In the first article on this topic, I talked about using GPMC's Group Policy Results Wizard to determine if Group Policy is working on a given Windows system. That gives you several vital pieces of information, including whether Group Policy processing worked (i.e. completed without an error) for the computer or user, which GPOs were applied, which were denied (and why) and finally, what settings were actually delivered to the computer or user. Now let's suppose that the Component Status section of that report showed a failure for one or more Group Policy areas. How do you determine the next step to take in tracking down the problem?

The Phases of Policy Processing
The answer to that question lies in where the failure occurred. In the Component Status section of the Group Policy Results Summary tab, you will see a listing of areas within Group Policy, and their status. The first area listed is called, "Group Policy Infrastructure". This represents the "core" part of the Group Policy processing. During the core phase, the computer or user talks to AD and SYSVOL to determine which GPOs apply to it and which policy areas must be processed. If this phase of policy processing shows a failure, then no Group Policy processing will occur. In addition to the core phase, the Component Status section will provide success or failure information for each policy area that is implemented within the GPOs that apply to the computer or user (e.g. registry, security, folder redirection, etc.). If Group Policy Infrastructure processing is successful, you can still have a failure in one of these policy areas, and that will show up here. Typically when failures are reported in these policy areas, the failure message is also listed here. If the failure message is not useful, then the next step is to start drilling into the various logging that Group Policy supports, starting with the Windows event logs.

Using the Logs
If Component Status shows a failure in any error of policy processing, chances are there will be some information about it within the Windows event logs. In all versions of Windows prior to Vista and Server 2008, Group Policy-related events appear in the Application event log. Most events related to "core" processing (and registry policy) will show up in the application event log with an event source of Userenv, which is the name of the Windows system component that runs GP Processing. You can search for Userenv events to get more information about why GP Processing (esp. core processing) might have failed. For each of the different policy areas, you will have varying degrees of success when it comes to finding events in the event logs related to them, but here are some event sources you can look for that correlate to policy areas.

Vista Logging
With the release of Windows Server 2008 and Windows Vista, Microsoft upped the ante on Group Policy logging. In previous versions of Windows, in order to get detailed trace logging -the kind we will discuss in the next installment of this series, you had to crack open detailed trace logs like userenv.log. But, with these newer OS versions, you can now get detailed Group Policy processing logging using the Windows event viewer. Specifically Vista and Server 2008 provide the Group Policy Operational Log, found in the Event Viewer under Applications and Services Logs\Microsoft\Windows\Group Policy\Operational. If you open up one of these logs, you will see very detailed, step-by-step tracing of the Group Policy processing cycle, including how much time is spent during each part of the processing phase, and whether each phase has succeeded or failed. In addition, Microsoft provides a handy command-line utility that can retrieve these operational log events into a variety of useful formats for further analysis. This utility is called the Group Policy Log View and can be downloaded at http://www.microsoft.com/downloads/details.aspx?FamilyID=bcfb1955-ca1d-4f00-9cff-6f541bad4563&DisplayLang=en.

In the next installment, I'll talk about taking the next step down in terms of troubleshooting--using the various GP trace logs.

Written by Guest Blogger Darren Mar-Elia. Darren is CTO & Founder of SDM Software (www.sdmsoftware.com), a Group Policy Solutions company. SDM Software develops and sells product to improvement the manageability and reliability of Windows systems that leverage Group Policy. The GPExpert™ Troubleshooting Pak (www.sdmsoftware.com/group_policy_troubleshoot) is an example of one of these products--a set of four utilities that help speed time-tor-resolution of Group Policy problems.