Although the Userenv.log is not the most cryptic log there is to read, it isn't exactly intuitive. IT managers...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
do need some experience using it to extract information out of it to help them troubleshoot problems.
Generated by the userenv.dll, Userenv.log collects events -- including errors, warnings and informational messages related to the processing of Group Policies and the user profile configuration for a particular user during logon. KB221833 describes how to set verbose logging in the Userenv.log because normal output is useless for debugging problems.
To set verbose logging, set the registry key: Subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Entry: UserEnvDebugLevel Type: REG_DWORD Value data: 10002 (Hexadecimal)
How to use Userenv.log to debug Group Policy and profile problems.
Because Userenv.log is produced on every client and server for Windows 2000, Windows Server 2003 and XP, the procedure is to collect the Userenv.log on the client and its authenticating DC.
In the past, one of the most frustrating things was that the time stamp on events in the Userenv.log had no date. So to refine your troubleshooting to the current day, you had to delete or rename the old Userenv.log and then reproduce the problem. This was inconvenient and time-consuming.
Good news: Windows Vista and Windows Server 2008 do not use a Userenv.log. Instead, they dump it to the event viewer. There is now a Group Policy Operational Log that will log events specifically with Group Policy as the source.
In addition, Group Policy-sourced events will show up in the system event log. This is unlike the old Group Policy events that carried a userenv source along with a variety of other events related to such things as profiles. Furthermore, you can add verbosity to these events by setting a registry key:
Set this to a DWord type and data of 10002. Note the similarity between this value and the UserEnvDebugLevel value above. This one will produce a GPEdit.log in the %windir%\debug\usermode directory, which is the same location that the old Userenv.log was located. Remember: This log contains Group Policy information exclusively, unlike Userenv.log.
If you haven't looked at the new event viewer in Windows Vista and Windows 2008, you should. Figure 1 shows a sample event viewer on a Windows 2008 domain controller.
Figure 1: Sample event viewer on a Windows 2008 domain controller.
The Windows Vista version will look similar but won't have the DC-related logs. It uses the new MMC 3.0 snap-in, like so many other administrative tools that have come out since Windows Server 2003 R2, so you should be getting used to the three panes.
Note in Figure 1 that the event viewer is considerably more complex than Windows Server 2003 with just a handful of event logs. See how far we had to drill down in the left pane to find the Group Policy Operational log. However, there is a very cool feature at the top of the left pane called Custom Views. Expanding Custom Views, as shown in Figure 2, we see Administrative Events.
Figure 2: Administrative Events
This is a collection of "Critical, Error and Warning events from all administrative logs," as the properties description of this group describes. With so many logs available, this is a nice summary of critical errors that Windows administrators should pay attention to -- sort of an automatic Eventcomb output. In Figure 2, we see a lot of Group Policy errors, which is much more descriptive than "Userenv."
You may choose to add your own custom views. For instance, maybe you want to have the Group Policy log added to Custom Views so you can see more of the Group Policy events that might help debug the critical Group Policy events shown in the Administrative Events custom view.
To do this, right click on Custom Views and select Create Custom View. In Figure 3, you can see the dialog shown in Create Custom View.
Figure 3: Dialog in Create Custom View.
Note that you can select the type of events to save -- critical, error, warning, etc. -- and that you can simply select "verbose." This is much easier than messing with the registry as previous Windows versions required.
See how we selected "by log" and browsed to the Group Policy Operational log and checked it. We can set up more filter features such as keywords if we wish. We also could have elected to create a custom view based on one or more event sources.
I like to think of Custom Views like the Saved Queries option in the Active Directory Users and Computers (ADUC) snap-in. It will then prompt us for a name -- and I specified "Group Policy" -- as well as a location for the view. I said to put it under Custom Views. You may want to keep this Group Policy custom view permanently, or you may want it just for debugging this problem and delete it later.
This feature of event viewer will undoubtedly prove to be a powerful debugging tool in Windows Server 2008 and Windows Vista. It also makes debugging Group Policy issues much easier than in older Windows products.
ABOUT THE AUTHOR
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Olsen is a Microsoft MVP for Windows Server-File Systems.