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:
Be sure to enable verbose logging using registry settings, as noted in KB 221833. Without verbose logging enabled, the Userenv.log is useless for troubleshooting.
Pay attention to errors and warnings involved in the processing.
GPOs are listed in processing order. A search is completed by domain and OU, which the user and computer are members of, and GPOs are detailed in order.
If a GPO is not processed, the reason why will be given (for example, no changes since the last processing).
Important GPO information includes:
* Testing access to the GPO
* GPO's Display Name (GUID) and Common Name (friendly name)
* Group Policy Template (SYSVOL) and GPS (AD) versions of the GPO
* Path of the GPO
* GPO Extensions processed
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.
| Policy Extension Name
|
DLL Name
|
| Security Processing
|
Scecli.dll
|
| Folder Redirection
|
Fdeploy.dll
|
| Software Installation and Maintenance
|
Appmgmts.dll
|
| Wireless Policy
|
Gptext.dll
|
| IE Zone Mapping
|
Iedkcs32.dll
|
| IPsec
|
Gptext.dll
|
| IE Branding
|
Iedkcs32.dll
|
| Scripts
|
Gptext.dll
|
| Disk Quotas
|
Dskquota.dll
|
| EFS Recovery
|
Scecli.dll
|
| Quality of Service (QoS) Packet Scheduler
|
Gptext.dll
|
| Offline Files
|
Cscui.dll
|
In Figure 1, the extensions and related information (such as the DLLs listed here) are exposed in the registry under the Winlogon key at:
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions
Figure 1
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:
Registry (Admin Templates)
Windows Installer
Folder Redirection
Disk Quotas
QoS Packet Scheduler
Scripts
Security
Internet Explorer Branding
WMI
EFS Recovery
Application Management
IP Security (IPsec)
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 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:
Execute the script locally to make sure there is not a problem with the script itself.
Connect to the SYSVOL share from another computer and run the script remotely to see if there is a problem with permissions.
Check GPResult. If a script was processed, the GPO containing the script would be listed. If there is none listed, the script was not processed.
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.
USERENV(a8.23c) 17:55:25:321 ProcessGPO: Found extensions: [ [{42B5FAAE-6536-11d2-AE5A-0000F87571E3}{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}]
Note: This is the discovery phase of the GPO extensions. Processing will appear later in the Userenv.log.
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.
