Anyone who uses Group Policy to manage a Windows environment knows what an incredibly powerful and flexible technology it is. You can do everything from locking down your users' desktops to distributing software and enforcing corporate security policy. With literally thousands of individual settings available out of the box, you can usually find a configuration setting for almost anything you need to control in Windows.
Of course, a byproduct of all this power is that Group Policy can be complex to deploy and manage, and sometimes a setting can cause unintended consequences for users or applications. It's these unintended consequences that I discuss here. Because the hardest part of solving such problems often is identifying their source, I explain how to track down and identify some common Group Policy—related problems, then provide some techniques for eliminating them.
Common Types of Problems
Group Policy—borne problems can take a variety of forms. Most often, such problems manifest as application problems on user desktops or administrative problems for the people who manage those desktops. By far, the problems I see most in user environments arise from one of two general policy categories: desktop lockdown policies or security policies.
Desktop Lockdown Policies
In one environment that I supported, the use of the Administrative Templates Hide Drives policy (User Configuration\Administrative Templates\Windows Components\Windows Explorer\Hide these specified drives in My Computer) caused older applications to fail with obscure error messages that were unrelated to Group Policy. Even when no applications are involved, Group Policy restrictions can result in some fairly nondescript errors that can cause consternation to users and administrators alike. For example, if you implement the User Configuration\Administrative Templates\System\Don't run specified Windows applications policy to restrict a certain application from running, users will see the generic message that Figure 1 shows when they try to run the application.
Administrative Templates policies set per-computer or per-user registry values that are used by various components of Windows, such as Windows Explorer, Microsoft Internet Explorer (IE), and Windows Media Player (WMP), to restrict or control their use. You can control these applications through Group Policy only because Microsoft has written these Windows components to look for policy-related registry values. In other words, a developer must make a conscious choice to use policy-based registry values to control an application's behavior. When you use an Administrative Templates policy to lock down or hide elements of your users' desktops, those restrictions can sometimes interact with user applications in unexpected ways.
If you have a user who's receiving the message in Figure 1, it might not be immediately apparent what the cause of this message is—you know it's probably related to Group Policy, but you might not know how. Identifying the underlying problem is especially problematic if you're not the administrator who deployed the policy and you don't have any visibility into which Group Policy Objects (GPOs) have been deployed to this user or computer. Later, I'll present some tactics for identify7ing likely causes of such problems.
You might even get no error message at all, especially when a third-party application interacts poorly with desktop lockdown settings because the application developers didn't test it in a locked-down environment and didn't use APIs that interact well with Group Policy restrictions. Thus, it's important to ensure that your application vendors adhere to Microsoft's application specifications, which, among other things, detail how applications should be written to interact well with Group Policy. You can download the Designed for Windows XP Application Specification at http://www.microsoft.com/downloads/details.aspx?FamilyID=44aa70b3-99d9-4529-9117-82cc0845938b&displaylang=en.
Security Policies
I know of an administrator who wanted to prevent nonadministrative users from logging on to certain servers. His approach was to control which groups had the Logon locally user right. However, he inadvertently linked the GPO that contained the policy to the domain without using security filtering to apply the GPO only to the servers he wanted to restrict access to. After every computer in the domain processed the policy, all users in the organization were unable to log on to their desktops until the administrator realized what he'd done and fixed the problem.
This is just one example of problems that can arise related to security policy settings. Keep in mind that many of the Administrative Template restrictions I talked about earlier aren't real security lockdown policies. They are simply "shell obfuscations"—smoke and mirrors, if you will—to prevent users from doing things that might cause problems on their desktops. True security—user rights; password policy; file, registry, and service permissions; and so forth—is set in Group Policy's Computer Configuration\Windows Settings\Security Settings node.
Security policy settings can cause problems in several ways. For example, you might unintentionally set a security policy that causes certain basic operations to fail. For example, if you change the supported NTLM authentication level on a server or desktop using the Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network Security: LAN Manager authentication-level setting, you might get the error that Figure 2 shows and effectively prevent downlevel (e.g., Windows 9x systems that don't run the directory services client or Windows NT 4.0 Service Pack 3—SP3—and earlier) clients from accessing that system. Further, the error message you get typically doesn't reveal the nature of the problem, but rather indicates something more basic, such as an incorrect username or password. The Microsoft article "Client, Service, and Program Incompatibilities That May Occur When You Modify Security Settings and User Rights Assignments" (http://support.microsoft.com/default.aspx?scid=kb;en-us;823659) has an excellent review of which security-related policy settings can cause problems with various versions of Windows and recommends appropriate settings.
In a similar vein, some security policies can effectively lock administrators out of a system. For example, administrators can use the Restricted Groups security policy to control local group membership on workstations and member servers. This policy is often used to set the membership of the local Administrators group on all Windows desktops. The Restricted Groups policy contains two options. You can use the Members of this group functionality to ensure that only the users and groups that you specify are members of the local Administrators group and that all other users and groups are removed automatically each time the policy is processed. The other option for this policy is less absolute. The This group is a member of option lets you specify, for a given group, which other groups it should be made a member of. For example, you can use this option to put your Desktop Admins global security group into the local Administrators group on all your Windows workstations. A common problem occurs when administrators use the Members of this group option to control the local Administrators group, then forget to add the local Administrator account or Domain Admins account to the list, effectively locking themselves out of local workstations. Because this option replaces, rather than merges, group memberships, it's very easy to make this mistake and cause a lot of problems for yourself.
Many other policies can cause difficulties for your users, but in my experience, most problems—particularly unobvious problems—are caused by lockdown-related or security-related GPOs. So, let's look at some tools and techniques for tracking down user problems related to Group Policy.
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.
Tools and Techniques
If RSoP doesn't reveal which policy setting might be causing the problem, your next step is to narrow down the other possible sources. If you're not sure whether the problem is related to an Administrative Template policy or a security policy, you can try several things. Bearing in mind that Administrative Template policies provide only obfuscation and not security, the first hint as to where a problem is coming from is in the error messages it throws. For example, messages such as Access Denied or Permission Denied are clear indications of security rather than desktop lockdown issues, whereas error messages such as the one in Figure 1 are most probably Administrative Template—related.
If you get messages that aren't even this clear, you can use some tools to narrow down the problem. My favorite tool for tracking down possible Administrative Template—related problems is Sysinternals' free regmon.exe (http://www.sysinternals.com). Regmon lets you filter registry activity by registry key. By using Regmon during the operation that's causing problems to trace registry activity to one of the four policy-related subkeys mentioned earlier, you can often identify the policy that's causing the problem. Figure 4 illustrates how Regmon helped me track down a policy restriction that prevents Microsoft PowerPoint from running. Although this example is somewhat oversimplified (I'd have been able to see this policy using the RSoP tools without having to resort to Regmon), it gives you an idea of how you can use the tool to track down an Administrative Template policy when RSoP doesn't fill the bill.
If you suspect the problem might be related to a security policy, you need to try to identify and undo that policy. As I mentioned earlier, security policies essentially tattoo your systems if you remove the GPO without first removing the setting. Thus, to fix such a problem, you must explicitly reverse the specific security setting. If your organization's security requirements don't allow you to undo a security policy company-wide, you might instead want to isolate a few workstations to try and solve the problem. The best way to start from scratch in terms of security settings is to use the setup security.inf security template file to roll back Windows security to the default settings provided at setup. The setup security.inf file is located in %windir%\security\templates on all standard Windows systems. You can use the secedit.exe utility to apply this template, or you can import the template into the local GPO on a computer by opening GPE, right-clicking the Computer Configuration\WindowsSettings\Security Settings node, and choosing Import Policy.
After you've rolled back security to its setup state, you can retest the application to ensure that it's working, then reapply security policies, one setting at a time, until you identify the problematic setting. Obviously, this process can be extremely time consuming and should be considered only if you can't track down the problematic policy any other way. But as a last resort, using this approach on one or two test machines can help you locate the source of the problem you're experiencing.
As a general rule, when testing policy settings, try to change only one new setting at a time, then test that setting before you proceed to the next one. Although this approach slows policy deployment, it also makes troubleshooting policy settings much easier than if you were to make a large number of changes all at once.
Test, Test, Test
Group Policy provides many powerful capabilities. But if you don't thoroughly test GPOs before you implement them, they have the potential to interfere with your users' day-to-day functioning.
Always test your Group Policy settings before you implement them. If you run into problems, using the RSoP tools that Microsoft provides, as well as third-party tools such as SysInternal's Regmon utility, can make the process of tracking down those problems much less painful. And no matter what, be sure you have a good change process in place.