In the last two installments, we talked about using GPMC's Group Policy Results Wizard and the Windows event logs to first glean what GP is up to on a target system and then drill into why failures might be occurring. But sometimes even that is not enough to get to the root cause of a GP processing failure. For example, GPMC might show that security policy is failing on a system and the application event log may show a scecli error event that provides an error code, but you are unable to translate that error code into something actionable. In those circumstances, you may need to resort to leveraging the deeper trace logs that Windows provide within the Group Policy infrastructure. Before I describe these, however, a warning is in order. These trace logs are really not designed with the typical Windows administrator in mind. Many of them are designed by and for developers looking to debug their code. As a result, you may find the content of some of these logs off-putting. In addition, each trace log usually supports a different standard for writing trace events. So it's not as if you can learn how one log does its thing and apply it to the next one.

Group Policy Trace Logs
The trace logging that is available in the GP infrastructure must be turned on, or enabled at its full verbosity before it can really be leveraged. In addition, not every part of Group Policy supports trace logging. The granddaddy of all trace logs is the userenv.log file, which can be enabled using the information in this KB article-- http://support.microsoft.com/default.aspx?scid=kb;en-us;221833.

The userenv.log file logs detailed, step-by-step events for Group Policy processing--both the core processing cycle and the Client Side Extension (CSE) cycle--in Windows XP and Server 2003. Note that in Vista and Server 2008, this file still exists, and also another new trace file, called gpsvc.log is available, but the primary role of userenv (and indeed gpsvc.log) has been supplanted by the more user friendly Operational Log that I described in the previous installment. Regardless of whether you're using userenv.log, or the Operational logs, they will only get you so far, if a particular Client Side Extension (i.e. policy area) is having problems. For that, you'll need to rely on the individual trace logs supported by many of the CSEs.

Not all of the CSEs support trace logging, but many of the more popular ones, such as security, IE Maintenance, Software Installation and Folder Redirection, do. In fact, I've assembled all of the registry tweaks for the various trace logs that are available in GP, into a Administrative Template file called GPOLOG.ADM (and GPOLOG.ADMX for Vista/2008). You can download this template at my free GP resource site--http://www.gpoguy.com/. Just go to the Free Tools section and you'll find the logging templates there. By loading up one of those templates into a GPO, you can enable and disable trace logging on your problem computers and use that information to dig deeper into your GP problems.

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.