Windows Administration

Your Guide to Group Policy Troubleshooting

Derek Melber

At a Glance:

• Common GPO Issues
• Group Policy Rules
• Troubleshooting GPO problems
• Tools for troubleshooting

Microsoft Active Directory has become a critical component of many IT infrastructures. One of the most important features of Active Directory is Group Policy, which allows administrators to centralize the management of domain controllers, member servers, and desktops.

While Group Policy clearly provides many benefits, it has one small glitch. It can be complex to design and implement in a large organization and even more problematic to troubleshoot when something goes awry. In this article, I'll investigate how Group Policy is structured and show you how to troubleshoot it. By the end, you will have all of the ammunition you need to tackle almost any Group Policy issue.

Troublesome Settings

There are many moving parts within Group Policy, especially in regard to the way it interfaces with the overall Active Directory® design and implementation. When troubleshooting many kinds of access and network issues, you must always include Active Directory and the basics of Group Policy implementation in your search for a solution. To begin the troubleshooting process, let's look at Group Policy settings that can be configured incorrectly, then move on to more complex issues that might cause Group Policy to malfunction.

Group Policy settings are viewed by Active Directory administrators using administrative template files (ADM or ADMX files) and the Group Policy Object Editor, or GPEdit (launched by running gpedit.msc). Using GPEdit, the administrator creates Group Policy Object files, or GPOs. The GPOs are configured to apply (or not apply) to computers and users within the Active Directory structure. There are a number of rules GPOs must follow in order to function correctly. Let's look at them now.

GPO Must Be Linked When a new GPO is created, it may not be linked to any node within Active Directory. Even though the GPO can be edited and modified, it will not affect any objects until it is linked to a node. To ensure that the GPO is properly linked, you can view the information window in the Group Policy Management Console (GPMC) that is shown in Figure 1.

Figure 1 GPO Links Are Clearly Shown (Click the image for a larger view)

GPO Must Target Correct Object As you know, Group Policy must target the correct objects in Active Directory. However, this is sometimes overlooked in the midst of a troubleshooting exercise. Within a GPO, there are two major categories: computer and user. When you configure a GPO, be sure to note if it is for a computer or user object. Then you can verify that the correct object types are placed in the Organizational Unit (OU) where the GPO is linked.

GPOs Don't Apply to Groups Although you may wish it were so, a GPO cannot apply to an Active Directory security group object. The only two objects that a GPO setting can configure are computers and users. GPOs can't configure objects via group membership. For example, if there is a GPO linked to the Finance OU, as shown in Figure 2 the only objects that will be affected by the setting are Derek and Frank. The settings in the GPO will not affect the members of the Marketing group, no matter who has membership in that group.

Figure 2 Finance OU and the Objects Within It (Click the image for a larger view)

Target Object Must Be in the Path of the GPO When you notice that a GPO setting is not affecting an object as it should, there is one more important setting-the object must be in the Scope of Management (SOM) of the GPO. This means that the object must be located under the node where the GPO is linked (even a child node will be sufficient). For example, none of the objects in the Marketing OU will be affected by a GPO that is linked to the Finance OU, as shown in Figure 3. The SOM of a GPO is from the node where it is linked, down through the Active Directory structure.

Figure 3 When OUs Are at the Same Level, GPOs Only Apply to the OU Where It Is Linked (Click the image for a larger view)

GPO Needs To Be Enabled When a GPO is created, it is not configured to make any modifications to target objects. However, it is enabled for both the computer and user portions. If either of these portions is disabled, it can be tricky to track this down. Therefore, when you are troubleshooting a GPO that will not apply, it is a good idea to check to see if some or all of the GPO is disabled. You can do so by looking under Group Policy Objects | Account Policy in the GPMC and checking the GPO status.

Some Settings Need a Reboot When a GPO setting is not working properly, it might be due to the inherent processing of GPOs. When the periodic background refresh of GPOs is triggered, it can only process some of the GPO settings, but not all. So while you may have created a setting, it may not have taken effect yet. There are some settings that are categorized as Foreground Policies, and they are only applied when the computer is rebooted or the user logs off and then logs back in. Examples of settings that behave this way include software installation, folder redirection, and script application.

Synchronous and Asynchronous Application of Settings

Within a GPO you can configure how policy application occurs at boot time and logon. The changes that you can make will either provide immediate access to the desktop while policies are still applying, or ensure all policies apply before the user has access to the desktop. Figure 4 shows how each operating system behaves by default. If you want to alter this behavior, you can modify the following policy setting:

Computer Configuration | Administrative Templates | 
System | Logon | Always wait for the network at computer startup and logon 

Figure 4 Default Processing on Client

Most administrators prefer to have a synchronous application of policy, to ensure that all policies are applied before the user can access the desktop. This ensures that all security and configuration settings are applied before any work can be done by the user. Note that this is not the default state in Windows® XP Professional, which was optimized for enhanced logon speed.

Altering Default Inheritance

There are four different methods that can be used to alter the default inheritance of GPO processing. These options are powerful and should be used sparingly, as they can cause significant alterations to the behavior of Group Policy processing. They can also be very difficult to troubleshoot. The options for altering default inheritance include the following four settings and configurations:

• Block policy inheritance
• GPO enforcement
• GPO filtering of the access control list (ACL)
• Windows Management Instrumentation (WMI) Filters

Since these settings should be used sparingly, it should be easy to document when they are being used. To find out if these options are in use, look in the GPMC. Block inheritance is performed at the domain or organizational unit (OU) node in GPMC. GPO enforcement, filtering of the ACL, and WMI filtering are set on each GPO.

Alternatively you can run the Gpresult command from the target computer to get an idea about whether any of these settings are prohibiting the policies from applying. To get a more in-depth view of the resulting set of policies being applied, you can add the /v switch to the Gpresult command, which will give you the verbose output.

ADM Template Issues

When you are attempting to configure settings in a GPO under the Administrative Templates section, you are working with ADM templates. In addition to the ADM templates that ship with the operating system, you can customize your own for use in a GPO. The code in the ADM template creates the folders and policies in the Group Policy Editor under the Administrative Templates node. However, if the ADM template is corrupt, missing, or not configured properly, it's quite possible that you won't see some or all of the settings in the editor. Here are some other issues to guard against when using ADM templates.

Missing ADM Templates When you edit a GPO and find that there are settings in a custom ADM template that are not showing up in the editor, you need to import the ADM template into the GPO. You do this by simply right-clicking on the Administrative Templates node in the editor and selecting Add/Remove Templates.

Missing Preferences There are two types of settings that can be created in a custom GPO: Preferences and Policies. Policies are the default Microsoft settings that all fall into one of four subkeys in the registry, each ending with the text "Policies". Preferences are "old style" Registry modifications that don't fall under one of the four subkeys, and are difficult to reverse once configured. These preferences don't show up in the editor by default. You must enable them to show up, which is possible when you go under the View menu on the toolbar. From there, select Filtering, then check the "Only show policy settings that can be fully managed" checkbox. This will immediately display the preferences that are configured in your custom ADM templates that have been imported.

Handy Tools

There are plenty of tools available for helping you track down your Group Policy issues. Some are built into the operating system and others can be downloaded and installed. Next I'll discuss the appropriate tools so you can choose the right one for your task.

Dcgpofix There might be a time when you have an issue with one of the two default GPOs: Default Domain Policy and Default Domain Controllers Policy. If one or both of the GPOs becomes corrupted, too far out of configuration where you can't fix it, or some other unknown issue, you can use the dcgpofix tool to revert them to the default state. This tool is included in Windows Server® 2003. You should not run this tool on a Windows 2000 domain controller; use Recreatedefpol instead. And remember, when you use this tool, you will lose any customized settings.

Recreatedefpol This tool is similar to Dcgpofix, but for Windows 2000 servers. It can return the two default GPOs to their freshly installed state. This tool should only be used in a disaster recovery situation, not for routine maintenance of GPOs. You can download this tool.

Event Viewer The Event Viewer has a wealth of information regarding Group Policy. Unfortunately, it requires you to look at all of the different log files to find entries for Group Policy. There you'll find entries related to policy application, policy replication, and policy refresh, all of which can be useful when trying to track down a problem. There is not always a lot of information on specific Group Policy errors in the event logs, but remember that you can always search TechNet if you find errors you can't identify.

Gpresult This tool can only be run locally on the target computer, but it provides information about the Resultant Set of Policies (RSoP), blocked GPOs, permissions on GPOs, and much more. Using the command with the /v switch will show a great deal of information about the GPOs that are affecting the computer and about user accounts associated with the current logon session.

Gpupdate If you are implementing new GPO settings or trying to ensure that all GPO processing has occurred, you can use the Gpupdate tool. This is a command-line tool that ships with the operating system (Windows XP and greater). When you run it, it will trigger a background refresh which will apply all GPO settings that adhere to this type of refresh. If you add the /force switch, it will reapply all GPO settings, even if there have been no changes to the GPO since the last refresh. Running this command before running the Gpresult command is a very powerful method for tracking GPO issues.

Gpotool Since GPOs are replicated from the domain controller where the GPO changes initially occur to all other domain controllers, there is a chance of replication failing or not converging efficiently. The result of this is inconsistency or failure of the changes to be properly applied to the target computers. Tools such as Gpresult and RSOP can help determine what GPOs have applied, but this tool, Gpotool, can help you determine if the GPOs on each domain controller are consistent. The tool is part of the Windows Server 2003 Resource Kit at go.microsoft.com/fwlink/?LinkId=77613.

Replmon When troubleshooting replication of GPOs from one domain controller to another, it is important to know which tools you can use to help get the replication working. Since there are two parts of a GPO that must be replicated, there are two parts that need to be addressed. The first, which is the contents of SYSVOL on each domain controller, is controlled by the File Replication Service (FRS). There is really not much you can do to control this replication, except to disable and enable the service to help it trigger a replication interval. The other part of the GPO, which is stored in Active Directory, is controlled by Active Directory replication. This replication can be controlled between domain controllers in the same Active Directory site by using Active Directory Sites and Services. However, when you need to trigger a replication between domain controllers in different Active Directory sites, you need to use a tool like Replmon. Replmon can force replication of the Active Directory database across site boundaries, while Active Directory Sites and Services can't. Therefore, when you have a mismatch of Group Policy information, which is stored in Active Directory, you can use Replmon to trigger a replication process to get that information converged on each domain controller. Replmon is part of the Resource Kit and Windows XP Support Tools. You can download it at go.microsoft.com/fwlink/?LinkId=77614.

RSOP Much like the command line tool Gpresult, RSOP provides a graphical interface for looking at the settings that have been applied by all of the GPOs. RSOP.MSC is a built-in tool for Windows XP Professional and Windows Server 2003. The tool provides you with a result of all applied policy settings in a format similar to that of the Group Policy Object Editor, as shown in Figure 5.

Figure 5 Resultant Set of Policies Tool

Wrap-Up

Troubleshooting Group Policy issues is not the easiest task you will ever attempt. In fact, as this article shows, Group Policy can be quite complex. When you approach it for troubleshooting, you need to understand the core architecture and overall processing typical of Group Policy. You also need to understand how a GPO is updated, replicated, processed, and applied. If you have a good grasp of all these concepts, the troubleshooting of any particular Group Policy issue is much easier. By following the guidelines in this article and using your tools appropriately, you'll be ready to tackle all the Group Policy problems you may encounter.

Derek Melber is the Director of Education, Certification, and Compliance Solutions for DesktopStandard, a wholly owned subsidiary of Microsoft. Derek co-wrote Microsoft Windows Group Policy Guide (Microsoft Press, 2005). He also wrote a series of books on auditing Windows security (www.theiia.org). Contact him at derekm@desktopstandard.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.