Free builder for gpupdate /force, gpresult RSoP reports, and Invoke-GPUpdate commands for local and remote computers. Copy-paste ready.
Most Group Policy work comes down to three questions asked in a hurry: how do I force a refresh, how do I prove which GPOs actually applied, and why has the setting I just configured not landed on this machine. This builder assembles the command for you — you pick the action, the target and the method, and it writes the syntax, warns you when the step needs an elevated prompt or the RSAT module, and lets you chain several steps into one script you can copy or download as a .ps1 file.
Everything is generated in your browser. No computer names, OU distinguished names or usernames you type are sent anywhere — the tool is a string builder, not a remote console. It never connects to a domain controller, so it cannot tell you what your GPOs contain; it tells you what to run.
Each action is wired to the methods that can genuinely perform it, so you cannot generate a command that does not exist. Selecting an action switches the method automatically if your current choice is not compatible.
| Action | Methods offered | Elevation |
|---|---|---|
| Force a policy update | gpupdate, PowerShell (Invoke-GPUpdate) | Run as Administrator |
| Generate RSoP report (HTML) | gpresult, PowerShell (Get-GPResultantSetOfPolicy) | Not required for your own account |
| Show applied policies | gpresult only | Not required for your own account |
| Back up GPOs | PowerShell (Backup-GPO) | Run as Administrator |
| List GPOs & links | PowerShell (Get-GPO) | Not required |
Backup and list are domain-wide operations, so choosing either one locks the target back to local — you run them from a machine that already has the GroupPolicy module, against the domain, not against a workstation.
A plain gpupdate applies only the policy settings that have changed since the last refresh. That is fast, and it is also the reason a change you just made appears to do nothing: if the client-side extension decides nothing changed, it skips the work. /force discards that optimisation and re-applies every setting from scratch, which is why it is the switch everybody reaches for and why it is ticked by default in the builder.
The switches the builder can emit, in the order it writes them:
/force — reapply all settings, not just changed ones./target:user or /target:computer — refresh one half only. Leave the scope on User + Computer and the switch is omitted, which is the default behaviour of refreshing both./sync — make the next foreground policy application synchronous. This is the switch for settings that will not apply in the background at all; it triggers a logoff or restart to do it./logoff — log the user off after the refresh, if any applied extension requires it./boot — restart the computer after the refresh, if any applied extension requires it.So a full local refresh of computer policy followed by a restart is gpupdate /force /target:computer /boot. Note that /logoff and /boot are conditional: they act only if a processed extension actually asked for it, so pairing them with /force on a machine with nothing pending will simply do nothing. gpupdate also accepts /wait:<seconds> to change how long the console waits for processing to finish; the builder does not emit that one, so add it by hand if you are scripting around the return.
Group Policy has two halves that refresh independently. Computer Configuration is applied by the Group Policy service in the machine's own context at startup and on the background refresh cycle. User Configuration is applied at logon and on its own background cycle. On Windows the default background refresh runs roughly every 90 minutes with a random offset of up to 30 minutes so that thousands of clients do not hit the domain controllers at once; domain controllers themselves refresh every five minutes. That randomised offset is exactly why "I waited, it still has not applied" is so often a false alarm.
The refresh cycle only covers extensions that support background processing. A handful genuinely cannot apply while the session is live, and no amount of /force will change that:
That is the whole point of /sync, /logoff and /boot. If you are chasing a drive map, a mapped printer, a registry preference or a security setting, a background refresh is enough and a reboot is superstition. If you are chasing redirected Documents or an MSI, stop refreshing and log off.
Refreshing tells you nothing about the result. gpresult is the Resultant Set of Policy reporter, and it is the command that actually answers "did my GPO apply".
gpresult /r prints a console summary: the site, domain and OU the object sits in, the last time policy was applied, the list of applied GPOs, and — the part people miss — the list of GPOs that were filtered out along with the reason. A GPO showing "Filtering: Denied (Security)" is a security-filtering or permissions problem. "Denied (WMI Filter)" is a WMI filter that did not evaluate true. "Not Applied (Empty)" means the half of the GPO you care about has no settings in it.
gpresult /h "C:\Temp\GPReport.html" /f writes the same data as a full HTML report, which is far easier to read and to attach to a ticket. /f overwrites an existing file at that path — without it the command fails when the report already exists, which is the single most common reason this line errors out on a second run. The builder always appends /f and follows the report with a Start-Process line so it opens straight away.
The modifiers the builder adds:
/s <computer> — query a remote machine. Added when you switch the target to remote and supply exactly one computer name./user DOMAIN\user — report on a different user's resultant policy. Reading another user's data requires administrative rights on the target; your own needs nothing special./scope user or /scope computer — restrict the report to one half.A worked example: to see why a member of the finance OU is not getting a drive map on their laptop, from your admin workstation, that is gpresult /s FIN-LT-014 /user CORP\jsmith /scope user /h "C:\Temp\GPReport.html" /f.
The gpupdate and gpresult executables ship with Windows. The cmdlets do not — they come from the GroupPolicy module, which means the Group Policy Management Tools feature of RSAT on a workstation, or the Group Policy Management feature on a server or domain controller. Every PowerShell script the builder produces opens with Import-Module GroupPolicy for that reason, and the tool flags the requirement in the warning strip so you find out before you paste rather than after.
| Cmdlet | What the builder generates it for |
|---|---|
Invoke-GPUpdate | Refreshing policy on a remote computer or across a whole OU |
Get-GPResultantSetOfPolicy | RSoP HTML report, optionally for a named computer and user |
Backup-GPO | Backing up every GPO in the domain to a folder |
Get-GPO | Listing GPOs with status and last modification time |
Invoke-GPUpdate is the reason to use PowerShell here at all: it is the only method in the tool that can refresh machines other than the one you are sitting at. Give it -Computer "PC-01" for a single target, or -OU "OU=Workstations,DC=corp,DC=local" to hit everything in an organisational unit. It accepts -Force, -Target "User" or -Target "Computer", -Boot and -LogOff, mirroring the gpupdate switches. Paste more than one computer name into the box without an OU and the builder switches shape entirely, emitting a ForEach-Object loop over the list rather than a single call.
One caveat the generated header understates: Invoke-GPUpdate works by scheduling a task on the target machine, so the target needs the Remote Scheduled Tasks Management firewall rules allowed, not just PowerShell remoting. If the cmdlet fails against a machine you can otherwise reach, that firewall group is the first thing to check.
The backup step is deliberately blunt: it creates the destination folder if it is missing, then runs Backup-GPO -All with a dated comment. Take one before you edit anything you would struggle to rebuild.
When you need to look at files rather than run commands, three locations matter. Domain GPOs live in SYSVOL, under \\yourdomain\SYSVOL\yourdomain\Policies\{GUID}, with the registry-based settings in registry.pol and the metadata in Active Directory. Local Group Policy lives on the machine in C:\Windows\System32\GroupPolicy (and GroupPolicyUsers for per-user local policy). And the settings that have actually been written to the client end up in the registry under HKLM\Software\Policies and HKCU\Software\Policies — checking there is the fastest way to confirm a setting landed without reading a report.
Run gpresult /r first. It will tell you which of these it is faster than any amount of guessing, and every one of the categories above shows up in the filtered-out list with a reason attached.
Each generated command can be added to a running list, which the tool assembles into a single annotated script with numbered step comments. The header comments are conditional on what you built: an elevation note appears only if a step needs it, the RSAT module note only if a cmdlet is involved, and the remoting note only if a step targets another machine. Copy it to the clipboard or download it as group-policy.ps1. A typical troubleshooting script is two steps — force the refresh, then write the HTML report — so you can hand a single file to whoever is sitting at the machine.
There is also an optional in-browser assistant that turns a plain-English request such as "force a policy refresh on PC-01 and PC-02" into the option settings below it. It runs a small model entirely on your own GPU through WebGPU, downloading the weights once on first use, and it is genuinely optional — every option it sets can be set by hand, and browsers without WebGPU simply do not offer it.
Run gpupdate /force from an elevated prompt to re-apply every policy setting immediately instead of waiting for the background refresh. Add /target:user or /target:computer to refresh one side, and /logoff or /boot if a setting needs a sign-out or restart to take effect.
gpupdate applies Group Policy, forcing the machine to pull and enforce current settings. gpresult reports the Resultant Set of Policy, showing which GPOs actually applied to a user or computer and why. You use gpupdate to push policy and gpresult to verify it.
Use the GroupPolicy PowerShell module: Invoke-GPUpdate -Computer "PC-01" -Force, or target a whole OU with -OU. This requires RSAT or a domain controller, and each remote machine must have WinRM enabled via Enable-PSRemoting -Force.
Generate an RSoP report with gpresult /h report.html /f and open it. The report lists applied, denied, and filtered GPOs, so you can see whether a policy was blocked by a security-group filter, WMI filter, or scope before troubleshooting further.