In 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.
Further, in the Userenv.log we see another clue where the processing is attempted:
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:
This, however, doesn't make sense bec...
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
ause 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.
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:
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:
We can deduce two things from these entries:
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:
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:
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.
