Manage Learn to apply best practices and optimize your operations.

Best practices in working with Group Policy Objects for Windows Vista

This excerpt from "Microsoft Windows Vista Management and Administration" details best practices for IT admins when managing Group Policy Objects.

Microsoft Windows Vista Management and Administration 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.

GPOs can be very powerful when used correctly, and they can also be very dangerous when used incorrectly. Many tricks can be employed to improve overall management and application of GPOs, ranging from ways to make GPOs faster to process to ways to more easily roll back mistakes with GPOs.

Speeding Up GPO Processing

To speed up login and boot times for users, it is recommended that if the entire User Configuration or Computer Configuration section is not being used in a GPO, the unused section should be disabled for the GPO. This expedites the user logon time or the computer boot time because the disabled sections aren't parsed on boot or login.

To disable configuration settings using Active Directory Users and Computers, follow these steps:

  1. Right-click a Group Policy.
  2. Click Properties.
  3. Go to the General tab.
  4. Click one of the boxes, either Disable Computer Configuration Settings or Disable User Configuration Settings, whichever section is not being utilized.

To disable configuration settings using the GPMC, follow these steps:

  1. Click the Group Policy in GPMC.
  2. Click the Details tab.
  3. Click the drop-down box at the bottom of the Details tab.
  4. Choose Computer Configuration Settings Disabled or User Configuration Settings Disabled, depending on which portion needs to be disabled.

Reusing Basic GPOs

If a Group Policy will be applied to many locations, you should create the policy once, assign the permissions, and then link the policy to the other locations rather than creating the policy multiple times. Linking the policies achieves the following objectives:

  • Creates fewer group policies in SYSVOL -- This allows for quicker domain controller promotion and less replication traffic.

  • A single point of change for the GPO -- If the GPO is changed, the change is applied to all the locations where the GPO is linked.

  • A single point of change for permissions -- When permissions are configured or changed in one location on a linked GPO, the permissions are applied universally to each place where the GPO is linked.

Understanding Inheritance</font

Group Policy objects are applied in a specific order. Computers and users whose accounts are lower in the Directory tree can inherit policies applied at different levels within the Active Directory tree. Group Policy is applied in the following order throughout the AD tree:

  • Local Security Policy is applied .
  • Site GPOs are applied next.
  • Domain GPOs are applied next.
  • OU GPOs are applied next.
  • Nested OU GPOs and on down are applied next until the OU at which the computer or user is a member is reached.

If a setting in a GPO is set to Not Configured in a policy higher up, the existing setting remains. However, if there are conflicts in configuration, the last GPO to be applied prevails. For example, if a conflict exists in a Site GPO and in an OU GPO, the settings configured in the OU GPO will "win."

If multiple GPOs are applied to a specific AD Object, such as a site or OU, they are applied in reverse of the order they are listed. The last GPO is applied , and therefore if conflicts exist, settings in higher GPOs override those in lower ones. For example, if a Contacts OU has the following three Group Policies applied to it, and they appear in this order (as shown in Figure 22.7) the policies will be applied from the bottom up:

  • Contacts Default Group Policy
  • Contacts Software Policy
  • Contacts Temporary Policy

The Contacts Temporary Policy will be applied . The Contacts Software Policy will apply next, and finally the Contacts Default Group Policy will be applied. Any settings in the Contacts Default Group Policy will override the settings configured in the two policies below, and the settings in the Contacts Software Policy will override any settings in the Contacts Temporary Policy.

Figure 22.7

Where to Link GPOs

Administrators will quickly find that it can be very confusing to determine what GPOs are applied to a given user or computer and which aren't. One way to reduce this confusion is to try to eliminate questions of security filtering and policy inheritance overwrite whenever possible. This is to say that in many cases, it's best to push the application of a GPO as far down the hierarchy as is possible. This may result in the same GPO being linked to multiple locations.

Utilizing WMI Filtering

Linking WMI Filters enables you to apply group policies and establish their scopes based on attributes of target computers. You can do this by using the WMI filters to query the WMI settings of the target computers for true/false and apply group policies based on the true/false WMI queries. A "false" on the target computer results in the GPO not being applied. Conversely, a "true" results in the application of the GPO.

Because WMI filters are separate from GPOs, they must be linked to GPOs in the GPO Scope tab to function properly. Only one WMI filter can be applied to each GPO. Additionally, WMI filters will work only on Windows XP and later workstations, not Windows 2000 or before, or non-Microsoft operating systems.

Rolling Back Bad Ideas

Most administrators will experience a bad idea GPO at least once in their career. Sometimes settings that seem innocuous will cause problems, or perhaps an administrator will try to save time and link a GPO that hasn't been fully tested. In these cases it's necessary to quickly revert to an older version of a GPO. Unfortunately, there isn't a native method for rolling back a GPO; however, a few simple administrative tasks can allow for a quick restore to a known good GPO.

The key to being able to quickly revert from a bad GPO is to ensure that GPOs are always backed up and that they are always given a descriptive name.

Let's take as an example a GPO that we'll call Disable BITS Peercaching. It has a simple setting that disables BITS Peercaching. We've followed our rule and given the GPO a descriptive name. We'll back up this GPO with the following steps:

  1. From within GPMC, right-click the GPO and select Back Up.
  2. Click Browse and choose the location where you will store your GPOs.
  3. Enter a description that explains the last set of changes and the date that it was saved; click Back Up.
  4. When the backup is completed, click OK.

Now imagine that an administrator has modified this GPO to include some settings that are incorrect or that are causing problems. It is very possible that the contents of the original GPO have been forgotten. You can revert to the old version of the GPO by doing the following:

  1. Select the GPO you want to revert, right-click, and choose Restore from Backup.


    You can use the View Settings button when highlighting a backed up GPO to review the settings of that GPO in an XML format. This can be helpful if you just want to see what the old version of the GPO was and not actually restore it.
  2. The Restore Group Policy Object Wizard will launch. Click Next.
  3. Click Browse and navigate to the location where the GPOs are saved. Click Next.
  4. In this screen, you will see all GPOs that have been backed up with a description and a time stamp. Select the version of the GPO you want to restore and click Next.
  5. Review the summary information and click Finish.
  6. When the GPO has successfully restored, click OK.

Because the GPO is restored on the Domain Controller that currently has focus within the Group Policy Management console, it may take a short while for the restored GPO to replicate to all domain controllers in the domain.


As we've seen, Vista has brought with it many changes to the available GPO settings as well as to the way in which they are stored and managed. We've seen the necessity of carefully managing and maintaining GPOs and have discussed ways to troubleshoot GPOs should any problems occur.

Always remember to carefully delegate who can create GPOs and who can link them. This will make it much less likely that you ever deploy a GPO that can cause problems for your users. Always try to do a peer review of a GPO before it's linked, and always link it to a test OU to make sure it has no unintended effects.

Keep these things in mind, and GPOs will help you more easily maintain your Vista community.


 Home: Introduction
 Tip 1: A basic primer on Microsoft Group Policy
 Tip 2: How to configure GPOs
 Tip 3: What's in Vista Group Policy?
 Tip 4: How to manage GPOs
 Tip 5: Troubleshooting GPOs for Vista
 Tip 6: Group Policy best practices
 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

Dig Deeper on Windows systems and network management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.