When you run gpupdate /force from an elevated Command Prompt, Windows updates Group Policy settings for the computer and user, even if those settings have not changed. This is useful when a GPO is live in Active Directory and you need a machine to pick it up immediately.
To force a Group Policy update:
- A local command works on a single machine.
- To force an update on somebody else’s machine, you either need the Group Policy Management Console (GPMC), which targets one OU at a time, or the PowerShell’s Invoke-GPUpdate cmdlet, which can target any computers you specify.
- A domain-wide rollout needs a script.
This guide covers all three, the background refresh schedule, the firewall rules required for remote update, and how to verify that the update worked.
How Do You Force a Group Policy Update?
When choosing a method, consider the number of computers you need to update and how you want to target them. The following table compares the methods by scope and requirements.
| Method | Scope | Requires |
|---|---|---|
| gpupdate /force (Command Prompt) | This machine only | Local admin session, elevated command prompt |
| GPMC remote Group Policy update | Every computer in one OU, plus every OU nested inside it | GPMC installed, RPC and WMI firewall rules open on targets |
| Invoke-GPUpdate (PowerShell) | Any set of computers, including those outside the OU structure | GroupPolicy module, RPC and WMI firewall rules open on targets |
gpupdate /force can’t update policy settings on another computer because it runs only on the local machine.
The GPMC’s Group Policy update option is the only GUI method, but it can only target an OU and its child OUs. It cannot target an arbitrary list of computers or the default Computers container.
Invoke-GPUpdate is the most flexible option. You can target one computer, a scripted list of computers, or all computers returned by an Active Directory query, including those that are outside your OU structure.
On a Local Computer with Command Prompt
gpupdate is a Windows command-line utility that updates Group Policy settings on a local computer, and it’s included with supported Windows editions.
Press Win+X, select Command Prompt (Admin) or Terminal (Admin), then run:
gpupdate /force
You’ll see output similar to:
Updating policy…
Computer Policy update has completed successfully.
User Policy update has completed successfully.
This confirms that Windows has reapplied the Group Policy settings on the machine where you ran the command. If a policy needs a logoff or restart to take effect, gpupdate will prompt you.
Note: The target computer must be able to retrieve the updated GPO from a domain controller. If you recently created or changed the GPO, Active Directory replication must complete before the target sees the latest version.
To update group policy on multiple computers remotely, use GPMC or PowerShell.
The /force Parameter and What It Reapplies
Simply running gpupdate applies changed policy settings and new GPOs. The command contacts the domain controller, retrieves policy changes since the last refresh, and applies them to both computer and user configuration. Adding /force re-applies every GPO in scope regardless of change status.
Consider a scenario where a local administrator or an attacker with local administrator rights changes a registry value or security setting managed through Group Policy. The outcome: the GPO has not changed on the domain controller yet local settings do not match the value defined by the GPO. You should add /force to perform a refresh that re-applies all Group Policy settings, including security settings, on the target machines. When Windows re-applies the GPO setting, it overwrites the local change.
Additional Switches
The following table lists the switches that can be used with gpupdate:
| Switch | What it does | When you need it | Interrupts the user |
|---|---|---|---|
| /force | Re-applies every GPO, changed or not | Reverting local changes; urgent reapplication, retrying a failed install | No |
| /logoff | Logs off the user after policy processing; required for policies that can’t apply to an active session | User-targeted software installation and folder redirection | Yes, if required |
| /boot | Restarts the computer after policy processing; required for policies that apply only at startup | Computer-targeted software installation | Yes, if required |
| /sync | Makes the next foreground Group Policy application to run synchronously at computer startup, user logon, or both, depending on the /target value. Note that /force and /wait are ignored when /sync is used. | When you need the next foreground policy processing to complete before Windows continues | Can delay startup or logon |
| /target:{computer|user} | Updates policy for only Users or only Computers; both are updated by default | Narrow the scope of a refresh either to computer-side or user-side policies only | No |
| /wait:<seconds> | Sets how long gpupdate waits before returning to the command prompt. Default: 600 seconds; 0: don’t wait; -1: wait indefinitely | Scripting or controlling how long the command waits | No |
/logoff and /boot exist because some policy areas can’t apply changes to a running session, so you intentionally accept the interruption.
From the Group Policy Management Console
Since Windows Server 2012 and Windows 8, you can remotely refresh Group Policy for every computer in an OU from the GPMC. Microsoft states that this is the equivalent of running GPUpdate.exe /force from the command line.
Follow these steps:
- Open the Group Policy Management Console (gpmc.msc).
- Expand your domain and locate the target OU.
- Right-click this OU and select Group Policy Update.
- Click Yes on the Force Group Policy update dialog box.
When you trigger the Group Policy update, an Active Directory query returns all computers that belong to the OU and its child OUs. For each computer, a WMI call retrieves the list of signed-in users. Then a remote scheduled task is created that runs GPUpdate.exe /force once for each signed-in user and once for each computer. The firewall rules covered later are important because GPMC cannot create the remote scheduled task without them, and the update does not occur.
The Remote Group Policy update results window displays a status for each computer.
Note: You cannot use Group Policy Update for the default Computers container because that container is the default location for computer accounts and is not implemented as an OU that the GPMC can manage. To manage machines within it, use the PowerShell route.
What the Remote Group Policy Update Results Window Does and Does Not Confirm
The Remote Group Policy update results window shows the status of scheduling a Group Policy refresh for each computer in the target OU and its nested OUs. It only confirms whether Windows successfully scheduled the refresh task on each target.
The window does not show whether the actual Group Policy update succeeded or failed on those machines. A window full of successes means that the tasks were queued, not that the policy was applied successfully.
This confirmation step is separate. On the target computer, run gpresult /r to see which Group Policies and settings are in effect. This information is known as the Resultant Set of Policy (RSoP).
The Random Delay of Up to 10 Minutes
A GPMC-triggered policy refresh doesn’t run on every target at once. Windows schedules each one with a random delay of up to 10 minutes, spreading the network traffic load so hundreds of clients don’t contact the domain controller simultaneously. There is no option to control this random delay from the GPMC. If you want zero delay or want to configure it yourself, use PowerShell’s Invoke-GPUpdate cmdlet.
Practically, the delay means that you should wait for about 10 minutes before you start verifying results and conclude that something failed.
Remotely with PowerShell
PowerShell’s Invoke-GPUpdate has been available since Windows Server 2012. It allows you to schedule a remote Group Policy update on Windows client computers, with controls similar to those provided by GPUpdate.exe. However, the cmdlet is not a one-to-one wrapper for every gpupdate.exe switch. It also offers its own parameters, such as -RandomDelayInMinutes and -AsJob, for controlling how the update is scheduled and executed.
The cmdlet can target any computer, not just the ones inside an OU. That includes the computers container the GPMC cannot reach.
As prerequisites, you need:
- The GroupPolicy module (installed with RSAT’s Group Policy Management feature) on the machine you run it from.
- Currently supported Windows client and Windows Server versions on each target computer.
Open PowerShell with administrative privileges and run:
Invoke-GPUpdate
When run without any parameter, the cmdlet refreshes the changed Group Policy settings on the computer you are currently signed in to.
To run it on a specific computer, supply the -Computer parameter:
Invoke-GPUpdate -Computer “COMPUTER-NAME” -Force
When the cmdlet runs, it triggers a Group Policy update. The process for creating a scheduled task is the same as discussed for a GPMC-based trigger.
The cmdlet doesn’t return an output. To confirm success, run gpresult on the target.
-RandomDelayInMinutes 0 for an Immediate Refresh
Use the –RandomDelayInMinutes parameter with the Invoke-GPUpdate cmdlet to configure the interval of time to wait before a Group Policy refresh is performed. Set it to zero to run the scheduled task immediately.
Invoke-GPUpdate -Computer “COMPUTER-NAME” -Force -RandomDelayInMinutes 0
The trade-off: at zero delay, a command prompt window briefly appears on the target user’s desktop while gpupdate runs. You should use zero delay for something urgent, like a security fix. Use the default randomized delay for routine changes during business hours.
Updating Every Computer in the Domain with Get-ADComputer
To refresh Group Policy on multiple computers, pipe Get-ADComputer into Invoke-GPUpdate.
Note: Get-ADComputer -Filter * retrieves all computer objects in Active Directory, regardless of whether they are online. Offline or unreachable machines do not receive the remote refresh, but they receive the applicable Group Policy when they reconnect to the network.
Example 1: To refresh Group Policy settings for all computers in a domain:
Get-ADComputer -Filter * | ForEach-Object { Invoke-GPUpdate -Computer $_.Name -Force }
Example 2: To refresh all Group Policy settings for all computers in an OU:
Get-ADComputer -Filter * -SearchBase “OU=Accounting,DC=domain01,DC=com” | ForEach-Object { Invoke-GPUpdate -Computer $_.Name -Force }
Example 3: To refresh Group Policy settings for all computers in the default Computers container, which the GPMC cannot target because it isn’t an OU:
Get-ADComputer -Filter * -SearchBase “CN=Computers,DC=domain01,DC=com” | ForEach-Object { Invoke-GPUpdate -Computer $_.Name -Force }
If you pipe thousands of computers into Invoke-GPUpdate at once, you are generating that same number of remote scheduled task requests in a short period. Process the computers in smaller batches with a short pause between them, or use -AsJob to run the updates in parallel.
What is a Group Policy Update, and How Does it Work?
Let’s look at some definitions:
| Term | Definition |
|---|---|
| Group Policy | The infrastructure that lets you apply policy settings to configure a computer and user experience within a domain. |
| Group Policy Object (GPO) | A virtual object whose policy-setting information is stored in two components: a Group Policy Container in Active Directory and a Group Policy Template in SYSVOL. These policy settings manage things like password policies, logon scripts, security baselines, and desktop configurations. |
| Group Policy update |
The moment a client contacts a domain controller, pulls the GPO settings that apply to it, and applies them locally. The policy is applied automatically through any of these ways:
gpupdate and gpupdate /force trigger this very process on demand. Computer Group Policy is processed at computer startup, while user Group Policy is processed at user logon. The normal background policy refresh interval for clients and member servers is 90 minutes plus a random offset of up to 30 minutes. |
| Precedence, commonly abbreviated LSDOU |
The order in which Group Policy applies:
Policy settings applied later in the chain override earlier settings when there is a conflict. |
How Do GPOs, OUs, and Group Policy Inheritance Work?
An OU groups users and computers, usually by department or function. OUs sit at the lower end of the Group Policy hierarchy and inherit GPOs from above them (domain, site, and local level).
- Domain-level GPOs: Apply to the domain, such as password length and complexity requirements that affect all users and computers.
- Site-level GPOs: Apply to specific physical locations, such as assigning local printers or configuring settings for users and computers at a branch office.
- OU-level GPOs: Apply to specific OUs, such as an HR or marketing OU, so policies reflect the needs of different departments or teams.
- Local GPOs: Apply only to a specific computer and are used to configure local settings.
Note that:
- An OU-level Account Policy affects local accounts on computers in that OU, not the domain accounts stored there. Domain account policies are configured at the domain level.
- For other Group Policy settings, a lower-level GPO normally takes precedence over conflicting settings from a higher-level GPO. However, if the higher-level GPO link is configured as Enforced, its settings take precedence over conflicting settings in lower-level GPOs.
- The /force switch reapplies all applicable Group Policy settings. It does not change how Group Policy precedence or conflict resolution works. The same Local, Site, Domain, and OU processing order, link order, inheritance, and Enforced settings continue to apply.
When Should You Force a Group Policy Update?
The Group Policy client automatically checks for changes roughly every 90 minutes, so a new or changed GPO usually takes between 90 and 120 minutes to be applied, without requiring a manual push. Force a refresh when the situation won’t wait.
New Security Vulnerabilities
A mitigation delivered through a GPO only takes effect after target machines process the policy. If an urgent security advisory recommends disabling a vulnerable protocol or blocking a script host, deploy the GPO and run gpupdate /force on affected machines to apply the change immediately. Using /force can reapply Group Policy-managed settings and overwrite local configuration drift where the applicable policy extension supports background reprocessing.
Urgent Role, Access, and Device Changes
When an employee changes roles, access privileges need to change right away. This calls for an immediate user policy update, something that cannot wait for the next background refresh.
Keep in mind that a forced refresh only reaches a machine that’s online. A stolen laptop that never reconnects will not receive any new or updated policy. Think of gpupdate /force as a policy tool, not a device-recovery control. If you need to secure a missing device, pair it with BitLocker or a remote wipe solution.
Compliance Deficiencies Found at Onboarding
During acquisitions, mergers, or new client onboarding, an audit may reveal compliance issues in computer policies and system configurations. For example, folder permissions may not have been properly restricted through Group Policy. Create or update the GPO, then force a refresh on the affected machines so the new policy takes effect immediately, with a timestamp showing when.
What is the Difference Between gpupdate and gpupdate /force?
As mentioned earlier, gpupdate pulls changed and new GPOs only. /force reapplies every GPO in scope for the user and computer, whether or not the policies have changed, and it has a cost. Every client reprocesses its full policy set instead of a delta, which puts significant load on your domain controllers. The effect grows with the number of GPOs.
A small environment can usually handle the load; a gpupdate /force on a machine takes less than two minutes. The picture changes with dozens of GPOs and thousands of endpoints. Forcing large numbers of clients at once can increase network and domain controller load. Run the refreshes in smaller batches to keep that load under control.
This is an important consideration for MSPs because the load isn’t limited to one domain. A script that runs /force on every managed endpoint can create a spike on a client’s domain controllers. Running it for multiple client tenants back to back multiplies that load. A best practice is to batch and space out the refreshes.
The practical rule, especially when you have a substantial tenancy or many GPOs:
- Use /force when you need Windows to reprocess all applicable Group Policy settings, including settings whose GPOs haven’t changed, such as when correcting Group Policy-managed configuration drift or troubleshooting settings that remain incorrect.
- Use plain gpupdate when you simply need a new or changed GPO to be processed on demand.
- At scale, batch /force instead of running it domain-wide all at once.
What are the Prerequisites and Firewall Requirements for Remote Group Policy Updates?
When you perform a remote Group Policy refresh from GPMC or PowerShell, Windows uses WMI to query the target for signed-in users and remotely creates a scheduled task to run GPUpdate.exe /force. The remote task creation relies on RPC. If the target’s firewall blocks the required traffic, scheduling the refresh fails.
Required Ports and Services
To schedule a Group Policy refresh, the targets need inbound firewall rules for the following:
| Port or range | Service | Firewall rule name | Direction | Why it is needed |
|---|---|---|---|---|
| TCP 135 | RPCSS (Remote Procedure Call service) | Remote Scheduled Tasks Management (RPC-EPMAP) | Inbound | RPC endpoint mapping (RPC-EPMAP): tells the caller which dynamic port the real RPC service is on |
| TCP RPC dynamic range | Schedule (Task Scheduler service) | Remote Scheduled Tasks Management (RPC) | Inbound | Carries the scheduled-task creation call once the endpoint mapper hands off |
| TCP all ports | Winmgmt (Windows Management Instrumentation service) | Windows Management Instrumentation (WMI-In) | Inbound | Retrieves the list of signed-in users so the scheduled refresh can run for each user context |
Each entry corresponds to a step in the remote refresh process.
- TCP 135 provides RPC endpoint mapping.
- The dynamic RPC ports carry the remote scheduled-task request.
- The WMI rule allows the remote query for signed-in users.
When the required traffic is blocked, no scheduled task is created on the target. If a remote refresh repeatedly fails for a computer or OU, check these firewall rules first, along with the required services and permissions.
Configure the Group Policy Remote Update Firewall Ports Starter GPO
Windows Server 2012 and later ship a starter GPO, Group Policy Remote Update Firewall Ports, that includes policy settings to configure the firewall rules listed in the table above.
Microsoft recommends that you create a new GPO from that Starter GPO, link it to your domain at a higher precedence than the Default Domain GPO, and use it to enable remote Group Policy refresh on every computer in the domain. The steps are:
- In the GPMC console tree, locate the domain where you want to enable a remote Group Policy refresh on all computers.
- Right-click the domain and choose ‘Create a GPO in this domain, and link it here’.
- Type a name for the new GPO in the New GPO dialog box.
- In the Source Starter GPO list, select the ‘Group Policy Remote Update Firewall Ports’ GPO and click OK.
- In the results pane, open the Linked Group Policy Objects tab.
- Select the GPO that you just created, and click the Up arrow until the GPO sits above Default Domain Policy, giving it a smaller link order value than the Default Domain Policy.
This PowerShell equivalent creates the GPO from the Starter GPO and links it to the domain:
New-GPO -Name “Remote GPUpdate Firewall Rules” -StarterGpoName “Group Policy Remote Update Firewall Ports” | New-GPLink -Target “DC=domain01,DC=com” -LinkEnabled Yes
The command uses New-GPO with the -StarterGpoName parameter, then pipes the new GPO to New-GPLink to link it to the domain.
Enabling Windows Firewall with Advanced Security Through a GPO
In some environments, the Starter GPO route may not be available. For example, firewall rules may be centrally managed through another baseline GPO, and you may not want to add another GPO layer. In that case, you can configure the rules manually.
- Launch the Group Policy Management console.
- In the navigation pane, expand Forest, Domains, and Group Policy Objects.
- Right-click the GPO you want to modify and select Edit.
- In the Group Policy Management Editor, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall with Advanced Security > Inbound Rules.
- Create the three inbound firewall rules listed in the Required ports and services section:
- Remote Scheduled Tasks Management (RPC)
- Remote Scheduled Tasks Management (RPC-EPMAP)
- Windows Management Instrumentation (WMI-In)
Supported Operating Systems for Admin and Target Computers
To schedule a remote Group Policy refresh from GPMC, the administrative computer must be domain joined and have the required Group Policy management tools. The target computer must be reachable and have the required firewall rules enabled.
| Requirement | Admin workstation | Target computer |
|---|---|---|
| Operating system | Windows 10/11, or Server 2016 through 2025 | Windows 10/11, or Windows Server 2016 through 2025 |
| Required components | GPMC and RSAT (Group Policy Management) | Domain-joined, reachable, firewall rules enabled |
| PowerShell | 5.1 or later with the GroupPolicy module | Not required locally; runs under the Schedule service |
How Often does Group Policy Refresh Automatically?
Knowing the default duration after which Group {Policy automatically refreshes itself on a machine helps you decide whether a manual refresh is necessary.
| Trigger | Interval | What it applies |
|---|---|---|
| Client background refresh | 90 minutes, plus a randomized offset of up to 30 minutes | GPOs that are new or have changed since the last refresh, subject to each Client-Side Extension’s (CSE) processing rules |
| Domain controller background refresh | 5 minutes, no offset | GPOs that are new or have changed since the last refresh, targeting the domain controller |
| Security settings background refresh | Every 16 hours, fixed | Security settings in applicable GPOs, even when the GPO hasn’t changed |
| Computer restart | Immediate, every boot | Applicable computer-side policy |
| User Logon | Immediate, every logon | Applicable user-side policy |
The client background refresh is a 90-minute interval plus a randomized offset of up to 30 additional minutes, so the real range is 90 to 120 minutes, not a flat 90. The offset exists so that in large environments, thousands of machines do not contact domain controllers at the same time.
Windows reapplies security settings from applicable GPOs every 16 hours, even when those GPOs haven’t changed. Hence, security configuration gets forced back into line every 16 hours. This is separate from the normal 90-minute background refresh.
Background Refresh and Local GPOs (Reverting Local-Admin Changes)
A local administrator, or an adversary with local administrator rights, can change many settings on a machine, including settings that are controlled through Group Policy. For example, they might change a security setting that restricts removable storage, opening the door to data exfiltration or a USB-borne infection. The 16-hour security refresh will eventually undo that. A manual gpupdate /force closes that window immediately.
The lesson is least privilege: grant local administrator rights only where they are genuinely needed, and never give them to regular users.
Mandatory Reapplication of Non-Security Policy Settings
There is a middle path between waiting for the background refresh and running /force manually. The regular background update applies only new and changed GPOs, but you can modify it to reapply chosen settings even when the GPOs have not changed. This is a way to fix configuration drift or local changes in non-security policy areas.
The following policy areas can be configured to process even if the Group Policy objects have not changed. The behavior depends on the specific client-side extension and when that extension is processed:
- Registry (Administrative Templates)
- IP Security
- EFS Recovery Policy
- Wireless Policy
- Disk Quota
- Scripts
- Security
- Folder Redirection
- Software Installation
- Wired Policy
To enable mandatory reapplication of any of these policy areas:
- Open the GPO in the Group Policy Management Editor.
- Go to Computer Configuration > Administrative Templates > System > Group Policy (or the matching User Configuration path).
- Open a policy area and turn on the ‘Process even if the Group Policy objects have not changed’ setting.
This removes the need to manually run /force for a setting that may drift out of compliance. The trade-off: forcing reprocessing on every cycle adds load to both client and domain controller, so enable it selectively.
What are the Best Practices for Managing Group Policy Updates?
Forcing a refresh is easy. Doing it repeatedly, across an environment, without disrupting users or losing track of what changed, is the real skill. When you are managing multiple computers and systems, an organized approach helps you stay in control of every Group Policy update.
Plan Group Policy Changes Around Compliance Requirements
If you support compliance-heavy environments, keep an eye on changes to security policies. Regulatory changes are usually announced months in advance, so you have time to plan. Schedule your GPO updates and forced refreshes around those deadlines instead of rushing to get everything in place when the audit is around the corner.
Minimize Disruption from Reboots and Logoffs
Reboots and logoffs can disrupt users. As mentioned in the Additional switches section, /boot and /logoff interrupt the user’s session, while a plain gpupdate usually does not. Schedule interrupting refreshes at the least disruptive time, such as during lunch breaks or at the end of the day.
The same logic applies to the –RandomDelayInMinutes parameter. Zero delay produces a visible command window on the user’s desktop, so default to the randomized delay unless the change is genuinely urgent.
Combine Group Policy Updates with Maintenance Windows
If you’re already scheduling a patch cycle or reboot window, run the forced Group Policy refresh as part of the same maintenance window. In this way, you do not have to create separate change window and related work can be handled together. It also helps spread policy-processing traffic along with other planned maintenance and minimize business disruption.
Track every Group Policy change
Keep detailed records of all Group Policy changes: what changed, its purpose, the date it was executed, and the outcome. A simple table like this one can be useful:
| Date | GPO | Change | Reason | Scope forced | Verified by | Rollback step |
|---|---|---|---|---|---|---|
This practice pays off twice: an auditor will ask when a control took effect, and a rollback needs to know what the setting was beforehand when something goes wrong.
Managing Group Policy Updates at Scale (Tooling Section)
The policy refresh methods discussed in this article have limitations. gpupdate /force reaches one machine. The GPMC handles one OU at a time and cannot target the default Computers container or an arbitrary list of computers. Invoke-GPUpdate reaches any set of computers, but needs a management workstation, open firewall ports on every target, and a carefully defined computer list. And using /force can considerably spike policy-processing and network traffic.
MSPs and larger IT teams can benefit from centralized policy management platforms, which can:
- Push a scripted refresh to managed endpoint from one console, without a per-OU click.
- Schedule refreshes around maintenance windows to reduce disruption and load during business hours.
- Track refresh activity and results, so administrators can see what was triggered and whether the policy processing completed successfully, without manually running gpresult on hundreds of machines.
Quick Reference
Here’s a quick reference for policy refresh commands:
| Command prompt | Purpose |
|---|---|
| gpupdate | Apply changed policy and newly applicable GPOs |
| gpupdate /force | Reapply all applicable policy settings |
| gpupdate /logoff | Apply policy and log off the user if required |
| gpupdate /boot | Apply policy and restart the computer if required |
| gpresult /r | Show when policy was last applied, with policy settings and applied or denied GPOs |
| PowerShell | Purpose |
|---|---|
| Invoke-GPUpdate | Trigger Group Policy processing on the local computer |
| Invoke-GPUpdate -Computer NAME -RandomDelayInMinutes 0 | Trigger Group Policy processing on a remote computer without a randomized delay |
Frequently Asked Questions
How Can I Tell Whether Policies are Up to Date?
Open an elevated Command Prompt and run:
gpresult /r
This displays the RSoP summary information for the current user and computer, including the GPOs that were applied and those that were denied.
For a more detailed report, run:
gpresult /h C:\Temp\gpresult.html
Open the HTML report and review the applied and denied GPOs, as well as the policy settings reported for the user and computer. If an expected GPO is missing or appears under denied GPOs, verify your security filtering, group membership, WMI filters, and the GPO’s scope.
Compare the last policy processing timestamp against the expected refresh interval. If it’s older than the typical 90-to-120-minute interval, further investigation may be appropriate. The refresh interval can be customized or disabled through policy, and the device may also have been offline, asleep, or unable to contact a domain controller. If necessary, force a refresh with gpupdate /force or Invoke-GPUpdate -Force.
You can also use the GPMC Group Policy Results wizard for accurate diagnostics.
Can I Force an Update on Offline Computers?
No. The computer must have network connectivity to reach a domain controller and retrieve the latest Group Policy. An offline computer cannot be refreshed or scheduled remotely. The policy change isn’t lost, though. When the computer reconnects to the network, Group Policy processing can retrieve the policy during startup, user logon, or the next background refresh.
How Long Does gpupdate /force Take?
It depends on how many policies are being applied and what those policies do. A small number can take a few seconds to a couple of minutes, while policies involving Software Installation, Folder Redirection, scripts, or other resource-intensive processing can take longer.
The 90-minute interval plus the randomized delay of up to 30 minutes does not describe how long gpupdate /force takes to run. These numbers apply to the normal background refresh, not how long the command takes to run. gpupdate /force starts policy processing immediately instead of waiting for that refresh cycle.
In other words, background refresh timing determines when Windows checks for policy changes; execution time determines how long the policy processing takes when it starts.
Does gpupdate /force Require a Restart?
Not by default. Many settings apply live, in the current session. Settings that depend on startup or logon processing, like some Software Installation or Folder Redirection policies, need a reboot or logoff to finish applying. When this is necessary, gpupdate explicitly prompts you to restart or log off for changes to take effect.
How Can Action1 Automate Group Policy Refreshes Across All Your Endpoints?
Action1 can remotely execute PowerShell and CMD scripts on selected managed Windows endpoints or endpoint groups, so you can use a custom script to run gpupdate on multiple computers from its cloud-based console. This provides a way to automate Group Policy refreshes without manually connecting to each endpoint.
Run Group Policy Refreshes Remotely
Create a custom PowerShell or CMD script containing the required gpupdate command, then use a Run Script automation to execute it on the required Windows endpoints. Action1 lets you select individual endpoints or entire endpoint groups as the automation target.
For example, a PowerShell script could run:
gpupdate /force
You can then schedule the script to run once at a specified time or on a recurring schedule. Action1 supports schedules based on hours, days, weeks, or months, and lets you use either your current time zone or the local endpoint time.
Handle Offline Endpoints
Action1 includes a missed schedule retry and maintenance window for scheduled actions. If an endpoint is offline or disconnected when the automation is scheduled to run, Action1 can retry the action when the endpoint comes back online within the configured completion deadline.
Track Execution and Results
Action1 records script execution in its History view, where you can review the automation session and view results for individual target endpoints. Endpoint details also include automation history, providing visibility into whether the Group Policy refresh script ran successfully.
Control Access and Manage Multiple Organizations
Action1 provides role-based access control (RBAC), allowing administrators to assign permissions and limit access according to users’ responsibilities. It also supports MFA for console access.
For MSPs and larger organizations, Action1 supports multiple organizations within a single account. Administrators can manage separate customer or business-unit environments from a central console while keeping endpoint data separated by organization.
Reporting
Action1 also provides reporting and dashboard capabilities for monitoring endpoint activity and management status.
Note: The first 200 endpoints are free forever with no feature limitations, so organizations can use these endpoint-management and automation capabilities without paying for the first 200 endpoints.
