Performance Boosters
Besides the sheer number of GPOs that a computer or user object must deal with, numerous steps within the GPO-processing operation can affect the amount of time that a computer needs to boot or that a user needs to log on and gain control of the desktop. The ability to promptly resolve the required DNS names and locate a DC in the workstation's site also is important to good GPO-processing performance. The more time these basic setup tasks take, the more time GPO processing consumes. And if your XP or Win2K devices can't resolve the correct SRV records, GPO processing might fail outright.
Even basic GPO processing can be time-consuming. However, several Group Policy settings and features can affect GPO-processing performance. As Figure 1 shows, you can access client-side extension and Group Policy options through the Group Policy snap-in. Open the Group Policy console, then drill down to Computer Configuration, Administrative Templates, System, Group Policy. Select a policy in the right-hand pane and open the policy's Properties dialog box to view or modify the policy's settings. In particular, the policies that control slow-link detection, processing despite GPO version, and synchronous or asynchronous processing can affect performance significantly.
Slow-link detection. By default, the client-side extensions that control Folder Redirection, Software Installation, Scripts, and Disk Quota won't process a GPO when the workstation detects a slow link. Enabling slow-link detection means that fewer client-side extensions will work to process GPOs, so GPO-processing time will lessen under slow-link conditions. You can modify the default slow-link value of 500Kbps through the Group Policy slow link detection policy. (However, increasing the threshold to force slow-link detection isn't the best strategy for improving GPO-processing performance.)
GPO versioning. Each GPO's GPC and GPT contain the GPO's version number. Win2K increments this number each time you change the GPO. XP and Win2K workstations keep a history of each round of GPO processing in their local registries, under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History and HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History subkeys. By default, client-side extensions won't process a GPO if its version number hasn't changed. When a GPO's version number is 0 (meaning that no settings have been made within the GPO), the client-side extensions won't even attempt to process the GPO.
Forcing the client-side extensions to process all GPOs regardless of version number will increase processing time. From the Group Policy folder, select a policy from the right-hand pane, open the policy's Properties dialog box, select the option to enable the policy, and be sure the Process even if the Group Policy objects have not changed check box is cleared.
Asynchronous processing. By default, Win2K's GPO-processing operations are synchronous: All client-side extensions must finish processing any machine-based GPOs (at system boot) before the computer will present the logon dialog. Similarly, when a user logs on to a Win2K device, the client-side extensions that process user-level GPOs must complete their work before the user can get control of the desktop and start working. If the processing of many GPOs significantly delays system startup or user logon, you can configure Win2K to process GPOs asynchronously (through the Apply Group Policy for computers asynchronously during startup and the Apply Group Policy for users asynchronously during logon policies). However, a GPO that doesn't complete processing by the time a user logs on might not go into effect until the next time the user logs on—a lapse that could present a problem for Group Policy categories such as Software Installation and Folder Redirection. (XP includes a Fast logon optimization feature, so XP's GPO processing is asynchronous by default. Thus, the client-side extensions on an XP device might not finish processing all GPOs before a system presents the logon dialog box or lets a user access the desktop, and Software Installation and Folder Redirection typically require two logons before they take effect.)
Win2K also uses asynchronous processing for background refresh of Group Policy. Win2K periodically refreshes certain client-side extensions, such as those responsible for security settings and administrative templates, after the initial processing at boot or logon. For example, the client-side extension responsible for security settings on a Win2K server or workstation refreshes all applicable GPO settings every 90 minutes by default. On DCs, the default refresh interval is 5 minutes. This type of periodic processing limits the damage from users who muck with security settings between logons or reboots.
Not all client-side extensions support background refresh. For example, the Software Installation policy doesn't refresh (uninstalling Microsoft Word while someone is using it would be a bad idea). Also, client-side extensions won't refresh a GPO that hasn't changed. To prevent a GPO from refreshing, open a policy's Properties dialog box and select the Do not apply during periodic background processing check box. To change a device's overall background processing settings, enable and modify the Disable background refresh of Group Policy, Group Policy refresh interval for computers, or Group Policy refresh interval for domain controllers policy.
Although background processing doesn't have a big effect on your system's performance, you should be aware that it's happening. You can enable event logging for GPO processing so that you can monitor background processing and troubleshoot processing problems (see the sidebar "Group Policy Logging" for details).
Greater Control
Performance-enhancing behaviors such as slow-link detection, GPO versioning, and asynchronous-processing options are available in XP and Win2K. You can also explicitly tune a couple other settings to further reduce the overhead of GPO processing.
Disable unused settings. Within each GPO, you can define settings that apply to computers or to users. However, you don't need to define both within a given GPO. Therefore, the first and easiest step to enhance performance is to disable a GPO's unused computer-level or user-level settings. Suppose that a workstation determines during boot that it needs to process four GPOs, only two of which have a defined computer-level policy. You can flag the other two GPOs as not having any computer-level policy. As a result, the workstation's client-side extensions won't bother to look for the nonexistent computer-level settings, and you'll save some time in the processing cycle.
Register
