My last couple of tips have dealt with troubleshooting Group Policy processing in Windows Vista and later. Understanding how to do this is important for enterprises since Group Policy is a key tool for managing both client and server systems across an organization.
Checking your Event logs is usually the first step in troubleshooting any issue on Windows-based networks, so it's important to understand how logging of Group Policy events has changed in Vista compared to previous versions of Windows. For example, in Windows XP, administrative events relating to Group Policy were logged to the System log, and the event source for such events was displayed as "USERENV" since they were generated by Userenv.dll, the Group Policy engine on earlier Windows platforms. If you tried to troubleshoot a policy processing issue on Windows XP and found that the USERENV events in the System log didn't provide enough info, you could configure Userenv debug logging by setting UserEnvDebugLevel, a REG_DWORD registry value found at HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon, to one of the following data values depending on how verbose you wanted to make the log:
0x00000001 (normalâ€”the default)
You could also turn off logging entirely by setting UserEnvDebugLevel to 0x00000000, and you could combine the above four logging levels for greater detail. For example, setting UserEnvDebugLevel to 0x00030002 would provide the greatest level of detail in the log.
Things have changed in Vista however, and Events generated by the Group Policy engine as well as information previously logged in the Userenv log are now logged in the Application event log, while events generated by Group Policy extension DLLs are now logged to the Group Policy Operational event log. In addition, the event source for Application log events has now changed from "USERENV" (used in the System event log previously) to "Group Policy".
And finally, for even more detailed troubleshooting purposes you can configure Group Policy debug logging for the Group Policy Editor by creating GPEditDebugLevel, a REG_DWORD registry value, under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon, and set this value to 0x10002. Doing this will create a log file named GpEdit.log found under %SystemRoot%\debug\usermode which can be used for advanced troubleshooting purposes, for instance identifying malformed ADMX templates.
You can find lots more information on how Group Policy works in Windows Vista SP1 in chapter 13 of the Windows Vista Resource Kit, Second Edition, a must-have book for IT pros who deploy, maintain, and troubleshoot Windows Vista. Full disclosure: I was lead author for this title, so no wonder you "must have" this terrific book ;-)
Got comments concerning this tip? Want to share a tip of your own with ITWorld readers? Email me