I would also try logging into the device as another user and run the gpupdate /force and see if you get the same issues. This will also allow you to see if it is a user issue, device issue or server issue. Please let me know how you go with this so I can provide more solutions for you to try.
When to use the /force switch with gpupdate
I’ve seen that question a couple of times and thought I’d write a few lines on this.
- Gupdate.exe file information Gupdate.exe process in Windows Task Manager. The process known as gupdate.exe belongs to software gupdate by unknown. Description: Gupdate.exe is not essential for Windows and will often cause problems. The file gupdate.exe is located in a subfolder of 'C:Program Files (x86)' (usually C:Program Files (x86)Companygupdate).
- In this guide, you will learn how to use the GPResult command line tool to verify what group policy objects are applied to a user or computer. If your using group policy in your environment then you definitely should know how to use this tool.
- When the scan is finished, locate GpUpdate.exe in the scan result and tick the checkbox next to the GpUpdate.exe file. Do not check any other file for removal unless you are 100% sure you want to delete it. Tip: Press CTRL-F to open up FreeFixer's search dialog to quickly locate GpUpdate.exe in the scan result.
- Running GPUpdate or rebooting the computers is not efficient in a large environment so these options simply don’t scale. Changing the Group Policy Refresh Interval. An interesting coincidence is that the policy that configures this setting is itself built into Group Policy! You just need to know where it is and what the valid settings are.
GPUpdate is a command line based tool that comes with Windows since Windows XP and is used to manually refresh Group Policy on the client. From the help, you can see that there’s a /force switch. That switch seems to confuse some people.
First, let’s see how clients apply Group Policy on a regular basis. For every Group Policy, there’s a bunch of files located on the SYSVOL share in each policy’s folder. One of those files is called GPT.INI. Inside GPT.INI there’s a variable called “Version” that has a specific value. More on this on the GP Team’s blog: http://blogs.technet.com/grouppolicy/archive/2008/01/08/understanding-the-domain-based-gpo-version-number-scripts-included.aspx
Every time you edit a Group Policy, the value of that version variable in GPT.INI gets incremented. This is how clients notice that there is a change with one of the GPs they apply. On startup, clients check what version number they last updated the GP on and, if the version number has increased, they re-apply the whole policy. If the version number the client had cached is equal to the number the SYSVOL stores, the policy isn’t reapplied as it hasn’t changed since the last application.
Now, how does that relate to gpupdate? When GPUpdate (without the /force switch) is called, it does the very same things a client does when it checks for new Group Policy. It compares its cached version numbers for all its GPs with the version numbers on SYSVOL. If one of the version numbers on SYSVOL has incremented/is newer than the locally cached one, it obviously has changed and the GPO therefore gets applied right away.
What does /force do? The switch makes the client machine ignore version numbers completely. When running gpupdate /force, the client re-applies all GPs the machine and user are targets of. All of them. Not just the ones that were updated recently, the whole load. Obviously, that can lead to increased network traffic and load on DCs when used too often or on a wide number of clients.
It really is *not* recommended to use the /force switch in a startup script or any other kind of maintenance procedure that occurs too often. If there’s a situation you see “gpupdate /force” working on a client so that it applies a changed GP while “gpupdate” doesn’t, there’s obviously something wrong with the data on SYSVOL. I’d check replication then and see whether the version number for the Group Policy has a correct value. Either SYSVOL replication hasn’t worked correctly or there was a problem increasing the version number of the GPO. Either case should be checked.
Using the /force switch should be a temporarily measure of troubleshooting and testing, not a long-term solution to get broken GPs applied.
I teach several classes that cover Windows deployment, operations, and troubleshooting. Most of the content I teach is focused on enterprise environments – that is, generally, more than 5,000 systems. At that scale centralized IT management is a requirement, not an option. And the cornerstone of centralized computer configuration management in Windows are Active Directory and Group Policy.
Many of my students relate stories of making changes to Group Policy settings. Usually the story goes something like, “We needed to change the screensaver timeout period to kick in after 5 minutes for the HR department. So I edited the Group Policy and under User Configuration, Administrative Templates, Control Panel, Personalization, I set the ‘Screen saver timeout’ to 600 seconds. Then I ran GPUpdate /force on the HR computers to get the setting.” A common alternate ending to that story is replacing the GPUpdate /force command with rebooting the computer.
Neither rebooting the computer nor running GPUpdate /force are necessary. Group Policy updates happen all by themselves.
Group Policy Updates Itself
Yup, the Group Policy service on all domain-joined client computers regularly checks with Active Directory to see if anything has changed. If new or changed policies exist, they are applied to the computer. By default, Group Policy updates every 60 to 120 minutes, as well as during system startup.
The most efficient way to ensure faster application of Group Policy changes is to change how frequently the client checks with a domain controller. This uses the existing timing and infrastructure already built in to Group Policy. Running GPUpdate or rebooting the computers is not efficient in a large environment so these options simply don’t scale.
Changing the Group Policy Refresh Interval
An interesting coincidence is that the policy that configures this setting is itself built into Group Policy! You just need to know where it is and what the valid settings are.
The setting is in Group Policy under Computer ConfigurationAdministrative TemplatesSystemGroup Policy. There are two separate settings:
- Group Policy refresh interval for computers configures all non-domain controller systems within the scope of the policy. By default this is set to every 90 minutes with a random time offset of 0 to 30 minutes, resulting in a refresh interval of 60 to 120 minutes per computer.
- Group Policy refresh interval for domain controllers targets only domain controller systems within the scope of the policy. By default this is set to every 5 minutes with no random time offset.
Change those settings and each computer will use the new settings beginning with the next Group Policy refresh.
Don’t Set the Refresh Very Low
Some administrators might want to crank this setting down as low as it will go to have computers update policy as fast as possible. That’s a really bad idea.
The policy refresh consumes resources on the client, the network, and the domain controller. The more frequently it runs, the more resources it consumes. The documentation defines the fastest possible refresh interval at 7 seconds. That setting will most likely result in unusable computers and CPU-bound domain controllers in very short order. In my experience, setting the computer interval to 60 minutes and reducing the offset to 10 minutes is sufficient to meet any regulatory or IT policy requirement while avoiding resource starvation on the systems.
Good luck and be careful with this one!
Mike Danseglio -CISSP / CEH
Interface Technical Training – Technical Director and Instructor
You May Also Like
How Long Does Gpupdate Take
Active Directory, Domain Controllers, GPUpdate, Group Policy, Group Policy Deployment, Group Policy refresh interval, Group Policy refresh interval for domain controllers, Group Policy Updates