Taking Control of Group Policy

Managing any Windows environment can be a challenging task. Features such as Group Policy, which lets administrators control a domain's clients (i.e., computers and users), are both welcome and useful. But many administrators apply security policies only after events occur that signal the need for a policy. Such events might involve a user who wreaks havoc on a computer's configuration or who changes a setting that results in domainwide problems.

When an administrator applies policies on an as-needed basis, the result is often a hodgepodge of many policies. Having too many policies can increase the logon time for client machines, ultimately annoying users. Too many policies can also result in conflicting policies that prevent some users from performing needed tasks and let other users, who should be restricted, perform tasks that affect the domain. The quick cure to these types of problems is to set yet another policy to correct the error, which of course makes everything worse.

You can, however, set policies in a way that maintains order. By planning ahead and taking steps to reduce the number of policies you need, you can avoid many of the pitfalls that administrators typically encounter when applying policies.

Use Fewer Policies More Effectively
When a Windows Server 2003, Windows XP, or Windows 2000 computer that's a member of a domain starts, the system processes and applies both domain and local computer-based policies. Then, when a user logs on to the domain from that computer, the system processes and applies both domain and local user-based policies. Because each policy takes time to apply, users can experience a significant delay between the time the computer starts and the time they can begin working. This delay is directly proportional to the number of physical policies (aka Group Policy Objects—GPOs) associated with the domain, site, or organizational unit (OU) that the system must process. You can minimize this delay by applying one or more of the following principles:

Apply policies to OUs. If you add computers to OUs, you can apply policy settings more effectively and at a more granular level than domainwide policies afford. For example, you can apply specific GPOs to all members of a particular OU and use those GPOs as a condition of membership for joining that OU. An added benefit of applying GPOs to OUs is that you minimize the need to process unnecessary GPOs. To create a GPO for an OU, perform the following steps:

Filter policies according to security group memberships.
Although many policies aren't relevant to particular security groups, an administrator can still allow or deny GPOs according to security group memberships. Many professionals in the field consider this alternative to the "apply policies to groups" paradigm to be the backdoor approach that they wish Microsoft had built into Active Directory (AD). To filter policies according to security group memberships, perform the following steps:

For example, if you create a policy to expand user rights, you might want to select the Allow option for the Apply Group Policy permission only for administrative security groups. If you create a policy to restrict user rights, select the Deny option for administrative security groups (to preserve administrators' rights) and select Allow for all other users.

Disable unused GPO sections. All GPOs have a Computer Configuration section and a User Configuration section. If the policy that you want to apply affects only the computer profile or only the user profile, but not both, you can configure the GPO so that the system doesn't spend time processing the unused section. To disable an unused GPO section, perform the following steps:

Process policies asynchronously. Windows provides a way to speed up the enumeration of GPOs during machine start-up and user logon. In my experience, this feature has little value in enterprises that apply several GPOs to both the computer and the user. However, if your users are complaining about the amount of time they spend starting their computers and logging on to the domain, you might want to experiment with this feature.

When Windows starts, the system by default processes policy settings from the Computer Configuration section of each GPO synchronously in the following order: Local, Site, Domain, OU. After processing all the computer-based policies, the system prompts the user to log on to the domain. Then, the system processes user-based policies synchronously in the same order that it processed the computer-based policies.

To speed GPO processing and thereby speed user logon, you can tell Windows to apply policies asynchronously instead of synchronously. Processing the policies asynchronously means that the system can download and process the policies out of order. In fact, users can log on to the domain and have use of the computer before the system has the chance to apply all policy settings—and therein, of course, lies the danger. Because the system processes OU policies last, many administrators make sure that any "real" policies (i.e., those that override domainwide policies) are in the computer's OU. However, if you process policies asynchronously, you lose that advantage.

If you're reasonably sure you don't have conflicting policies (e.g., OU policies that conflict with domain or local policies), you can experiment with asynchronous policy application. To enable asynchronous policy processing with a GPO, perform the following steps:

Incidentally, you don't have to select both policy types in Steps 5 and 6 for asynchronous processing; you can select just computer-based policies or just user-based policies if you want.

Managing Existing Policies
As I've discussed, applying policies to OUs, filtering policies by security group memberships, disabling unused GPO sections, and processing policies asynchronously can help you manage new policies. But if you're past the point of creating your first GPO, you might already have a tangle of policies that can lead to bigger problems. Logons can become slow, which can cause users to complain. More important, conflicting policies sometimes cause administrators to lose sufficient rights to perform tasks. Worse, you probably aren't sure which policies you've set because GPE doesn't tell you what you've done. Fortunately, Windows provides some tools to help you determine the state of your GPOs. In a future column, I'll discuss these tools and offer some suggestions for unsnarling your GPOs.