Force gpupdate Remote Computers: 5 Methods for Every OU

To force gpupdate remote computers from one console, Windows gives you GPMC’s Group Policy Update command and the Invoke-GPUpdate cmdlet, and PowerShell remoting or PsExec work as alternatives. All of them end up running gpupdate on the target, but they differ in the firewall rules they need, whether they refresh the signed-in user’s policy, and how much they tell you afterwards. This guide covers the gpupdate switches, each remote method, the background refresh intervals and the common failures.

Short answer: For a whole OU, right-click it in GPMC and choose Group Policy Update…. For a script or a single PC, run Invoke-GPUpdate -Computer PC01 -RandomDelayInMinutes 0 -Force. Both need three inbound firewall rules on the targets: Remote Scheduled Tasks Management (RPC), Remote Scheduled Tasks Management (RPC-EPMAP) and Windows Management Instrumentation (WMI-In).

Which method to use

Method	Scope	Needs on the target	Refreshes signed-in users	Best for
GPMC Group Policy Update	All computers in an OU	Scheduled Tasks and WMI firewall rules	Yes	Quick push after a GPO change
Invoke-GPUpdate	One computer per call; loop for many	Same as GPMC	Yes	Scripts, filters, delays, jobs
Invoke-Command + gpupdate	Many computers in parallel	WinRM enabled	No (remote session user only)	Computer policy where WinRM is already used
PsExec	One or a list of computers	Admin share and SMB	No	Legacy or ad-hoc fixes
Background refresh	Every domain member	Nothing	Yes	Changes that can wait 90 to 120 minutes

Every way to force gpupdate remote computers runs the same client engine, but only GPMC and Invoke-GPUpdate refresh user policy for the people actually signed in, because they create a scheduled task that runs gpupdate in each user’s session as well as once for the computer.

gpupdate switches

Every method below eventually runs one of these commands, so it helps to know what each switch does.

Switch	Effect
/target:computer or /target:user	Refresh only one half; the default is both
/force	Reapply every setting, not only the ones whose GPO changed
/wait:<seconds>	How long the command waits for processing to finish (default 600, 0 no wait, -1 forever); processing continues after the timeout
/logoff	Sign the user out afterwards if an extension needs it (for example user Software Installation or Folder Redirection)
/boot	Restart afterwards if an extension needs it (for example computer Software Installation)
/sync	Make the next startup or sign-in process policy synchronously; /force and /wait are ignored with it

/force is not always needed. A plain gpupdate already applies GPOs whose version changed. Use /force when a setting was changed locally or a previous run failed, and avoid it on hundreds of machines at the same moment, because every client then downloads and reapplies every GPO.

Prerequisites

Before you force gpupdate remote computers, check the following:

• Domain-joined targets running Windows 11 Pro, Enterprise or Education, or Windows Server 2016 to 2025.
• An account that is a local administrator on the targets (Domain Admins, or a delegated group added through Restricted Groups or Group Policy Preferences).
• GPMC and the GroupPolicy module (RSAT on Windows 11), plus the ActiveDirectory module to list computers in an OU.
• The Task Scheduler and Windows Management Instrumentation services running on the targets (both are by default).
• Replication finished: a client reads GPOs from its own DC, so a change made on another DC must replicate first. On a small domain you can push it with repadmin /syncall /AdeP.

Open the firewall rules

To force gpupdate remote computers with GPMC or Invoke-GPUpdate, every target needs three predefined inbound rules:

Rule	Traffic
Remote Scheduled Tasks Management (RPC)	Task Scheduler service over dynamic RPC ports
Remote Scheduled Tasks Management (RPC-EPMAP)	RPC endpoint mapper, TCP 135
Windows Management Instrumentation (WMI-In)	WMI, used to find signed-in users

Option A: the starter GPO

1. In GPMC, select Starter GPOs. If the folder is empty, click Create Starter GPOs Folder.
2. Right-click Group Policy Remote Update Firewall Ports and choose New GPO From Starter GPO….
3. Name the new GPO and link it to the workstation and server OUs.

Option B: predefined rules in your firewall GPO

1. Edit your firewall GPO and go to Computer Configuration » Policies » Windows Settings » Security Settings » Windows Defender Firewall with Advanced Security » Windows Defender Firewall with Advanced Security » Inbound Rules.
2. Right-click New Rule…, choose Predefined, select Remote Scheduled Tasks Management, tick both rules and allow the connection.
3. Repeat with the predefined group Windows Management Instrumentation (WMI) and tick only WMI-In.
4. Limit the Remote IP address scope on each rule to your admin subnet where possible.

Option C: one machine from PowerShell

Enable-NetFirewallRule -DisplayName 'Remote Scheduled Tasks Management (RPC)', 'Remote Scheduled Tasks Management (RPC-EPMAP)', 'Windows Management Instrumentation (WMI-In)'

Our Windows Firewall Group Policy guide covers rule scope and profiles in detail.

Method 1: GPMC Group Policy Update

1. Open Group Policy Management and select the OU that holds the computers.
2. Right-click the OU and choose Group Policy Update…. GPMC shows how many computers it found; click Yes.
3. The Remote Group Policy update results window lists each computer with Succeeded or an error code.

Two facts to keep in mind. First, Succeeded means the refresh task was scheduled, not that policy processing completed. Second, GPMC schedules the task with a random delay of up to 10 minutes to spread the load, and you cannot change that delay in the console. The task runs gpupdate /force once for the computer and once for each signed-in user.

Method 2: Invoke-GPUpdate

The cmdlet does what GPMC does, with control over the delay, scope and output. It is the most flexible way to force gpupdate remote computers from a script.

One computer

Invoke-GPUpdate -Computer PC01 -RandomDelayInMinutes 0 -Force
Invoke-GPUpdate -Computer 'CONTOSO\PC02' -Target User -RandomDelayInMinutes 0

Parameters that matter:

• -RandomDelayInMinutes: 0 runs as soon as the task is scheduled; 1 to 44640 (31 days) waits that many minutes plus a random offset.
• -Target: Computer or User; both when omitted.
• -Force: runs without asking for confirmation.
• -Boot and -LogOff: restart or sign out afterwards when an extension needs it, like the gpupdate switches.
• -AsJob: returns a background job; collect results with Receive-Job.

A whole OU with error reporting

This is the pattern we use to force gpupdate remote computers in one OU and keep a record of the machines that could not be reached:

$ou = 'OU=Workstations,DC=contoso,DC=com'
$results = Get-ADComputer -Filter 'Enabled -eq $true' -SearchBase $ou | ForEach-Object {
    $pc = $_.DNSHostName
    try {
        Invoke-GPUpdate -Computer $pc -RandomDelayInMinutes 5 -Force -ErrorAction Stop
        [pscustomobject]@{ Computer = $pc; Status = 'Scheduled' }
    } catch {
        [pscustomobject]@{ Computer = $pc; Status = $_.Exception.Message }
    }
}
$results | Export-Csv C:\Reports\GPUpdate-Workstations.csv -NoTypeInformation
$results | Where-Object Status -ne 'Scheduled'

The computer name is stored in $pc before the try block because inside catch, $_ refers to the error rather than the computer. The last line prints only the failures, which are usually offline laptops or machines without the firewall rules.

Only computers active recently

To limit the push to machines that were active in the last week, filter on LastLogonDate (based on the replicated lastLogonTimestamp attribute, which can lag by up to two weeks) first:

$since = (Get-Date).AddDays(-7)
Get-ADComputer -Filter 'LastLogonDate -gt $since' -SearchBase $ou |
    ForEach-Object { Invoke-GPUpdate -Computer $_.DNSHostName -RandomDelayInMinutes 10 -Force }

Run it as background jobs

Each Invoke-GPUpdate call waits for the remote task to be registered, which adds up over a large OU. With -AsJob the calls run in parallel and you collect the results afterwards:

$jobs = Get-ADComputer -Filter * -SearchBase $ou | ForEach-Object {
    Invoke-GPUpdate -Computer $_.DNSHostName -RandomDelayInMinutes 5 -Force -AsJob
}
$jobs | Wait-Job -Timeout 300 | Out-Null
$jobs | Where-Object State -eq 'Failed' | ForEach-Object { $_.ChildJobs.JobStateInfo.Reason.Message }
$jobs | Remove-Job -Force

Schedule the refresh for later

For a change that should land outside office hours, set a longer delay. -RandomDelayInMinutes 240 run at 18:00 starts the refresh after 22:00 plus a random offset, and the task still runs if nobody is signed in (the user part is then skipped). Remember that the delay counts from the moment the task is created, so run the script at a predictable time.

A small random delay (5 to 15 minutes) spreads the load on DCs and SYSVOL when you target hundreds of machines. For an urgent security change on a few PCs, use 0.

Method 3: Invoke-Command

Where WinRM is already enabled, PowerShell remoting can force gpupdate remote computers in parallel, up to the throttle limit you set:

$pcs = (Get-ADComputer -Filter * -SearchBase 'OU=Servers,DC=contoso,DC=com').DNSHostName
Invoke-Command -ComputerName $pcs -ThrottleLimit 32 -ScriptBlock {
    gpupdate /target:computer /force /wait:120
}

The remote session runs as your admin account, so a user-side refresh would update your policy on that machine, not the signed-in user’s. Use this method for computer policy only. It needs no Task Scheduler or WMI rules, only WinRM (TCP 5985).

Method 4: PsExec

PsExec from Sysinternals uses the admin share and a temporary service. It is useful when WinRM and the scheduled-task rules are both unavailable:

psexec \\PC01 -s gpupdate /target:computer /force
psexec @C:\Lists\kiosks.txt -s gpupdate /target:computer /force

-s runs as SYSTEM and @file reads one computer name per line. As with remoting, the user half does not refresh the signed-in user. Many security teams block PsExec, so prefer the native methods.

Method 5: tune background refresh

Sometimes you do not need to force gpupdate remote computers at all, and the right answer is to let the normal cycle do the work. Windows refreshes computer and user policy in the background every 90 minutes with a random offset of 0 to 30 minutes, and domain controllers every 5 minutes. Security settings are also reapplied every 16 hours even when no GPO has changed. You can change the intervals with these settings under Computer Configuration » Policies » Administrative Templates » System » Group Policy:

• “Set Group Policy refresh interval for computers”: interval (0 to 64800 minutes) and random offset. The values are stored as GroupPolicyRefreshTime and GroupPolicyRefreshTimeOffset under HKLM\SOFTWARE\Policies\Microsoft\Windows\System.
• “Set Group Policy refresh interval for domain controllers”: the same for DCs.
• “Turn off background refresh of Group Policy”: leave this Not Configured; when enabled, policy waits until the user signs out.

The user interval is set by “Set Group Policy refresh interval for users” under User Configuration » Policies » Administrative Templates » System » Group Policy. Shortening intervals across the domain raises the load on DCs; a remote refresh for urgent changes is usually the better trade.

For settings that only apply at startup or sign-in, enable Computer Configuration » Policies » Administrative Templates » System » Logon » "Always wait for the network at computer startup and logon" so foreground processing is synchronous.

Verify the refresh ran

Because most tools that force gpupdate remote computers only schedule the work, check the targets afterwards:

1. From your admin PC: gpresult /s PC01 /scope computer /r. The Last time Group Policy was applied line should show the new time.
2. For a full report: Get-GPResultantSetOfPolicy -Computer PC01 -ReportType Html -Path C:\Temp\PC01.html.
3. On the target, open Applications and Services Logs » Microsoft » Windows » GroupPolicy » Operational. Event 4004 marks the start of manual computer processing and 8004 its successful completion; 4005 and 8005 are the user equivalents.
4. For several machines, read the time of the last successful manual computer refresh from the event log over remoting:
   

   Invoke-Command -ComputerName PC01, PC02 -ScriptBlock {
       Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -MaxEvents 200 |
           Where-Object Id -eq 8004 | Select-Object -First 1 TimeCreated
   }

Troubleshooting

Error or symptom	Likely cause	Fix
0x800706BA The RPC server is unavailable	Target offline or firewall rules missing	Enable the three rules; check the machine is on and resolvable
0x80070005 Access is denied	Your account is not a local admin on the target	Use an admin account or fix local group membership
Succeeded in GPMC but nothing changed	Only scheduling succeeded; the change has not replicated to the client’s DC	Wait for replication or sync it; check events 4004/8004
User settings not refreshed	Nobody signed in, or you used Invoke-Command or PsExec	Use GPMC or Invoke-GPUpdate while users are signed in
Software or Folder Redirection not applied	Extension needs startup or sign-in	Use -Boot or -LogOff, or schedule a restart
Computers missing from the GPMC count	Objects are in a different OU or stale in AD	List them with Get-ADComputer -SearchBase and compare
gpupdate itself reports errors	DNS, SYSVOL or GPO problems on the client	Follow the event 1058/1030 checks in our Group Policy not applying guide

Once the firewall rules are in place through a GPO, the ability to force gpupdate remote computers becomes a routine step after every GPO change: edit, wait for replication, run GPMC Group Policy Update or Invoke-GPUpdate, then confirm with gpresult or event 8004.

Force gpupdate remote computers at a glance

Official documentation: Invoke-GPUpdate (GroupPolicy module), gpupdate command reference, Force a remote Group Policy refresh (GPUpdate).

Related guides: Troubleshoot Group Policy not applying: gpresult, RSoP and Events 1058/1030 · Windows Firewall rules with Group Policy · Group Policy processing order, Enforced and Block Inheritance.

Frequently asked questions