Locating Troublesome Policies
People have frequently asked me whether they can "turn off" Group Policy for a user or computer so that the settings return to the default state. Although you can use security filtering to prevent a given user or computer from processing a GPO, doing so doesn't return all settings for that user or computer to their default state if the policy has already been applied. There's no easy way to "turn off" Group Policy, which is all the more reason you should always thoroughly test every Group Policy—related change, no matter how small it seems, in your user environment. The general approach for solving Group Policy—related problems with your users' desktops is to first determine what settings are being applied, then isolate those settings one by one until the problem disappears. This process can be tedious and time consuming, but tools and techniques are available to make the job easier.
Your first step when trying to track down Group Policy—related problems is to run a Resultant Set of Policy (RSoP) report on the problem client. An RSoP report tells you what policy settings are being delivered to the client and helps you narrow down the possible causes of problems. Depending on the OS version you're using, the tools that you can use will vary. If your clients are running Windows 2000, for example, you'll need to rely on the gpresult.exe command-line utility from the Microsoft Windows 2000 Resource Kit. However, Win2K supports only limited RSoP capabilities, and the gpresult.exe tool won't produce complete results for categories such as security policies. If you have XP, you have a variety of tools at your disposal. The first and simplest tool to run is rsop.msc, which is on every XP Professional system. That tool provides a quick RSoP report—in the familiar Group Policy Editor (GPE) format—for the currently logged-on user, as Figure 3 shows.
You can also use Group Policy Management Console (GPMC) to remotely create an RSoP report against an XP client. GPMC's Group Policy Results Wizard provides an HTML-based report that shows the user and computer policies processed and which GPOs delivered those policies. Windows Server 2003 and XP also include a more complete version of gpresult.exe that provides a command-line mechanism for generating an RSoP report.
After you've generated an RSoP report for your policy settings and you know which GPOs you're dealing with, the next step is to narrow the list. But first, it's important to understand some things about how policies—and specifically Administrative Template policies—are applied.
Policies, Preferences, and Orphaned Settings
As I mentioned earlier, Windows components read the registry values that Administrative Template policies set to control the behavior or lockdown of those components. All true policy settings are stored under one of four subkeys in the registry. Two of those subkeys are per-computer, and two are per-user. The per-computer subkeys are HKEY_LOCAL_MACHINE\Software\Policies and HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies. The per-user subkeys are HKEY_CURRENT_USER\Software\Policies and HKEY_CURRENT_USER\Software\Micrsoft\Windows\CurrentVersion\Policies.
If a computer or user has entries under any of these subkeys within the registry, that computer or user is receiving some type of policy. With few exceptions, Administrative Template settings that ship with Windows today are considered policies and write their values under one of these four subkeys.
Microsoft also supports the ability to create custom .adm template files that let you specify registry values for subkeys other than the four listed here. Custom templates, called preferences, can set values under any registry key. Preferences can come in handy when you need to be able to set a registry value for which Microsoft hasn't provided an .adm file, such as for non—policy-aware applications or Windows system settings that don't fall under one of the four policy keys listed above. For example, I've created a custom .adm file that enables Group Policy logging on Windows systems; all the registry values that enable that logging are preferences. However, the downside to preferences is that they aren't removed automatically if the GPO that delivered them no longer applies to the computer or user. When that happens, the result is referred to as tattooing, and it was a common annoyance with system policies in NT 4.0 and Win9x.
Preferences are important to be aware of because they can cause no end of difficulty when you're trying to troubleshoot GPO-related problems. Because preferences aren't removed with the GPO, you need to ensure that you explicitly set a preference to Not Configured or disable it before you remove the GPO that implements it. Removing the GPO without first disabling the preference can result in tattooed policy settings.
The policies you see in GPE under the Administrative Templates sections are a function of which .adm files the GPOs use. Let's say that you've edited a Microsoft .adm file to add a preference setting for a registry value you want to enforce. In the next Windows service pack release, Microsoft updates that .adm file and your preference options are lost. Because the policy has already been enabled, that setting is stored in the GPO. However, you can no longer see the preference in GPE, so you can't undo the setting. That setting is an orphan. In that case, you'd need to redo your custom preference in the .adm file so that you can again manage it. A better practice is to always create a separate .adm file for any custom policy settings and not to edit the Microsoft.adm files.
After you've run RSoP on your problem client, the next step is to identify the policy setting that's causing the problem. Although you could very easily try to remove all the GPOs that apply to a given user or computer and perhaps solve the immediate problem, doing so won't help you identify which policy setting is causing the conflict. Furthermore, although that approach will work for Administrative Template policies, as I mentioned above, it won't work for preferences. Nor will it work for security policies, which also effectively tattoo your systems because they aren't removed when you remove the GPO that delivers them. So, we'll need some other tools and techniques to try to pin down the source of the trouble.
