Group Policy Blog

Group Policy Tips, Tricks, and News from Darren Mar-Elia

Understanding the Group Policy GPUpdate Command

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

 

 

 

There are 9 comments .

Pierre Breau —

Do you really need to do a gpupdate on the current local machine to apply policy from the AD or as soon the user logoff the policy will apply by it self ?

Reply »
    Darren Mar-Elia

    Pierre-
    A logoff/logon is not sufficient to refresh policy. Or more specifically, if nothing has changed on the GPO side, then even a logon (or restart) will not force a policy re-application. This is a common mis-understanding.

    Darren

    Reply »
Higgs —

” 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.”

A bit off topic, but does this mean that if the local administrator uses regedit.exe and changes a GPO configured registry key, the key will never get reset by the GPO again (unless the GPO is updated or the setting is included in the mandatory 16 hour security settings refresh)?

Thanks.

Reply »
    Darren Mar-Elia

    That’s correct! If a policy setting is manually updated by an administrator, it will only get set back when “something changes” in the GPOs processed by that CSE. And correct that the exception to that is the 16 hour security CSE auto-refresh.

    Darren

    Reply »
Steve —

I need to run gpupdate /force on a machine that is our database server. If I do that will it disrupt database users or their database processes who are currently logged into our database?
Steve

Reply »
    Darren Mar-Elia

    Steve-
    It’s really hard to answer that without knowing all the policies you’re applying. To be clear, all gpupdate /force does is re-apply any GPOs that apply to the computer or user, so assuming nothing has changed since the last time policy updated and you didn’t have previous problems with policy applying to that machine, nothing should change just by doing that, but that’s a generalization at best. Your best bet is to schedule it during an outage window so you can handle anything that might happen.
    Darren

    Reply »
Steve Leeper —

Thank you Darren. I will take your advise and do it during off time. Thank you for the quick response. And thank you for the Understanding the Group Policy GPUpdate Command post. It was very helpful to me.
Steve

Reply »
William Lister

We still use XP at the facility I work. I have recently written a script that pushes xpsp3 to a remote machine. We have had to resort to doing this through vbscript because our McAfee security stops the sp3 install when using other methods. My script has no problem turning the McAfee service off, however, depending on where the Group Policy Refresh is at on the remote pc McAfee can get turned back on with group policy.

My question is: Is there a way to query a machine to know when it will do another scheduled Group Policy Update?

That way I could send a scheduled task to a machine to turn the McAfee service back off at the correct time.

Reply »
    Darren Mar-Elia

    on Win7 you could definitely get the next GP refresh time (or at least approximate it) out of the event log. On XP, if I recall, the only place that is recorded is within the userenv.log when it’s enabled for verbose logging. So you would have to parse that log, after turning it on, and determine the latest refresh and the next refresh time. Not trivial but do-able.

    Darren

    Reply »

Share Your Thoughts!

Copyright ©2013 SDM Software, Inc.
Site design by Social Media Ninjas | Sitemap