If you've deployed Active Directory (AD), you know the benefits that it brings to your Windows environment. Among these benefits is the use of Group Policy Objects (GPOs)—powerful tools for managing your Windows 2000 servers and your Windows XP and Win2K workstations. As with any technology, however, too much of a good thing can hurt your systems' performance. You can link GPOs to multiple levels of your AD hierarchy, so a particular computer or user in your infrastructure might be subject to tens of GPOs at system startup or at logon. The result: long startup and logon times while your systems complete GPO processing.
To manage GPO processing and optimize your GPO infrastructure so that the impact on your systems and users is minimal, you need to understand how Win2K stores and applies GPO settings, how you can adjust those settings, and how to design an effective yet efficient Group Policy infrastructure. (This article assumes that you already have some knowledge about using GPOs in an AD environment. For primers about GPOs and their capabilities, see Randy Franklin Smith, "Controlling Group Policy, Part 2," Winter 2000, InstantDoc ID 15886, and "Controlling Group Policy, Part 1," November 2000, InstantDoc ID 15704; and Michael D. Reilly, Getting Started With Win2K, "Group Policy," March 2000, InstantDoc ID 8144.)
GPO-Processing Basics
You link GPOs to container objects (i.e., sites, domains, or organizational units—OUs) within AD, and all user and computer objects under that container process those GPOs. This process can be complicated because user and computer objects must process any GPOs that you link to the domain, parent and child OU, and site in which the object resides. You can link one GPO to multiple container objects, or you can link multiple GPOs to one container object. The former situation has little effect on GPO-processing performance, but the latter situation makes all the difference in the world. The more GPOs that a given computer or user must process, the more time the computer needs to boot or the user needs to log on.
Win2K stores a GPO's settings in two places: the GPO's Group Policy Container (GPC) in AD, and the GPO's Group Policy Template (GPT) within the Sysvol share on your domain controllers (DCs). The process of creating a new GPO through the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in or the MMC Active Directory Sites and Services snap-in creates the GPC and GPT and links the GPO to the selected container object. When you use the MMC Group Policy snap-in to change a GPO, your actions modify both the GPC and the GPT.
Processing the settings in the GPC and GPT is the job of a set of DLLs called client-side extensions. Your XP and Win2K workstations' local registries reference these client-side extensions in separate subkeys under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions subkey. The values in each globally unique identifier (GUID)-named subkey list the name of the DLL, the Group Policy processing category that the extension provides (e.g., Folder Redirection, Software Installation), and the settings that control the extension's behavior. These settings determine, for example, whether the extension will process a GPO when the computer connects to the DC over a slow network link, whether the extension will refresh policy settings periodically, and whether the extension will process GPOs that haven't changed since the last processing time.
Client-side extensions are the primary worker bees of GPO processing. But certain network interactions must occur before a client-side extension can do its work. Network communications usually represent a significant portion of your servers' and workstations' total GPO-processing time. When a Win2K workstation boots in an AD domain that contains GPOs, the following processes take place:
- The workstation queries a DNS server to locate a DC in the workstation's site. To be precise, the workstation queries DNS for the _ldap._tcp.sitename._sites.dc._msdcs.domain-name SRV record. This record returns the name of the DC (in the site sitename) that handles Lightweight Directory Access Protocol (LDAP) requests for the domain.
- The workstation establishes a secure-channel connection with the DC.
- The workstation pings the DC to determine whether the workstation's network connection to the DC (e.g., dial-up, T1) constitutes a slow network link. (By default, Win2K considers a transfer rate of less than 500Kbps to be slow. See the Microsoft article "How a Slow Link Is Detected for Processing User Profiles and Group Policy" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q227260 for information about how Win2K calculates slow links.)
- The workstation binds to AD over LDAP.
- The workstation uses LDAP to query AD and get a list of all the GPOs linked to the workstation's OU or parent OU.
- The workstation uses LDAP to query AD and get a list of all the GPOs linked to the workstation's domain.
- The workstation uses LDAP to query AD and get a list of all the GPOs linked to the workstation's site.
- The workstation uses LDAP to query the GPC (in AD) and determine the path to each GPO's GPT (in Sysvol).
- The workstation reads the gpt.ini file that resides in each GPO's GPT. This file lists the GPO's current version number.
- The workstation's client-side extensions process the retrieved GPOs.
These steps represent the processing of only computer-specific GPOs, which occurs at computer boot. After a user logs on to the system, Win2K must process any user-specific GPOs. During that procedure, the OS repeats Steps 4 through 10 (from a network perspective, Steps 1 through 3 have occurred already).
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.
To disable a GPO's computer- or user-level settings, open the Active Directory Users and Computers snap-in or the Active Directory Sites and Services snap-in, right-click the container to which the GPO is linked, then choose Properties from the context menu. Go to the Properties dialog box's Group Policy tab. Select the GPO and click Properties to open the GPO's Policy Properties dialog box. Use the check boxes in the Disable section to disable unused computer or user configuration settings. (You can select both check boxes, but doing so effectively disables the GPO.)
Set a maximum wait time. Another way to keep GPO-processing times in check is to establish a maximum interval for running scripts. GPOs support computer startup and shutdown scripts as well as user logon and logoff scripts. Such scripts can be any form of executable, batch file, or Windows Script Host (WSH) script. Because you can apply multiple GPOs to a given user or computer, you might have multiple scripts running one after the other. But ill-functioning or poorly programmed scripts could hang or run forever. For example, when you use synchronous GPO processing, your XP and Win2K systems might hang for as many as 10 minutes, and you have no easy way to determine the problem.
To mitigate this type of problem, you can set a maximum time for all scripts to run. In a worst-case scenario, a script that is hung or caught in some kind of loop will run for only the specified time. Be aware, however, that the wait time applies to the total runtime of all scripts. For example, if you've defined logon scripts in each of 10 GPOs in your AD domain and you set the wait time to 60 seconds, all those scripts must be completely executed within 60 seconds. To specify a maximum script-processing interval, open the Group Policy snap-in, drill down to Computer Configuration, Administrative Templates, System, Logon (or Administrative Templates, System, Scripts in XP), and open the Maximum wait time for Group Policy scripts policy's Properties dialog box, which Figure 2 shows. You can enable the policy and configure the wait time on the Policy tab.
Design Matters
Aside from tweaking Group Policy behaviors, you can mitigate or prevent performance problems through a well-planned Group Policy infrastructure. Limiting the number of GPOs you create, the security groups you use, and the cross-domain GPO links you establish can speed up processing time.
Limit GPOs. The most basic step is to limit the number of GPOs that a computer or user must process at startup or logon. In general, I suggest limiting this number to 10 as a starting point, but you need to test this number for yourself because it depends heavily on what each GPO does. Also keep in mind that wait times are longer the first time a computer or user processes a GPO because the client-side extensions must initially apply all the settings. After the initial processing cycle, subsequent system restarts or user logons will process only GPOs that have changed (unless you force them to do otherwise).
Limit security groups. The use of security groups (i.e., AD local, global, or universal groups containing computers or users) can affect GPO processing. You can use security groups to filter GPOs' effects—for example, when you want to apply a domain-level GPO to only a handful of users or computers. However, security-group filtering comes with a performance cost. The more access control entries (ACEs) you associate with a GPO, the more work the GPO's client-side extension must do to figure out whether a computer or user belongs to one of the groups to which you've applied filtering. Thus, keeping your GPOs' ACLs short and concise further improves (or at least maintains) performance. Don't use ACLs indiscriminately to filter GPOs for every computer or user. Instead, rethink the level at which you're linking your GPOs. You might get the desired effect by relinking the GPO lower in your AD hierarchy (e.g., at the OU level rather than the domain level).
Limit cross-domain links. Another design aspect that can play a role in performance is the use of GPOs that are linked across domain boundaries. Every GPO belongs to one AD domain, and the GPO's GPC and GPT reside on that domain's DCs. Suppose you have a multidomain AD forest. You could link a GPO in one domain (Domain A) to another domain in the forest (Domain B). But when a computer or user in Domain B processes the GPO that resides in Domain A, the client-side extensions on the Domain B computer must traverse trust relationships within the forest to access the GPO's GPC and GPT. Such an operation is more expensive from a performance perspective than communicating with GPOs within the same domain. Furthermore, if the Domain B computer can't find a Domain A DC within the same AD site, the computer might need to traverse WAN links to reach a DC and process the GPO.
The best solution is to avoid linking GPOs across domain boundaries. Instead, copy a defined GPO from one domain to another. (XP and Win2K don't provide an easy way to copy GPOs from one domain to another, but third-party tools can provide such functionality.)
GPOs: Complex but Powerful
GPOs can be powerful tools in your Windows systems-management arsenal, but GPO configuration and behaviors are complex and can slow down system startups and user logons. Armed with the knowledge of how to modify GPO behavior and infrastructure to improve GPO-processing time, however, you can minimize GPO performance penalties—and get the most out of your AD infrastructure.
