In Debugging user profile and GPO problems with Userenv logs, we reviewed the basics of the Userenv.log file and how it can be used to diagnose issues in Group Policy. The Userenv.log, which contains details about user profiles and Group Policy Object (GPO) processing, resides in %SystemRoot%\debug\usermode and is generated automatically by the Winlogon process.
The log is fairly easy to read, and there are some important points to be aware of when using it, including:
One thing that was not discussed in the previous article involves the processing of Group Policy Extensions (GPEs). GPEs are add-ons to Group Policy and act somewhat independently, even though they appear to be an integral part of a GPO. The following table identifies the extensions as well as their associated DLL.
[TABLE]
In Figure 1, the extensions and related information (such as the DLLs listed here) are exposed in the registry under the Winlogon key at:
Figure 1
[IMAGE]
Note that they are stored under key names corresponding to the GUID of the GPE. Just as the Default Domain Policy and Default Domain Controllers Policy have GUIDs that are the same on every Active Directory installation, the GPE GUIDs are likewise common in all installations. To resolve these GUIDs to a friendly name, simply click on one of the GPE folders and look at the values exposed in the right-hand pane. In Figure 1, the folder we clicked on is the Scripts folder. In the right pane, the top value (Default) shows "Scripts," and the DLL Name is gptext.dll. The DLL Name is important as you will see later.
At startup and user logon, Group Policy Extensions are processed in the following order:
Troubleshooting Group Policy Extension problems
Troubleshooting GPEs is a bit tricky because you have to think of them as an "extension" to the policy as opposed to the policy itself. For
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
example, I often hear an administrator say that his logon script isn't working but the policy is applying. He configured a setting such as "Add Logoff to the Start Menu." The policy applies and the "Add Logoff to the Start Menu" is taking effect, but the logon script, defined in the same policy, is not running. How can this be? If the policy applies, why will some settings apply and not others?
Of course there are the basic checks for a logon script problem:
Beyond that we can check the Userenv.log. When a GPO is processed, if any GPEs are processed, they will be listed by GUID. For example, the following entry in the Userenv.log shows that the Scripts, Security and EFS Recovery extensions are processed, respectively. I just looked in the registry and looked up the friendly name of the extension.
The answer for the confused admin is that the logon script is a GPE. As an extension it is processed separately by its own DLL and must be debugged separately. While the GPO processing is exposed in the Userenv.log file as was just noted, the processing of extensions produces an additional log. These logs are stored in the same place as the Userenv.log, %SystemRoot%\debug\usermode, and they are named for the DLL that processes the GPE. For example, we see in Figure 1 that gptext.dll is the GPE for Scripts. Thus, when errors occur in processing the script, they will be logged in a file called "gptext.txt" in the %SystemRoot%\Debug\UserMode directory.
In Troubleshooting a logon script problem using Userenv and GPE logging, we'll take a look at a case study in which Userenv and GPE logging are required to troubleshoot a logon script problem.
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. Gary is a Microsoft MVP for Windows Server-File Systems.
