Problem solve Get help with specific problems with your technologies, process and projects.

Case Study: Troubleshooting a logon script problem using Userenv and GPE logging

Understanding the value of Userenv and GPE logs is only half the battle. Software engineer and author Gary Olsen shares a case study to demonstrate how the logs can be used in a real-life situation.

USERENV(a8.23c) 17:55:25:682 ProcessGPOList: Extension Scripts returned 0x2.
USERENV(a8.23c) 17:55:25:772 ProcessGPOs: Extension Scripts ProcessGroupPolicy failed, status 0x2.

This entry is pretty clear. The scripts extension failed with an error code of 0x2. This type of error code can...

be resolved with the Net Helpmsg command from a command prompt:

C:\>Net Helpmsg 2

The system cannot find the file specified.

This, however, doesn't make sense because we drilled into SYSVOL and found the script in the proper place and even executed it from that spot. Looking further at the Userenv.log, we see the result of processing the User section.

USERENV(a8.294) 17:57:35:149 ProcessGPO: Searching <CN={E76EFF53-7C02-4BCB-9288-D24774D06BFD},CN=Policies,CN=System,DC=Corp,DC=net>
USERENV(a8.294) 17:57:35:149 ProcessGPO: User has access to this GPO.
USERENV(a8.294) 17:57:35:149 ProcessGPO: Found functionality version of: 2
USERENV(a8.294) 17:57:35:149 ProcessGPO: Found file system path of: <\\\SysVol\\Policies\{E76EFF53-7C02-4BCB-9288-D24774D06BFD}>
USERENV(a8.294) 17:57:35:149 ProcessGPO: Found common name of: <{E76EFF53-7C02-4BCB-9288-D24774D06BFD}>
USERENV(a8.294) 17:57:35:159 ProcessGPO: Found display name of: <Scripts Policy>
USERENV(a8.294) 17:57:35:159 ProcessGPO: Found user version of: GPC is 2, GPT is 0

In the last entry, we see that the GPC version is at 2 but the GPT (SYSVOL) version is 0, so there must be a problem with processing the script in the context of SYSVOL. Still further, in the Userenv.log, we see the following:

USERENV(a8.294) 17:57:35:339 ProcessGPOs: Processing extension Scripts
USERENV(a8.294) 17:57:35:339 CompareGPOLists: The lists are the same.
USERENV(a8.294) 17:57:35:339 CheckGPOs: No GPO changes but extension Scripts had returned ERROR_OVERRIDE_NOCHANGES for previous policy processing call.
USERENV(a8.294) 17:57:35:339 ProcessGPOList: Entering for extension Scripts
USERENV(a8.294) 17:57:35:339 UserPolicyCallback: Setting status UI to Applying Scripts policy...
USERENV(a8.294) 17:57:35:349 ProcessGPOList: Extension Scripts returned 0x4e4.

Again, we see that the GPO is not being processed because there were no changes made since the last processing. Also, there is an error in the previous processing of this GPO, and an error code of 0x4e4 was returned. We know that 0x4e4 can't be resolved by Net Helpmsg, so that doesn't help, and that is the last reference to scripts processing in the Userenv.log file.

Still, since we have a gptext.txt, we can look in it for further clues. Opening up this file, we find the following entries:

GPTEXT(a4.454) 08:39:31:895 ProcessScriptsGroupPolicy: Both the logon script and logoff script are NULL, but at least one command line should be present.
GPTEXT(bc.23c) 09:08:31:107 ProcessScriptsGroupPolicy Failed to get file attributes of \\\SysVol\\Policies\\{E76EFF53-7C02-4BCB-9288-D24774D06BFD}\Machine\Scripts\scripts.ini with 2

We can deduce two things from these entries:

  1. There is a null entry for logon and logoff scripts; and somewhere, a command line is missing.

  2. Accessing a file called Scripts.ini returned an error code of 2, which, when run through Net Helpmsg, means the file can't be found.

So what now? Digging into theSysvol\sysvol\\Policies\{E76EFF53-7C02-4BCB-9288-D24774D06BFD} \Users\scripts\logon, we can find the scripts.ini file. Opening it shows it was blank. That certainly explained the event in Gptext.txt stating "at least one command line should be present" and then the next event involving the Scripts.ini. If we create a scripts policy with a properly defined logon script in a test environment, we should see that the Scripts.ini was created with that policy. Opening Scripts.ini shows the following:


Note: The first line in the file was blank.

We then created a Scripts.ini file, added the lines we found from the test Scripts.ini and substituted the correct name of the logon script, which solved the problem.

The point here is that without the gptext.txt extension log, we wouldn't have had the clue about Scripts.ini -- just a bunch of errors complaining about the path.

The Userenv.log and the various GPE logs are very helpful in resolving Group Policy problems. These logs are located in %systemRoot%\debug\usermode on all Windows machines, servers and workstations. Just be sure to remember that verbosity must be set in the registry on the Winlogon key to provide any meaningful data, and that each of the Group Policy Extensions produce their own log (named after the DLL that the extension uses). Unfortunately, Microsoft never provided a date in the time stamp on the log entries, and new entries are appended to the existing log. Here's the proper way to get current data:

  1. Delete or rename all Userenv.log and *.txt logs currently in %systemRoot%\debug\usermode on the client and the DC that is authenticating the client.

  2. Either log off and back on and reproduce the problem for User issues, or reboot the machine and reproduce the problem for machine-related issues. The Userenv.log and GPE logs will be recreated.

Using this information -- along with what we learned about user profile and GPO problems -- we can enable a powerful tool in debugging Group Policy.

Do you have an Active Directory issue or problem that you'd like Gary to write an article on? Email him at [email protected].

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. 

Dig Deeper on Windows systems and network management