Speeding Up Group Policy Updates in Deployment
Speeding Up Group Policy Updates in Deployment
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 Configuration\Administrative Templates\System\Group 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!
You May Also Like
In this Office 365 training video, instructor Spike Xavier demonstrates how to create users and manage passwords in Office 365. For instructor-led Office 365 training classes, see our course schedulle: Spike Xavier SharePoint Instructor – Interface Technical Training Phoenix, AZ 20347: Enabling and Managing Office 365
One of the coolest new features in Window Server 2012 and Windows Server 2012 R2 is the ability to clone a Domain Controller. In the past, if we had virtualized Domain Controllers and we actually took a snapshot of it and then rolled back to that snapshot, it would break the logon service on that … Continue reading How to clone a Windows Server 2012 or 2012 R2 Domain Controller
How does an investigator hunt down and identify unknown malware? In this recording of our IT Security training webinar on April 21, 2015, Security expert Mike Danseglio (CISSP / CEH) performed several malware investigations on infected computers and identify symptoms, find root cause, and follow the leads to determine what’s happening. He demonstrated his preferred … Continue reading Detailed Forensic Investigation of Malware Infections – April 21, 2015