Most enterprise IT administrators have had to deal with users complaining about delays with logging into their...
computers in the morning. This is because of foreground synchronous Group Policy processing, which can steal the focus from the user interface and grind Windows to a halt while it changes certain managed settings or installs software that requires a network connection.
This is especially likely to happen on a new machine that has just been deployed, and users may report long pauses and spinning progress wheels as Windows alters settings like folder redirection. The operating system can also hang while installing software through Group Policy and Microsoft Installer (MSI) packages, which require application before anything can happen on the user side.
So while you might think you are in network management nirvana because you pushed out Office 2010 via Group Policy without messing around with full fat deployment systems, you have really just made sure that no one downtown can do anything on Monday morning for three hours while everyone applies your Group Policy object (GPO).
Back in Windows XP, Microsoft introduced fast logon optimization, which took a bunch of GPO processing that was previously required to work in real time and transformed those processes into ones that could be churned through in the background. This let users get from power switch to desktop in a fraction of the time it took in Windows 2000 and before.
Generally, this background processing happens every hour and a half for workstations, client machines and servers and every five minutes for domain controllers, although admins can change this by altering the Set Group Policy Refresh Interval setting.
However, implementing fast logon optimization in the real world ended up causing some behavior that not all desktop admins liked. Specifically, some GPOs wound up not getting applied for three or four restarts because of the way the algorithm looking for new GPOs was written. It was especially inconvenient when deploying new computers because this setting is always off during a user's first logon to a computer, so multiple restarts are required to get full policy application for every single new computer deployed.
Thus, some administrators turned on the "Always wait for the network at computer startup and logon" setting, which you can find by opening Group Policy Object Editor and navigating through the following tree: Computer Configuration\Administrative Templates\System\Logon\ Always wait for the network at computer startup and logon.
Windows 8.1 and Windows Server 2012 R2 now let the operating system pull these policies down in the background -- the actual data of the policy, mind you, not the application of the policy itself. Upon logon, even when foreground synchronous Group Policy processing is required, the user does not have to wait while the policy data is downloaded from the domain controller.
The user must still be connected to the corporate network and must be able to contact the domain controller, as always, for the policy to actually be applied, but the cache itself speeds up logging on to and starting up the computer.
Also, once processing from the cache begins, it will not stop during that policy application session, even if the policies themselves on the domain controller are updated. You will have to wait around for the next restart or logon for the new settings to take effect.
To enable Group Policy caching in Windows 8.1 and Windows Server 2012 R2, choose a new or existing GPO, open the Group Policy Object Editor, and navigate through the Computer Configuration\Administrative Templates\System\Group Policy tree to arrive at "Configure Group Policy Caching." You can leave it unconfigured, enable it or disable it. There are also two options:
- The slow link value, which tells Windows how long to wait for the domain controller to respond before skipping new applications and reverting to slow link speed policy application (which delays network-intensive GPOs such as software installations); and
- The timeout value.
If caching is enabled, then Windows 8.1 and Windows Server 2012 R2 store the contents of the cache in the user profile directory, which by default is C:\Users\username\AppData\Local\GroupPolicy\DataStore\o\SysVol\yourADdomainname\Policies. The GPOs each have globally unique IDs, or GUIDs, and the data for each is stored in a folder named for each GPO's GUID.
Provide users a standardized Windows 8.1 Start screen via Group Policy
Microsoft offers two ways to remotely refresh Windows 8 Group Policy settings
Lock down Internet Explorer 11 with Group Policy
Group Policy gives admins control over the Windows 8.1 Control Panel
Configure Windows 8, UI with Group Policy settings
Why admins should have Windows 8 AppLocker in their toolboxes