How to manage Group Policy Objects for Windows Vista

This chapter excerpt from Microsoft Windows Vista Management and Administration, by Andrew Abbate, James Walker, Scott Chimner and Rand Morimoto, is printed with permission from Pearson Education, Copyright 2007. Click here for the chapter download or purchase the entire book here.

As you can likely tell from this chapter, GPOs are an extremely useful and powerful way to manage workstations in a domain. Like most utilities that are powerful, it is easy to cause problems for yourself if you don't manage the process well. Knowing how GPOs work, where the components are stored, and what you need to do to utilize them are the key pieces to making GPOs work for you.

Where Are GPOs Stored?

For GPOs to be useful across the forest, the GPOs must be available to users and computers. The way in which Active Directory deals with this is to store the GPOs in the SYSVOL volume that is replicated across all domain controllers in the forest. Specifically, the files are stored in Domain sysvoldomainpolicies.

They will appear in directories with names like {162EBD2C-FAAC-4852- 8B28-FB2D4ABA1CD5}, as shown in Figure 22.4. Contained in these directories is a configuration file (gpt.ini) as well as subfolders for the Machine and User settings.

New to Vista and Windows 2008 is an additional directory under Policies called PolicyDefinitions. This directory contains the new ADMX files that are used by Vista and Windows 2008. This directory is referenced by new GPOs that contain Vista or Windows 2008 settings.

If the directory for a newly created GPO does not appear on remote DCs within 15–30 minutes, you should suspect that there may be issues with the File Replication Service on one domain controller or more.

Figure 22.4

How GPOs Replicate Throughout the Domain

Because GPOs are stored in the SYSVOL volume of domain controllers, they are automatically replicated to all domain controllers in the domain through the File Replication Service (FRS). It is very important that FRS be operating successfully to ensure that all users in the domain are getting consistent settings via GPOs. If a domain controller is having FRS issues, it may not become aware of changes to a given GPO. This will result in some systems not getting the correct version of the GPO. This can be a major issue if GPOs are being used to configure important security settings or to apply patches or hotfixes to workstations.

A very simple way to verify the health of FRS is to place a text file in the SYSVOL directory of a domain controller and check the SYSVOL directory of other domain controllers to ensure that the new file appears within the expected replication intervals.

Keeping an eye on the FRS section of the event viewer of domain controllers is another easy way to become aware of FRS problems. If you want to keep a more watchful eye for potential FRS problems, Microsoft has a tool called SONAR, available here that will allow you to keep closer tabs on FRS performance.

How to Link a GPO to an OU

After a GPO has been created, it needs to be linked to an OU or site to actually do anything. Interesting to note is that the User and Computer containers in Active Directory are not actually OUs and thus can't be used as a link point for a GPO.

The concept of linking a GPO is that the GPO is effectively being assigned to objects contained in or under the OU to which it is linked. This is traditionally the largest point of confusion to administrators. As mentioned previously in this chapter, GPOs are separated out into two sections: Computer and User settings. When a GPO with both Computer and User settings is linked to an OU, there are two potential things that can occur. If a user object is in or below the OU where the GPO is linked, the User settings will be applied (assuming the user has permissions to apply the GPO). Similarly, if a computer object is in or under the OU where the GPO is linked, it will attempt to apply the Computer settings (if the computer has permission to apply the GPO).

The common mistake made by administrators is assuming that both User and Computer settings will get applied if either the user or computer object is in or under the linked OU. This is an incorrect assumption.

In some situations, it may be very desirable to apply both Computer and User settings when a user logs on to a specific computer. A classic example of this is when a user is logging on to a Terminal Server. It may be useful to apply User settings when the user is on the Terminal Server that wouldn't be desired when the user logs in to their normal workstation. This is where the concept of loopback processing comes into play. Loopback processing is a Computer GPO setting that will effectively apply User settings based on the computer object being in a linked OU when the user object isn't. The two options are to append the User settings to existing inherited user GPOs or to replace the existing GPOs.

To link an existing GPO to an OU, perform the following steps:

1. Launch the GPMC (Start, Run, gpmc.msc).
   
2. Expand the Forest container.
   
3. Expand the Domains container.
   
4. Browse to the OU to which you plan to link the GPO.
   
5. Right-click the OU and choose Link and Existing GPO.
   
6. Choose the GPO you want and click OK.

Figure 22.5

How to Control Who Can Modify a GPO

After a GPO has been created, an administrator can control who is allowed to edit an existing GPO. This can be helpful in environments where the creation of GPOs is a centralized and controlled event but where a local OU Admin might be empowered to make modifications to existing GPOs. To alter the rights on a GPO to allow for editing, perform the following steps:

1. Launch the GPMC (Start, Run, gpmc.msc).
   
2. Expand the Forest container.
   
3. Expand the Domains container.
   
4. Browse to the Group Policy container.
   
5. Highlight the GPO you want to alter permissions on.
   
6. In the right pane, click the Delegation tab.
   
7. Click Add and type the name of the user or group to which you want to delegate rights.
   
8. Click Check Names and then click OK.
   
9. In the Permissions drop-down list, choose Edit and click OK.

Figure 22.6

How to Limit Who Can Apply a GPO

Typically, the role of GPO administrator is limited to a particular subset of administrators in Active Directory. This minimizes the potential for an administrator to make an unauthorized change that could potentially impact all users in the domain.

A best practice is to separate out the two key roles of Group Policy: creation and application. One group should have the capability to create GPOs but should not have the rights to link them to any containers. Another group should have the capability to link but not create. This creates a situation where no one person has the capability to place new GPOs into production. To delegate these rights, perform the following steps on a domain controller:

1. Click Start.
   
2. Click All Programs.
   
3. Click Administrative Tools.
   
4. Click Active Directory Users and Computers.
   
5. Click View and then click Advanced Features.
   
6. Right-click the domain object and select Delegate Control; then click Next.
   
7. Click Add and type in the name of the group to which you are delegating the capability to link GPOs.
   
8. Click OK twice and you should see the group you added. Click Next.
   
9. Check the box for Manage Group Policy Links and click Next.
   
10. Click Finish.

1. Click Start, Run, and type gpmc.msc.
   
2. Expand Forest.
   
3. Expand Domains.
   
4. Expand the domain you are managing.
   
5. Highlight Group Policy Objects.
   
6. Select the Delegation tab in the right pane.

To delegate a new group to be able to link GPOs, perform the following additional steps:

1. Click Add.
   
2. Type the name of the group you want to add and click Check Names.
   
3. 3. Click OK.

In many cases, an administrator might want to apply a GPO to most users or computers but exclude specific groups. Although this can be done by controlling where the GPO is applied in the OU structure, sometimes this would require too much granularity in the OU structure. In these cases, you can use GPO filtering to prevent specific groups of objects (users or computers) from applying the GPO. This is called GPO filtering.

Imagine, for example, that you create a GPO that will enable a screensaver with a password after 60 seconds of inactivity. Although this might be great for security, it can really bug an executive who is trying to do a PowerPoint presentation that requires a lot of talking. In this situation, it might be worthwhile to filter the presenter from the GPO. To accomplish this task, perform the following steps from a domain controller:

1. Click Start, Run, and type gpmc.msc.
   
2. Expand Forest.
   
3. Expand Domains.
   
4. Expand the domain you are managing.
   
5. Highlight Group Policy Objects.
   
6. Right-click the GPO in question and click Scope.
   
7. Add the group you want to filter and change the permissions to Apply GPO—Deny.

In most OU structures, there is a container for protected objects that in many cases should not have GPOs applied to them. This might include administrator accounts, validated computer systems, or even service accounts. The safest way to protect these accounts from accidental changes via GPO is to place them in an OU that is blocking inheritance. This is to say that even though a GPO might be applied to a container that is above the protected container in the OU hierarchy, the GPO will still be blocked.

To set blocking on an OU, from a domain controller follow these steps:

1. Click Start.
   
2. Click All Programs.
   
3. Click Administrative Tools.
   
4. Chose Active Directory Users and Computers.
   
5. Click View and then click Advanced Features.
   
6. Right-click the OU you want to set inheritance blocking on and select Properties.
   
7. Click the Group Policy tab.
   
8. Check the box for Block Policy Inheritance and click OK.

GROUP POLICY BASICS FOR WINDOWS VISTA

 Home: Introduction
 Tip 1: A basic primer on Microsoft Group Policy
 Tip 2: How to configure GPOs
 Tip 3: What's new in Vista Group Policy?
 Tip 4: How to manage GPOs
 Tip 5: Troubleshooting GPOs for Vista
 Tip 6: Group Policy best practices
ADVANCED GROUP POLICY FOR WINDOWS VISTA
 Home: Introduction
 Tip 1: Which GPOs are available
 Tip 2: Further understanding GPOs in Vista
 Tip 3: Examples of useful GPOs in Vista
 Tip 4: Moving policies between domains
 Tip 5: Recommended practices with Vista Group Policy