Group Policy, Profiles, and IntelliMirror for Windows2003, WindowsXP, and Windows 2000 (Mark Minasi Windows Administrator Library)

Advanced Group Policy Troubleshooting with Log Files

We've already explored some of the techniques to troubleshoot Group Policy application. You can enable some underlying operating system troubleshooting tools to help diagnose just what the heck is going on when the unexpected occurs.

Using the Event Viewer

Quite possibly, the most overlooked and underutilized tool in Windows is the Event Viewer. The client's Event Viewer logs both the successful and unsuccessful application of Group Policy (see Figure 4.22).

Figure 4.22: The Event Viewer is a terrific place to start your troubleshooting journey.

Before beating your head against the wall, check the client's Event Log for relevant Group Policy records. The Event Log in Windows XP and Windows 2003 spit out much more information and many more warnings than did the Event Log in Windows 2000so take advantage of it.

In Figure 4.22, the Event Log returned an error code of 1053. Doing a quick search in Microsoft TechNet, you can find a related Windows 2000 article, Q261007, which shows that the client is pointing to an incorrect DNS server. Again, search the Knowledge Base when you find an event that might be at fault. You might find a hidden gem therejust perfectly ready to solve your problem.

Diagnostic Event Log Registry Hacks

If you really want to go bananas, you can enable diagnostic logging to supercharge your Event Log. To do so, a Registry key to the client machine. Traverse to HKEY_Loca1_Machine\Software\Microsoft\Windows NT\CurrentVersion. Create a Diagnostics key, but leave the Class entry empty. You can specify logging types by creating one of three REG_DWORD keys.

RunDiagnosticLoggingGroupPolicy Create this REG_DWORD to log only Group Policy events. To enable logging, set the data value to 1. Log entries appear in the Application Log.

RunDiagnosticLoggingGlobal This key logs activity as if you added both the RunDiagnosficLoggingGroupPolicy as well as logs entries surrounding software deployment as detailed in Chapter 10. To enable logging, set the data value to 1. Log entries appear in the Application Log.

AppMgmtDebugLevel Create this REG_DWORD, but do so with a data value of 4b in hexadecimal. At the next targeted software deployment, you'll find a log in the local \windows\debug\usermode folder named appmgmt.log, which can also aid in troubleshooting why applications fail to load.

When you've finished debugging, delete the Diagnostic keys so your Event Logs don't fill up.

Turning On Verbose Logging

Sometimes, all the server pieces are working perfectly, but the end result on the client is cockeyed. You can examine Group Policy step by step by turning on verbose logging, which goes beyond the diagnostic Event Log Registry hacks. When you enable verbose logging by editing the Registry at the client, you are telling the system to generate a file called USERENV.LOG in the \windows\debug\usermode folder (or \winnt\debug\usermode for Windows 2000). You can then examine the file to see what the client thinks is really happening.

To enable verbose logging, follow these steps:

1. Log on locally to the client system as the Administrator.

2. Run REGEDIT .

3. In the Registry Editor, traverse to HKEY_Local_Machine\Software\Microsoft\Windows NT\CurrentVersion\Winlogon.

4. In the Edit DWORD Value dialog box, add a REG_DWORD value by entering UserEnvDebugLevel in the Value Name box, and Value Data box, enter the hex value of 30002, as shown in Figure 4.23. Click OK.

5. Close the Registry Editor.

Figure 4.23: Verbose logging requires a hack to the Registry.

After you modify the entry, log off as the local Administrator, and log on as someone with many GPOs that would affect their user objectsay, Frank Rizzo in the Human Resources Users OU. After logging on as Frank, you can immediately log off and back on as the Administrator for the workstation and then read the log file.

In the Userenv.log file in the \windows\debug\usermode folder, you should come across the following snippet. The output here has been truncated and formatted for better reading and for the sake of example. Additionally, line headers such as ProcessGPOs, AddGPO , and SearchDSObject have all been removed.

Starting user Group Policy (Background) processing... Starting computer Group Policy (Background) processing... User name is: CN=Frank Rizzo,OU=Human Resources Users,OU=Human Resources,DC=corp,DC=com, Domain name is: CORP Domain controller is: \WINDC01.corp.com Domain DN is corp.com network name is 192.168.2.0 User name is: CN=XPPR01,OU=Human Resources Computers,OU=Human Resources,DC=corp,DC=com, Domain name is: CORP Domain controller is: \WINDC01.corp.com Domain DN is corp.com Calling GetGPOInfo for normal policy mode No site name defined. Skipping site policy. Searching <OU=Human Resources Users,OU=Human Resources,DC=corp,DC=com> Found GPO(s): <[LDAP://cn={9A3B670A-3280-4687-A80A- 4C8196262B7D),cn=policies,cn=system,DC=corp,DC=com;0]> Searching <OU=Human Resources,DC=corp,DC=com> Found GPO(s): < > <OU=Human Resources,DC=corp,DC=com> has the Block From Above attribute set Searching <DC=corp,DC=com> Found GPO(s): <[LDAP://cn={7AF6DlA4-4CAB-44FF-8003- 67ED8241FFAB},cn=policies,cn=system,DC=corp,DC=com;0][LDAP://CN={31B2F340-016D- 11D2-945F-OOC04FB984F9},CN=Policies,CN=System,DC=corp,DC=com;0]> GPO will not be added to the list since the Block flag is set and this GPO is not in enforce mode. Searching <CN={9A3B670A-3280-4687-A80A- 4C8196262B7D},CN=Po1icies,CN=System,DC=corp,DC=com> User does not have access to the GPO and so will not be applied. Found functionality version of: 2 Found file system path of: <\corp.com\SysVol\corp.com\Policies\{9A3B670A- 3280-4687-A80A-4C8196262B7D}> Sysvol access skipped because GPO is not getting applied. Found common name of: <{9A3B670A-3280-4687-A80A-4C8196262B7D)> Found display name of: <Hide Settings Tab / Restore Screen Saver Tab> Found user version of: GPC is 2, GPT is 65535 Found flags of: 0 Found extensions: [{35378EAC-683F-11D2-A89A-OOC04FBBCFA2}{OF6B957E-509E-11D1- A7CC-OOOOF87571E3}]

You can learn a lot quickly by doing a little sleuthing inside the results. First, the computer is processing in Normal mode (as opposed to Loopback mode). And, while you're here, you can sniff out two back-to-back "errors" that I've detailed below.

The first error occurred due to some Active Directory site misconfiguration error. The text is clear: "No site name defined. Skipping site policy."

The second error occurred when the GPO represented by GUID 7AF6D1A4-4CAB-44FF-8003-67ED8241FFAB wasn't applied. This is the "Hide Desktop Tab" GPO we created and linked to the domain. The report states that the "GPO will not be added to the list since the Block flag is set and this GPO is not in enforce mode." This indicates that the GPO isn't being enforced while the OU level ( Human Resources ) is blocking inheritance.

The last error occurred when the GPO with the GUID 9A3B670A-3280-4687-A80A-4C8196262B7D was not applied due to "User does not have access to the GPO." In my case, the GUID matched with the "Hide Settings Tab/Restore Screen Saver Tab" GPO. Back in Chapter 2, one example denied the HR-OU-Admins security group the access to read that GPO, so it would not apply to them. Frank Rizzo is a member of the HR-OU-Admins group and, hence, does not get the GPO.