Anyone who manages Group Policy (GP) knows about the gpupdate.exe utility that ships with Windows. GPUpdate’s job is to refresh Group Policy manually, rather than relying on Windows to do it on its own schedule. Specifically, it can be used to force the system to ask Active Directory (AD) what’s new about Group Policy since the last time the client contacted AD. This can be a useful troubleshooting tool if you’re trying to determine whether a particular change to a GPO has been received by a client.
The version of GPUpdate in Windows 11 includes a number of options. Let’s explore what each of them can bring to the table.
What Does the /force Option in GPUdate Actually Do?
Many of you routinely use the /force option. That option tells Windows to forcibly reapply GP settings even if nothing has changed on the GPO side. Even if nothing has changed in your GPOs, using the /force option can be useful to tell the client to reapply all existing applied policies if someone has tampered with the settings delivered locally.
Normally, when Windows performs a periodic background or foreground refresh, which occurs at reboot or relogon, it checks whether anything has changed in the GPOs that apply to it. If nothing has changed, none of the Client Side Extensions (CSEs) that process policy settings will actually do anything (unless they’ve been instructed to, but that’s an article for another time). This is a performance optimization to prevent overloading AD domain controllers.
Using the /force switch tells the GP engine to ignore the fact that nothing has changed and forces the CSEs to act as if something has changed and reprocess all applied policy settings.
To be clear, this doesn’t literally mean re-processing EVERYTHING. For example, if the Software Installation CSE has previously installed Adobe Reader, it’s not going to reinstall Adobe Reader during a gpupdate /force if it’s still there, thankfully!
Have you ever wondered why, after running /force, you sometimes get prompts asking whether you want to log off or shut down the system after a refresh? What’s happening there is that not only is gpupdate forcing a background refresh of policy (i.e. an asynchronous refresh), but it’s also forcing a foreground refresh (requiring a user logon or machine reboot). More specifically, some CSEs, such as Software Installation and Folder Redirection, only process during the foreground processing cycle. If one of these CSEs apply to the system or user that you’re currently issuing the GPUpdate from, then /force will tell the system that it needs a foreground processing event (i.e. a restart or logoff) to process those policies. Behind the scenes the GP engine is setting a flag to tell the system to do a synchronous foreground cycle during the next foreground event. You can, of course, answer no to that, but that’s why it happens.
GPUpdate Options and What They Are for
In addition to the /force option, gpupdate has several other switches that can be useful. Let’s take a closer look at what’s available.
/Target:{Computer | User} — This one lets you refresh either the computer or the user policy selectively. For example, if you made a change to a per-user GPO setting, it’s much quicker to issue the command gpupdate /Target:user than to simply type gpupdate, which refreshes both per-computer and per-user settings–probably not needed if only user settings have changed. Note that you can use this parameter alongside other parameters, such as /force.
/Wait:{value} — The Wait parameter is a little confusing. It lets you handle the situation where GP refresh hangs for an extraordinarily long time. The default is to wait for 10 minutes for the command to complete. If it takes longer than that, then GPupdate simply stops trying and returns. If you set this value to -1, then gpupdate will continue indefinitely. Frankly, there are probably few cases where you’ll use this parameter, since if your GP processing is taking 10 minutes, you have bigger problems! I can admit that in 25+ years of doing GP, I’ve never used this parameter 🙂
/Logoff — The Logoff parameter is kind of like a modified Force. What it says is, do a normal GP processing update (i.e., don’t do anything if nothing has changed, unlike /force) but, if there are CSEs that apply to the current user that only process in the foreground, set the flag mentioned above and log me off after GP processing is completed, so that I can log back on to get that foreground processing cycle. Frankly, you could accomplish the same thing by simply logging off and logging back on, so it’s not clear to me why this switch is here, but there you go. Perhaps it’s all about setting the flag to force that next logon to be synchronous.
/Boot — Boot is exactly like /logoff, except that it applies to per-computer CSEs that need to do some foreground work (e.g., per-computer software installation), and it reboots the computer if you say yes to the prompt. So, you know–be CAREFUL about that! I have, on more than one occasion, accidentally rebooted a system I didn’t want to because of this option. Again, this prompt only happens if there are per-computer CSEs that apply to the machine that actually need a foreground processing cycle. These days, there are really precious few of these outside of Software Installation, which most people don’t use anymore anyway.
/Sync — Sync actually doesn’t perform a GP refresh at all. All it does, if specified alone, is set those flags for both per-computer and per-user processing that force the next foreground refresh (i.e., reboot or re-logon) to be performed synchronously. So, what does this actually mean? By default, ever since Windows XP, Microsoft enabled something called “fast logon optimization” that made foreground GP processing occur asynchronously, meaning while other things were getting done. As Windows starts up, per-computer GP processing occurs concurrently with the user logon dialog, without waiting for GP processing to finish. The same would hold true for per-user GP processing, where asynchronous processing meant that once the user logged on, GP processing would start, but the user would be presented with their desktop without waiting for GP processing to finish. This asynchronous behavior can impact some of those same CSEs that only run during foreground processing–most notably, folder redirection.
You could, of course, disable asynchronous processing altogether by enabling the Admin. Template policy on the computer at Computer Configuration\Admin Templates\System\Logon\Always Wait for the Network at Computer Startup and logon. In the absence of this policy, the/Sync parameter tells Windows that, during the next foreground event, I want to ensure GP runs synchronously. This might be a good switch to use if you are having problems with Folder Redirection kicking in and you want to make absolutely sure that the next logon happens synchronously. But outside of Folder Redirection, you aren’t likely to need it much. I do know some people who use this, like /force, as a “catch-all” to try to solve weird GP processing problems. There’s no harm in doing that, but it may not help either.
As mentioned above, you can use many of these switches in combination–such as calling /force and specifying the /target parameter to control whether user or computer processing is forced. But by and large, each parameter stands alone or only makes sense on its own.