In the article “Troubleshooting Group Policy in Windows
Server 2003”, I talked about some basic troubleshooting techniques related
to the inability to use the Group Policy Editor and related to group policy
objects not being applied in the expected manner. In this article, I want to
continue the discussion by demonstrating some tools that you can use to help
troubleshoot group policy objects that do not provide you with the expected
Before I begin
Before I get started, I need to mention that some of the
techniques that I will be discussing require you to modify your server’s
registry. Modifying the registry is dangerous. Making an incorrect modification
can destroy Windows and / or your applications. I therefore recommend that you
perform a full system backup prior to performing any registry modifications.
As I’m sure you are aware, one of the first things that you
should look at any time that you are troubleshooting a problem within Windows
is the Event Viewer. By default, the Event Viewer’s System log will provide you
with basic information regarding Windows’ health. What you might not realize
though is that you can tweak Windows so that more detailed information,
specifically related to group policy objects, is presented through the Event
To gain access to this extended logging information, you
will have to modify the server’s registry. To do so, enter the REGEDIT command
at the Run prompt to open the Registry Editor. When the Registry Editor opens,
navigate through the registry tree to
HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/Current Version. At this
point, right-click on the CurrentVersion container and select the New | Key
commands from the resulting shortcut menus. When prompted to enter a name for
the new key, enter Diagnostics (case
sensitive). Now, right-click on the key that you just created and select the
New | DWORD Value commands from the shortcut menus. You will now be prompted to
enter a name for the value that you are creating. Call the new value RunDiagnosticLoggingGroupPolicy (case
Once you have created the RunDiagnosticLoggingGroupPolicy
registry value, double-click on it to access the Edit DWORD Value dialog box.
Set the value’s Value Data to 1 and make sure that the Hexadecimal option is selected
prior to clicking OK.
Normally, when you make a modification to the registry, the
change occurs immediately. In this particular case though, you have to log off
and log back in before your change will take effect. When you log back in, open
the Event Viewer. All of the group policy related logging information will be
presented within the Application log. You will be able to differentiate the
group policy related log entries from other log entries because the event’s
source will be listed as Userenv, as shown in Figure A.
|Group policy related log entries will be presented in the Application log
with an Event Source ID of Userenv.
One last thing that I want to say about diagnostic logging
is that you should only enable it when you are actively trying to troubleshoot
a problem. Even on a system that is functioning perfectly and that has
relatively little activity, the diagnostic logging option can cause hundreds of
events to be added to the Application log in a matter of a couple of minutes.
At that rate, it won’t take long for the log to become completely flooded.
Therefore, it is critical that you disable diagnostic logging when you have
finished using it.
More detailed logging
Diagnostic logging gives you a lot of detail regarding the
inner workings of group policies. If you need even more detail though, there is
another type of log that you can create. The technique that I am about to show
you does not use the Event Viewer or the Application log. Instead, it creates a
log file named USERENV.LOG and places it into a hidden folder on your server’s
To create this particular log file, you must enter the
REGEDIT command at the Run prompt to launch the Registry Editor. When the
registry editor opens, navigate through the registry tree to
HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/Current Version/Winlogon.
Next, right-click on the Winlogon key and select the New | DWORD Value commands
from the resulting shortcut menus. When prompted, enter UserenvDebugLevel (case sensitive) as the name of the new value. At
this point, you must double-click on the new value that you’ve just created to
access the Edit DWORD Value dialog box. Set the value data to 30002, verify
that thee hexadecimal option is selected and click OK.
Once again, you will have to log out and log back in for
your changes to take effect. After logging in, go to the
%systemroot%\Debug\Usermode folder and open the USERENV.LOG file. By default,
the .LOG file extension isn’t associated with an application, and
right-clicking on the log file doesn’t give you an Open With option for some
reason (at least not on my machine). Therefore, you may have to go into Notepad
and open the file directly.
Figure B shows what the log file looks like. As you can see
in the figure, the information in this log file is different from what you get
through the Event Viewer. Interpreting the log file can be a little
intimidating at first, but it really isn’t very complicated once you understand
what it is that you are looking at. Each line represents a separate log entry.
The first piece of information that you are given is a processing code. In
Figure B, each line has the same processing code of USERENV(2c8.2cc). The
processing code isn’t really important. It basically just identifies that you
are examining information related to a group policy.
|This is what the USERENV.LOG file looks like.|
The next piece of information that you are presented with is
a time stamp. The time stamp is little odd because it doesn’t contain a date.
Personally, I’m not sure if I have ever seen the time listed in the way that it
is in the log file. Even so, only the first few digits are usually significant.
The entries shown in Figure B were made at 9:33 AM.
The next piece of information that is presented is the name
of the process that produced the event. For example, in the top line of the log
file shown in Figure B, the process name is LoadUserProfile. The process name
is followed by a colon, and finally by a brief description of the event.
When I talked about using the Application log for diagnostic
logging earlier, I mentioned that you needed to disable diagnostic logging when
you weren’t actively using it, as a way of preventing flooding. Flooding is
also a concern when it comes to the USERENV log. The USERENV.LOG file will
never grow to more than 1 MB in size. However, once the log accumulates a
megabyte worth of data, the existing log entries are moved into a file named
USERENV.BAK. This insures that the USERENV.LOG file always contains the most
current log data. It is important though that you disable the logging feature
when ever you are not actively using it, to prevent the USERENV.BAK file from
depleting your server’s disk resources. Even if disk space is not a concern,
logging also places a significant strain on your server’s CPU.
Resultant Set of Policy
One of the best group policy diagnostic tools is the
Resultant Set of Policy console. I don’t want to spend too much time talking
about this one because I recently wrote a full length article about it, but at
the same time I feel like I would be negligent if I wrote an article on
troubleshooting group policies and didn’t at least briefly talk about this
The most common problem with group policies is that the
various group policy objects don’t always combine together to give the
administrator the expected results. The idea behind the Resultant Set of Policy
console is that you can view the effective policy, and if the effective policy
is something unexpected, you can see where the unexpected policy setting is
To use the Resultant Set of Policy console, enter the MMC
command at the Run prompt to load an empty Microsoft Management Console. Next,
select the Add/Remove Snap-In command from the console’s File menu. When you
do, you will see the Add/Remove Snap-In properties sheet appear. Click the Add
button to reveal a list of the available snap-ins. Select the Resultant Set of
Policy option from the list and click the Add button, followed by the Close and
OK buttons. The Resultant Set of Policy tool is now loaded into the console.
To begin using the tool, right-click on the Resultant Set of
Policy container and select the Generate RSOP Data command from the shortcut
menu. This will launch the Resultant Set of Policy Wizard. Click Next to bypass
the wizard’s Welcome screen and you will be asked if you want to run the wizard
in logging mode or planning mode. Since you are attempting to troubleshoot an
existing policy, select the Logging Mode option and click Next.
The next screen that you will encounter will prompt you for
a computer name. As you probably know, group policies are applied to both users
and to computers. It is therefore important that you enter the name of the
computer that you noticed the problem occurring on. Click Next and you will be
prompted to enter the name of one of the users who is experiencing the problem.
Click Next again and you will see a summary of the information that you have
entered. Assuming that everything looks correct, click Next one more time and
the wizard will begin assembling information regarding the effective policy for
the user / computer that you have selected.
The effective policy will be displayed within the Group
Policy Editor. All you have to do now is to navigate through the Group Policy
Editor to the setting that is being applied incorrectly. Right-click on the
setting and select the Properties command from the resulting shortcut menu. You
will now see a properties sheet for the setting. The properties sheet’s
Security Policy Setting tab will show you the effective policy for that
particular setting. More importantly though, the Precedence tab will show you
where that policy setting was assigned, as shown in Figure C.
|The Precedence tab will display the name of the group policy object that
assigned the value for the setting.
The GPRESULT tool
Another tool that you can use to diagnose group policy
related issues is the GPRESULT tool. The GPRESULT tool is basically a command
line version of the Resultant Set of Policy tool. The biggest difference
between the two tools is that the Resultant Set of Policy tool is designed to
make it simple to figure out where a particular policy setting is coming from.
GPRESULT isn’t as easy to use as the Resultant Set of Policy
tool, but it provides you with a lot more information. I don’t want to spend a
lot of time talking about GPRESULT because I am about to write a full length
article on it, but I will tell you that GPRESULT gives you the following types
of information that you can’t get from the Resultant Set of Policy Tool:
last time that the group policy was applied and which domain controller
complete list of which group policy objects have been applied
settings that have been applied and their details
regarding folder redirection
on software applications that have been assigned or published via group
on how the IPSec protocol is being used
on scripts being called by the group policy
As I said, I will be writing a full length article on
GPRESULT in the very near future. If you would like to experiment with GPRESULT
in the mean time though, you can view the command’s full syntax by entering the
GPRESULT /? Command in a Command Prompt window.
The Advanced System Information Policy Tool
One last tool that I want to mention is the Advanced System
Information Policy Tool. The Advanced System Information Policy Tool doesn’t
give you nearly as much information as the Resultant Set of Policy tool or as
GPRESULT. The advantage of this tool though is that it is designed to be used
by novices and is therefore very simple to use and to understand.
You can access this tool by choosing the Help and Support
option from your server’s Start menu. When the Help and Support Center appears,
click the Tools link Next, expand the Help and Support Center Tools container
and click the Advanced System Information option. You will now see a report of
the resultant set of policy for the machine, as shown in Figure D.
|The Advanced System Information Policy Tool gives you a simplified view of
policy settings that have been applied to the machine.