Optimize GPO-Processing Performance

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.