Optimize GPO-Processing Performance

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:

1. 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.
2. The workstation establishes a secure-channel connection with the DC.
3. 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.)
4. The workstation binds to AD over LDAP.
5. The workstation uses LDAP to query AD and get a list of all the GPOs linked to the workstation's OU or parent OU.
6. The workstation uses LDAP to query AD and get a list of all the GPOs linked to the workstation's domain.
7. The workstation uses LDAP to query AD and get a list of all the GPOs linked to the workstation's site.
8. The workstation uses LDAP to query the GPC (in AD) and determine the path to each GPO's GPT (in Sysvol).
9. The workstation reads the gpt.ini file that resides in each GPO's GPT. This file lists the GPO's current version number.
10. 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).