Troubleshooting Group Policy

Group Policy is a complicated piece of technology with lots of moving parts that work together to make it do its thing. Typically, problems with Group Policy arise while you're testing a particular policy. More rarely, problems show up that are unrelated to each other and it isn't obvious that Group Policy is involved in all of them. No matter what the reason, when something goes wrong in Group Policy, you often have to look in several places to find the solution.

The key to successful Group Policy troubleshooting is knowing where to look. Because Group Policy processing consists of two phases, you have two main areas in which to start looking for problems. In the first phase, core processing, Windows queries Active Directory (AD) to figure out which Group Policy Object (GPO) applies to the current computer or user, which policy areas (e.g., administrative templates, software installation) need to be processed, and whether the GPO has changed since that computer or user last processed it. Core processing requires the cooperation of several pieces of your infrastructure, including DNS, AD, File Replication Services (FRS), and your network. If any piece goes bad during core processing, all Group Policy processing will typically cease.

The second phase of processing involves client-side extensions, such as security settings, administrative templates, and folder redirection. Client-side extensions implement policies by processing and applying the settings in the GPOs that were found during core processing. Typically, when a problem occurs during client-side extension processing, that problem is confined to a single client-side extension--or even to a single GPO processed by a client-side extension--and other Group Policy processing continues as expected. Client-side extension problems are more difficult to troubleshoot because each extension that implements a GPO performs its tasks in a slightly different way and generates varying degrees of logging.

Logging of both phases of processing is often vital to successful troubleshooting. The log files can often illuminate problems that aren't obvious at first glance. If a Resultant Set of Policy (RSoP) report and a check of infrastructure components don't show the way to a solution, logging can sometimes reveal error messages that point to the exact problem.

There's no single place you can go to enable all available Group Policy logging. You can enable individual logs manually by using the underlying registry values. Web Table 1 lists the logs available for Group Policy and the accompanying registry values. Alternatively, you can use a free shortcut tool I've created—an Administrative Template (.adm) file called gpolog.adm—to enable any or all Group Policy-related logs. You can download gpolog.adm at http://www.gpoguy.com/tools.htm. Regardless of whether a problem occurs during core processing or client-side-extension processing, following the steps I provide here will help you troubleshoot the problem.

Step 1: Review the most recent processing cycle.
The first step in determining why a workstation or server is having Group Policy processing problems is to find out what happened during the last Group Policy processing cycle. To do so, you need Group Policy Management Console (GPMC) for Windows Server 2003 or Windows XP or the gpresult.exe command-line utility that comes with Windows 2000.

GPMC provides the Group Policy Results Wizard, which you can use to query your Windows 2003 and XP systems to get a report of what happened for a given user on that system during the most recent processing cycle. You can use gpresult.exe to get the same data from the command line that the Group Policy Results Wizard provides. However, if you have Windows 2000 machines and are using the version of gpresult.exe that comes in the Microsoft Windows 2000 Resource Kit, you'll get only a subset of the data that Windows 2003 and XP provide. That's because Win2K doesn't have the RSoP that was added to later versions of the OS.

To run the Group Policy Results Wizard, start GPMC, right-click the Group Policy Results node, and run the wizard. The wizard will ask whether you want to gather results from the local computer or a remote computer.

After you specify the computer, you can choose a user account that has logged on to that computer, if you want to gather user-specific policy settings. The wizard then goes to the computer you've selected, uses Windows Management Instrumentation (WMI) to gather the most recent Group Policy processing data, and reports the results in GPMC's results pane.

From a troubleshooting perspective, the most interesting parts of these results are contained on the Summary and Policy Events tabs. The Summary tab provides an overview of the computer and user-specific policy processing actions during the most recent processing cycle. To find out whether any part of either core or client-side–extension processing failed, you can look at the Component Status section on the Summary tab. A status of "Failed" for Group Policy Infrastructure components indicates a problem with core processing. A status of "Failed" for a client-side extension, such as Folder Redirection, indicates a problem with client-side–extension processing, as Figure 1 shows.

The Policy Events tab gives you additional useful troubleshooting information. The events shown on this tab offer a filtered view of the Application event log for the computer that the Group Policy Results Wizard queried. The view is filtered to show only Group Policy-related events, from which you can often glean useful information about what's working and what isn't. For example, suppose your logon script isn't running but the Summary tab's Component Status for the Scripts client-side extension indicates success. If you were to look in the Policy Events tab, you might see an error related to script processing such as the one shown in Figure 2, which tells you that the script file can't be found. This problem could be due to either a missing script file on the server or a permissions problem. In either case, you have a lead you can use to track down the cause of the problem. After you've used the information in the Summary and Policy Events tabs to narrow the problem, you can dig deeper.

Step 2: Troubleshoot core-processing problems by checking infrastructure.
Let's say that the Group Policy Results Wizard revealed that core processing failed (i.e., the Group Policy Infrastructure component status was Failed). Such a failure usually points to an infrastructure problem related to either the client or the domain controller (DC) from which the policy information is being read. Note that "client," in this context, could be either a server or a workstation. Several technologies can cause core-processing problems. Start by doing the following checks:

net start 

at a command prompt to get a list of all running services or go into the Administrative Tools program group on the Start menu and select the Microsoft Management Console (MMC) Services snap-in to verify that the service is started.

You can also get clues to core-processing problems by checking the client computer's Application event log for events that have an event source of Userenv. Such events typically relate to core processing and sometimes can contain information about specific errors that occurred during processing. In that case, you might want to use the gpolog.adm template to enable verbose Application event logging.

Step 3: Use the Application event log to troubleshoot client-side extension problems.
If the Group Policy Results Wizard reveals that the problem is specific to a particular client-side extension, focus your efforts on determining why that extension failed. Start by looking for related errors in the Application event log. You'll typically see one of the following event sources listed for a particular client-side–extension problem:

In addition to using the Application event log, you might need to drill down further to find problems specific to client-side extensions.

Step 4: Enable logging specific to core or client-side extension processing.
If the information in the Application event log isn't detailed enough, you might need to drill further into a core processing or client-side–extension problem. The gpolog.adm template I mentioned earlier exposes a variety-of logs. A good log to start with is the Userenv log (written to %windir%debug usermode), which captures detailed step-by-step information of both core and client-side extension processing as well as user profile activity. This file is updated with every Group Policy processing cycle, and you can use it to walk through the processing actions of each client-side extension. You can see whether a client-side extension actually ran, and if not, why it didn't. For example, the log file might show that the client-side extension didn't run because the GPOs it was processing hadn't changed since the last cycle.

Finally, you can enable verbose logs to help you troubleshoot certain client-side extensions. For example, you can enable a verbose log for the Software Installation extension to determine why a package was incorrectly installed—whether because of a problem with the client-side extension or a problem with the package itself. If the problem is related to the package, then you can enable verbose Windows Installer logging within an administrative template policy (Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows InstallerLogging) to further attack the problem.

Be Methodical
Group Policy troubleshooting requires a methodical, step-by-step approach that first narrows the problem and then seeks out the solution. The tools and suggestions I've discussed will help keep your troubleshooting time to a minimum and the solution close at hand.