Group Policy Logging

Attempting to optimize Group Policy Object (GPO) processing can make you feel as though you're fumbling in the dark because by default, you have no easy way to monitor GPO processing as it occurs. However, Windows XP and Windows 2000 do provide some useful logging features that let you drill down into a system's processing cycle.

By default, client-side extensions log some high-level processing activity to the Application log. However, this activity rarely provides enough detail to be useful. You can enable additional logging through a registry change on each machine that you want to examine. Create a Diagnostics subkey under the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersion subkey, then add the RunDiagnosticLoggingGroupPolicy value (of type REG_DWORD) and assign it a value of 0x1. Restart the computer.

After this registry change takes effect, verbose GPO logging occurs within the Application log, as Figure A shows. You can follow the entire GPO-processing cycle within the event log and note which client-side extensions are running, which GPOs the system is processing, whether the system isn't processing a GPO because the GPO version hasn't changed, and the length of the processing cycle. Logging also comes in handy when you need to troubleshoot GPO-processing problems. The verbose logging shows when a particular client-side extension fails to run against a particular GPO, and in some cases, why the failure occurred. (Any verbose logging will fill up event logs over time and can generate a certain amount of system overhead. However, verbose GPO logging happens only during GPO-processing cycles, and I've yet to see it adversely affect system performance.)