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

Gary Olsen

    Requires Free Membership to View

Userenv and GPE logging: A great tool for debugging Group Policy Extensions, we discussed how Userenv and GPE logs can be valuable tools for debugging Group Policy.

Now, let's look at an example of how we can use the Userenv.log and the GPE log to troubleshoot a logon script problem.

The problem is simply that a logon script is not applying at user logon. The policy it is applied to is processed for other settings but the script itself is not running. We verified that we can run the script by specifying the Universal Naming Convention (UNC) path from another computer, so there must be some problem with the GPO processing of the extension.

Since this is a Group Policy Extension, it can be found in %SystemRoot%\Debug\UserMode as gptext.txt. Previously, we saw that gptext.dll processed the scripts extension, so the log will be written to gptext.txt. Note that this file only exists if the processing encounters errors, so you won't normally see it. Also, remember that there are several extensions that use gptext.dll, so this log isn't exclusive to script errors.

The first step is to look at the Userenv.log for clues. First, we see that the "Scripts Policy" is found, but there were no client-side extensions because both the GPC (Active Directory object) version and the GPT (SYSVOL) version are zero (0). So we know the GPO was discovered but that it contains no data. In this case, the Scripts Policy only had the logon script defined, and there were no other settings or extensions defined. Thus, we know that the script is not processing, so the GPO is not applied.

USERENV(a8.23c) 17:55:25:331 ProcessGPO: Found common name of: <{E76EFF53-7C02-4BCB-9288-D24774D06BFD}>
USERENV(a8.23c) 17:55:25:331 ProcessGPO: Found display name of: <Scripts Policy>
USERENV(a8.23c) 17:55:25:331 ProcessGPO: Found machine version of: GPC is 0, GPT is 0
USERENV(a8.23c) 17:55:25:331 ProcessGPO: Found flags of: 0
USERENV(a8.23c) 17:55:25:331 ProcessGPO: No client-side extensions for this object.
USERENV(a8.23c) 17:55:25:331 ProcessGPO: GPO Scripts Policy doesn't contain any data since the version number is 0. It will be skipped.
Further, in the Userenv.log we see another clue where the processing is attempted:
USERENV(a8.23c) 17:55:25:381 ProcessGPOList: Entering for extension Scripts
USERENV(a8.23c) 17:55:25:381 MachinePolicyCallback: Setting status UI to Applying Scripts policy...

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: <\\corp.net\SysVol\corp.net\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 \\company.com\SysVol\company.com\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 the Sysvol\sysvol\Corp.net\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 glo11749@yahoo.com.

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.

This was first published in April 2007

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.