Group Policies and their impact on User Logon
Group Policy Objects (GPOs) have an impact on how a user’s desktops starts and become usable to your users.
The following are the main topics when we discuss GPO and should not be left:
- Foreground vs. background GPO processing.
- Synchronous vs. asynchronous GPO processing.
- GPOs with WMI filters.
- GPOs with scripts.
- Group Policy Preferences.
1) Foreground and Background GPO processing.
Foreground and background processing are key concepts in Group Policy. Foreground processing comes into practice only when a computer boots up or when a user logs on.
Client Side Extensions or CSEs only run during foreground processing. Folder Redirection, Software Installation and Group Policy Preferences Drive Mapping are common examples of CSEs.
Background processing occurs continuously on Windows workstations, when group policies refresh itself periodically http://msdn.microsoft.com/en-us/library/ms813077.aspx. Background processing occurs while the user is logged on and working and doesn’t even notice the background processing.
Background processing doesn’t impact the system performance or the user never notices anything, foreground processing impacts start-up times for systems and logon times for users.
Foreground Processing is further explained in the below points :-\
2) Synchronous and Asynchronous GPO processing.
Foreground processing operates under two different modes—synchronous or asynchronous. Asynchronous processing has been the default foreground processing mode for Windows clients. Asynchronous GP processing allows the user to use their desktop during the GP processing completes. While a computer boots up, GP asynchronous processing is already into action for the computer, and Windows logon prompt appears for the user. During the asynchronous user process, when a user logs on and their desktop appears while the GP finishes processing. The user is not delayed during their logon process or reaching their desktop during asynchronous GP processing.
When foreground processing works in the synchronous mode, the user does not receive the logon prompt until computer GP processing has completed after a system reboot. The user does not get to their desktops at logon until user GP processing completes. This can have the effect of making the user feel as if the system is running slow. In short, synchronous processing can impact startup time, where asynchronous does not.
Foreground processing can run synchronously if :
- a) 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.
- b) A particular CSE requires synchronous foreground processing. Eg. Software Installation, Folder Redirection, Microsoft Disk Quota and GP Preferences Drive Mapping.
Best Practice: Avoid synchronous CSEs and don’t force synchronous policy. If usage of synchronous CSEs is required, try to minimize the changes to these policy settings.
3) 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. http://technet.microsoft.com/en-us/library/cc779036(v=WS.10).aspx 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.
4) GPOs with scripts
Longer running scripts 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.
5) 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.
Best Practice : Don’t run ILT evaluations such as OU, LDAP Query, Domain, Site, or Computer Security Groups.
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.”
Best Practice: Don’t use “Replace” with Group Policy Preferences Printers.