Microsoft

SolutionBase: Tools you can use to troubleshoot Group Policies in Windows Server 2003

Troubleshooting group policies in Windows Server 2003 can be challenging unless you know the tools you can use to get the job done properly. In this article, Brien Posey points out what's available to figure out what's wrong with group policies under Windows Server 2003.

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 results.

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.

Event Viewer

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 Viewer.

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 sensitive).

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.

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 hard drive.

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.

Figure B

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 wonderful tool.

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 coming from.

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.

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:

  • The last time that the group policy was applied and which domain controller applied it
  • A complete list of which group policy objects have been applied
  • Registry settings that have been applied and their details
  • Information regarding folder redirection
  • Information on software applications that have been assigned or published via group policy
  • Disk quote information
  • Information on how the IPSec protocol is being used
  • Information 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.

Figure D

The Advanced System Information Policy Tool gives you a simplified view of policy settings that have been applied to the machine.

Editor's Picks

Free Newsletters, In your Inbox