Group Policies, which were first introduced in Windows 2000, made the System Policies that were provided in earlier versions of Windows, obsolete. Their functionality, however, extends well beyond registry changes available through System Policies, including features such as deploying software or controlling security. Group policy is considered one of the most important benefits of implementing Active Directory and the primary factor in lowering total cost of ownership.
Although configuring Group Policies can be fairly easily accomplished with the Group Policy Editor MMC snap-in, it seems like other aspects of their management were overlooked by Microsoft. This is most apparent to administrators who manage multidomain forests, with complex hierarchy of organizational units and large number of Group Policy Objects. The following Group Policy operations are the most commonly performed:
- Copying settings from one GPO to another
- Backing up and restoring GPOs
- Troubleshooting Group Policies
The features for the first two items require cumbersome workarounds or use of third-party tools. Microsoft promised to provide this type of functionality with the release of Windows .NET server, and these issues will be the topic discussion in the next article.
Here, I will focus on the following techniques to troubleshoot Group Policies.
- Group Policy logging
- GPResult Resource Kit utility
- Resultant Set of Policies
- Third-party tools
Group Policy Logging
This feature is available in Windows 2000 and XP. You can enable detailed logging of Group Policy processing on a client system by modifying the registry. Entries that control this behavior reside under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics subkey (most likely you will need to create it).
The entry AppMgmtDebugLevel of type REG_DWORD set to the value 4b (Hex) will generate verbose logging of all activities relating to processing of Software Deployment Group Policies. Other Group Policy actions can be logged by creating the entry RunDiagnosticLoggingGroupPolicy of type REG_DWORD and setting it to 1.
After you reboot the computer, the detailed description of each action associated with the group processing will appear in the computer's Application Log. You will be able to find out each of the GPOs that was applied to both computer and user configuration, and, if applicable, the reason for the GPO not being processed. Keep in mind that enabling Group Policy logging slows down the logon process and affects the rate at which the Application Log will grow.
For troubleshooting Group Policies relating to user configuration, you can also use the the UserEnv.LOG file stored in the %SystemRoot%\Debug\UserMode folder. The level of details logged into this file depend on the value of the UserEnvDebugLevel entry of type REG_DWORD stored in the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon registry key. Setting it to 10002 (Hex) will result in verbose logging. This gives you very detailed information but also significantly increases the size of the UserEnv.LOG, so main use would be for troubleshooting. To switch it back to the default, either delete the UserEnvDebugLevel entry or set it to 10001 (Hex). To disable it completely, set its value to 0.
This command line Resource kit utility is downloadable, along with a number of other free Resource Kit tools from the Microsoft Web Site. In addition to the computer and user information (such as Distinguished Name, group membership, and site and domain membership), GPResult displays the last time Group Policy was applied. It lists all of the Group Policy Objects that were applied to both computer and user, as well as Group Policy Objects that were filtered out. To see the individual settings of each of Group Policy Objects, use /V (for verbose). You can execute GPResult against the local or remote system (by specifying the target computer name with /S switch). GPResult is built into Windows XP Professional.
Resultant Set of Policies
If your clients are running windows XP Professional, you can use the built-in MMC-based Resultant Set of Policy (RSOP) snap-in. You can invoke it by typing RSOP.MSC from the Command Prompt (or Start->Run box). In this case, RSOP will display the resulting Group Policy settings for the local computer and the currently-logged-on user account. You can also launch the empty Microsoft Management Console and add the RSOP snap-in to it. This will enable you to specify the target computer and user that is or was logged on to it (the RSOP will use user information from one of the cached profiles to analyze settings for users who logged on to the target computer in the past).
RSOP is the most friendly tool for troubleshooting Group Policies. It displays the results in a format similar to the interface used by the Group Policy Editor, listing each of resulting computer settings and the source GPO where the setting originated. In addition, for each setting you can find out all of the GPOs that had this setting configured and their precedence.
Currently, RSOP supports only logging mode (planning mode will be available in Windows .NET server).
The most popular tools for troubleshooting Group Policies are FAZAM 2000 (from FullArmor) and Active Administrator (from Small Wonders Software). For more information, refer to the manufacturers' Web sites.