Anyone that manages Group Policy probably knows about the gpupdate.exe utility that ships with Windows. GPUpdate’s job in life is to refresh Group Policy manually, rather than relying on Windows to do it on it’s own schedule. This can be a useful troubleshooting tool if you’re trying to determine whether a GP update has been received by a client machine. The version of GPUpdate in Windows 7 includes a number of options.<--more--!>

Many of you probably routinely use the /force option. That option tells Windows to forcibly re-apply GP settings even if nothing has changed within the GP infrastructure. As you may know, normally when Windows performs a periodic background refresh or foreground refresh during reboot or re-logon, it checks to see if anything has changed within the GPO infrastructure. If nothing has changed, none of the Client Side Extensions (CSEs) that process policy settings will actually do anything. This is a performance optimization. Using the /force switch tells the GP engine to ignore that nothing has changed, and forces the CSEs to act as if something has changed and re-process all applied policy settings (note that for some things, this doesn’t literally mean re-processing. For example, if the Software Installation CSE has previously installed Adobe Reader, it’s not going to re-install Adobe Reader during a gpupdate /force if its still there).

But gpupdate also has a number of other switches that can prove useful and those are the ones I want to cover here. To summarize, here are the options available with gpupdate, and a description of each.

/Target:{Computer | User} — this one lets you refresh either computer or 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 refresh both per-computer and per-user settings.

/Force — We all know this one, but may wonder why we occasionally get those prompts that ask if we want to logoff or shutdown the system.  What’s happening there is that not only is gpupdate forcing a background refresh of policy, but it’s also forcing a foreground refresh. More specifically, there are some CSEs, like Software Installation and Folder Redirection, that only process during a foreground processing cycle (i.e., during computer startup or user logon). 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. You can, of course, answer no to that, but that’s why it happens.

 /Wait:{value} — The Wait parameter is a little confusing. It lets you handle the situation where GP processing hangs for an extraordinary long period of time. The default is to wait for 10 minutes for the command to complete. If it takes longer than that, then GPupdate simply gives up 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!

/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, 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 an logging back on, so it’s not clear to me why this switch is here, but there you go.

/Boot — Boot is a 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. Again, this prompt only happens if there are per-computer CSEs that apply to the machine, that actually need a foreground processing cycle.

/Sync — Sync actually doesn’t perform a GP refresh at all. All it does, if specified alone, is set some flags for both per-computer and per-user processing that forces 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. What this meant is that, for example, as Windows was starting up, per-computer GP processing would happen but at the same time, Windows would present the user logon dialog–not 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. What the /Sync parameter does, in the absence of this policy, is tell Windows that during the next foreground event, I want to make sure 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.

Obviously, you can use some of these switches together–such as calling /force and specifying a the /target parameter to control whether user or computer processing is forced. But by and large, each of the parameters stands alone or only makes sense on it’s own. I’ve added a quick video below that shows how gpupdate behaves when you call the various options. In the case of my test workstation, I didn’t have any CSEs that needed to run in the foreground, so you won’t see logoff or restart prompts for the /logoff, /force or /boot parameters, but you do get to see them for the /sync parameter.

Also, check out my free remote GP refresh command line utilities. There’s a simple .exe out on www.gpoguy.com and a PowerShell version at www.sdmsoftware/freeware! Enjoy!

Darren