How to Administer Group Policies

Group policy administration represents a task of potentially great complexity. With careful design and some initial simplicity, using Active Directory and group policies to administer your enterprise environment provides a manageable environment. Creating a multi-level OU structure and a variety of GPOs can lead to a complex login and startup structure that can increase administration and make problem resolution almost impossible. The upcoming example depicted later in this chapter suggests that complexity increases rapidly. Although this example has a GPO for each feature that is implemented for demonstration purposes, one can imagine a number of GPOs for different profile users. A well thought-out design is critical in developing a functional environment. In our experience, is is best to start with a simple group policy approach.

Creating GPOs

After you have decided on the GPOs needed for your organization, you need to create them. GPOs are typically associated with SDOUs. It is also possible to create a local GPO for standalone machines. If you are creating a GPO, you need to associate the GPO with one of these objects. There are two main ways to start to create a GPO for domains and OUs. The first way is to start with the MMC and add the group policy snap-in. A wizard comes up that asks you to identify the SDOU in which you want the GPO to reside. The other way is to start the Active Directory Users and Computers administration tool. With this tool, you traverse the OU structure to where you want the GPO to reside. By right-clicking on the object (an OU, for example) you are given a list of the tasks you can perform. By selecting properties, you receive all the properties for the OU object. A group policy tab appears, providing you with all the tasks for a single GPO administration. You are able to create a new GPO; edit a GPO; and review, delete, or modify the properties of a specific GPO.

For a GPO at the site, you use the Active Directory Sites and Services snap-in. With this tool, you select the site for which you want to create a GPO, and then right-click and select Properties. The Properties page appears and at the top, there are tabs. You select the group policy tab. From this dialog box, you are able to create, edit, and remove GPOs for the site.

When you are starting out, you select the New button to create the GPO. After you have named the object, you are ready to edit the object. This is accomplished by selecting the Edit button. The Edit button triggers another MMC tool that contains the defaults for a GPO. You can then traverse the GPO and modify the entries. This establishes a GPO.

Now that you have a GPO established with the specific setting required for your computer and user settings the next level of execution of a GPO is to implement whom and what receives the GPO assigned to it. By default, all users and computers receive group policies based on the OU in which they reside. A GPO applied to an OU is applied to the objects within that OU (subject to access control list [ACL] settings) and to the objects within all child OUs located within the OU.

Controlling the Way That GPOs Are Applied

You now have a GPO created. This GPO has impacts on computer settings and user settings. After some experience using the GPO you determine that a specific OU could need different user-based GPOs. Each user-based GPO permits a different set of applications to be distributed to the workstation.

To control which GPO is applied to a user or group, you select the GPO and click the Properties button. Under the Security tab, you can configure a list of users and groups. For each user or group added, you can apply permissions. The permissions that affect whether a GPO is applied to a set of users are the Apply Group Policy permissions (Apply) and the Read Group Policy permissions (Read). If Allow is selected for both the Apply and Read permissions, it is applied. A sample is depicted in Figure 9.3. In this case, all users in the Authenticated Users group have the GPO applied.

There are other possible scenarios using these settings. If the Apply and Read permissions are set to Deny (regardless of the participation the members have in other security groups), this GPO is not applied. If the permissions for Apply and Read are not both set, nothing happens for the users of the security group. The GPO is neither applied nor explicitly denied.

Also note in Figure 9.3 that the permissions, such as read, write, create all child objects, and full control, are used to control who has the ability to administer the GPO itself.

GPOs: Order of Application

In a single container, there can be multiple GPOs. The GPOs are implemented based on the order they appear in the group policy tab for that container, from the bottom up (lowest to highest priority). The lowest GPO in the list is applied first. The implication here is that if every GPO has a policy setting to enable and the top GPO has the setting to disable, the final GPO—the top one—is applied and the policy is disabled. A view of this list is in Figure 9.4.

Special Case Application of GPOs

At this point in the application of group policies, there is functionality that is capable of handling most every scenario. You have group policies that can be applied at multiple levels in your Active Directory. You also have the ability to restrict application of a group policy. There is also a straightforward, top-down approach to applying group policies.

However, as is the case with the rest of Active Directory, Microsoft is providing a broad range of options and features. In the case of group policy, there is no difference. There are ways to create controlled exceptions to the standard rules for the application of a GPO.

No Override

A No Override button can be selected for a GPO. No Override provides the administrator with the ability to prevent other GPOs from overriding the settings in a selected GPO.

Block

The Block configuration setting blocks inheritance from parent-level OU settings from affecting an OU. As an example, a regional OU might want to prevent the distribution of an application to their OU until the users in their region have been trained on the new products. However, the GPO has been applied at a parent OU, and it would normally be distributed to the users in that group. The Block configuration setting would accomplish the object of this example.

Enforce

It is also possible to enforce a group policy. The Enforce option prevents a GPO's policies from being blocked. The Enforce option overrides the Block and forces the GPO to be applied on child OUs.

Asynchronous or Synchronous

The GPO's area is applied synchronously to your system by default. With the computer policies, all the applications are complete before a user is able to log on to the system, specifically before the CTL+ALT+DEL prompt is present. The user policies are applied before the Windows desktop is up and available for use. More specifically, the user policies are applied before the user is allowed to interact with the shell.

It is possible to change the GPO setting to "asynchronous." The results for asynchronous GPO process are unpredictable, and this approach is not recommended by Microsoft.

Debugging Group Policies

After you have implemented the design for your GPOs, you need to start testing and evaluating the adherence of your implementation to your design. This can identify problems in your implementation. In some cases, even your design can be exposed for what it really is, but assuming your design is correct, fixing your implementation requires some strategy for debugging your GPOs.

Before we describe the strategies, the first step is to use a resource kit tool that is available. This tool is GPResult.exe. GPResult provides you with a list of the GPOs that were applied to your computer. You run GPResult from the command line. There are four options. They are

• /V for verbose mode

• /S for super verbose

• /C for computer settings only

• /U for user settings only

The following sample output for GPResult was run on a Windows 2000 system with no options selected. The sample output has the information that you need to concisely identify what is happening to your environment. This includes the OS Type and Version, User group policy results, Domain, Domain type, Site name, Security Group memberships, and the User and Computer GPOs. In this case, two User GPOs were applied. They were GPOUSF and GPOU1.

Microsoft (R) Windows (R) 2000 Operating System Group Policy Result tool
Copyright (C) Microsoft Corp. 1981-1999


Created on Thursday, November 11, 1999 at 10:58:04 PM


Operating System Information:

Operating System Type:          Domain Controller
Operating System Version:       5.0.2128
Terminal Server Mode:           None

###############################################################

 User Group Policy results for:

 CN=Ed Brovick,OU=Western Division,DC=wadeware,DC=net

 Domain Name:          WADEWARE
 Domain Type:          Windows 2000
 Site Name:            Default-First-Site-Name

 Roaming profile:      (None)
 Local profile:        C:Documents and Settingsebrovi
 
 The user is a member of the following security groups: 

     WADEWAREDomain Users
     Everyone
     BUILTINUsers
     BUILTINAdministrators
     WADEWAREDomain Admins
     WADEWARESeattle Users
     LOCAL
     NT AUTHORITYINTERACTIVE
     NT AUTHORITYAuthenticated Users


###############################################################

Last time Group Policy was applied: Thursday, November 11, 1999 at 10:54:30 PM


===============================================================


The user received "Registry" settings from these GPOs:

      GPOUSF
      GPOU1



###############################################################

 Computer Group Policy results for:

 CN=WADEWARE-XH3MRH,OU=Western Division,DC=wadeware,DC=net

 Domain Name:          WADEWARE
 Domain Type:          Windows 2000
 Site Name:            Default-First-Site-Name

###############################################################

Last time Group Policy was applied: Thursday, November 11, 1999 at 10:53:53 PM


===============================================================


The computer received "Registry" settings from these GPOs:

      Local Group Policy
      Default Domain Policy


===============================================================
The computer received "Security" settings from these GPOs:

      Default Domain Policy
      Default Domain Controllers Policy


===============================================================
The computer received "EFS recovery" settings from these GPOs:

      Local Group Policy
      Default Domain Policy

There are strategies you can use to debug your policies. The first is to start peeling back your GPOs by disabling each GPO. As an administrator, you can disable a GPO so that it is eliminated from the processing and evaluate the effect. This approach is time-consuming if you have many GPOs; therefore, keeping the design simple helps here as well. Also, remember that you need to restart your system to receive computer policy changes.

The second strategy is to establish the logging of group policy events. This can fill up your event log; so, when enabling a group policy event, you should plan carefully and create a set of policies that only affect a select group. If you start logging production GPOs and if you have thousands of users logging in all the time, your ability to review the log might be difficult.