You can make decisions as you design and deploy your Group Policy Objects (GPOs) that will have an impact on how quickly your Windows desktops start and become usable to your users. Some of these decisions are obvious, while many are not. This post will guide you through some of the ways Group Policy can impact performance as well as some of the improvements we made for Windows 8.
This post (including the introduction) is a partial reproduction of a white paper written by one of our Group Policy MVPs, Darren Mar-Elia, with some additional comments and information. Darren has also written a free tool to help identity if your configuration might be susceptible to long logons.
This post covers:
- Foreground vs. background processing.
- Synchronous vs. asynchronous processing.
- GPOs with WMI filters.
- GPOs with scripts.
- Group Policy Preferences.
- Actions you can take in Windows 8.
Foreground vs. background processing
Foreground and background processing are key concepts in Group Policy. Foreground processing only occurs when the machine starts up or when the user logs on. Some policy areas (also called Client Side Extensions (CSEs)) can only run during foreground processing. Examples of these include Folder Redirection, Software Installation and Group Policy Preferences Drive Mapping. In contrast, background processing is that thing that occurs every 90 or so minutes on Windows workstations, where GP refreshes itself periodically. Background processing happens, well, in the background, while the user is working and they generally never notice it. While background processing doesn’t impact performance, foreground processing can extend start and login times. This post will be focusing on foreground processing.
Synchronous vs. asynchronous processing
Foreground processing can operate under two different modes—synchronously or asynchronously. The default foreground processing mode for Windows clients since Windows XP has been asynchronous. Asynchronous GP processing does not prevent the user from using their desktop while GP processing completes. For example, when the computer is starting up, GP asynchronous processing starts to occur for the computer, and in the meantime, the user is presented the Windows logon prompt. Likewise, for asynchronous user processing, the user logs on and is presented with their desktop while GP finishes processing. The user is not delayed getting either their logon prompt or their desktop during asynchronous GP processing. When foreground processing is synchronous, the user is not presented with the logon prompt until computer GP processing has completed after a system boot. Likewise the user will not see their desktop at logon until user GP processing completes. This can have the effect of making the user feel like the system is running slow. In short, synchronous processing can impact startup time, where asynchronous does not.
Foreground processing will run synchronously for two reasons:
1) The administrator forces synchronous processing through a policy setting. This can be done by enabling the Computer Configuration\Policies\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon policy setting. Enabling this setting will make all foreground processing synchronous. This is commonly used for troubleshooting problems with Group Policy processing, but doesn’t always get turned back off again.
2) A particular CSE requires synchronous foreground processing. There are four CSEs provided by Microsoft that currently require synchronous foreground processing: Software Installation, Folder Redirection, Microsoft Disk Quota and GP Preferences Drive Mapping. If any of these are enabled within one or more GPOs, they will trigger the next foreground processing cycle to run synchronously when they are changed.
Action: Avoid synchronous CSEs and don’t force synchronous policy. If usage of synchronous CSEs is necessary, minimize changes to these policy settings.
GPOs with WMI filters
If you must use a policy setting that triggers synchronous processing, another area to take note of is the use of WMI filters. A WMI filter does not automatically slow down GP processing appreciably, but if a WQL query implemented in that filter is time consuming, it could slow down the startup or logon process, This is true especially if that workstation is running Group Policy processing synchronously. A few long-running queries can extend the amount of time it takes to finish processing Group Policy. Costly WMI filters include those that rely heavily on network traffic, such as LDAP queries.
Action: Avoid costly WMI filters such as LDAP queries
GPOs with scripts
As with WMI filters, long-running scripts might impact performance during synchronous processing. Startup or logon scripts are not by themselves always a problem. But too many scripts running for a given user or computer, or scripts that hang or are no longer really in use, can add to startup and logon times. Frequently, people don’t recognize the number of scripts that are present. Try looking through your environment for startup or logon script policies and reviewing them to ensure they are responding (scripts that aren’t responding will not timeout for 10 minutes, by default) or otherwise taking a long time to execute.
Action: Look for costly scripts by running them in isolation and work to improve the scripts’ performance or avoid these scripts
Group Policy Preferences
GP Preferences settings that use Item- Level Targeting (ILT) are not inherently harmful. However, certain kinds of Item Level Targeting queries can take more time to run. You can find these targets in any Group Policy Preferences setting under the Common tab. Costly ILT evaluations include all of the ILT types that must work over the network against AD to be evaluated: OU, LDAP Query, Domain, Site and Computer Security Group filters.
Actions:
- Don’t run ILT evaluations such as OU, LDAP Query, Domain, Site, or Computer Security Groups.
- If you need to use security group filters, consider this KB article.
Similarly, Group Policy Preferences Printers can take some time to install a printer driver. If a printer item is set to “replace,” it will re-install the printer driver every time it runs. If you are deploying several printers at once, this can add up quickly. Instead of “replace,” consider using “create” or “update.”
Action: Don’t use “Replace” with Group Policy Preferences Printers.
Actions You Can Take in Windows 8
We made changes in Windows 8 to give greater control over synchronous processing. Synchronous processing takes longer over slow networks, because Group Policy makes many requests to domain controllers when applying Group Policy. To mitigate this effect, we added an option to allow computers or users on a slow network connection to avoid processing any CSEs that require synchronous processing. All other policy settings will apply as normal. Those synchronous policies that were skipped while on a slow network will take effect the next time a user or computer is on a fast network (as usual).
You can find this policy setting in Computer and User configurations under Policies -> Administrative Templates -> System -> Group Policy -> Change Group Policy Processing to run asynchronously when a slow link is detected
The Configure slow link detection policy setting in the same path allows you to configure the threshold at which Group Policy determines a link is slow. Slow link detection raises event 5314 in the Group Policy Operational Log (Located in the Event Log Viewer under Applications and Services Logs -> Microsoft -> Windows -> Group Policy) . Checking this event will show if Group Policy has detected a fast or slow link, as well as the detected bandwidth, and the threshold that has been set.
Action: Disable synchronous logins when on a slow link
Summary
Windows 8 provides new mechanisms to help reduce the impact of synchronous processing. By utilizing available tools and being aware of the necessary difference in the design and deployment of GPOs you can substantially improve your user’s desktop startup experience.
Actions you can take to improve Group Policy performance:
- Avoid synchronous CSEs and don’t force synchronous policy, or if CSE usage is necessary, minimize changes to these policies.
- Avoid costly WMI filters such as LDAP queries.
- Look for costly scripts by running them in isolation, and work to improve the scripts’ performance or avoid these scripts.
- Don’t run ITL evaluations such as OU, LDAP Query, Domain, Site, or Computer Security Groups.
- If you need to use security group filters, consider this KB article.
- Don’t use “Replace” with Group Policy Preferences Printers.
- Disable synchronous logins when on a slow link.