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.
Previous
Register
