Group Policy's power is well known. But just as well known are the annoying things about it, when it doesn't always work the way you'd expect. Equally frustrating, the myriad of different capabilities that Group Policy brings—literally thousands of settings—make it tough to know when you can use this technology for a given problem. I've helped many people get the most from Group Policy, and frequently I've seen the same few annoyances cause more than their share of problems. Here's what you can do about them.

Policy Settings Don't Take Effect Immediately
Sometimes it takes two to three reboots for a particular policy setting to take effect. This behavior can be disconcerting because you're not sure whether or not the setting is working. It happens most often for Folder Redirection or Software Installation Group Policy Objects (GPOs), primarily on Windows XP.

This delay is caused by an XP feature called Fast Logon Optimization. In the interests of getting an XP system booted and the user logged on as fast as possible, Microsoft enabled what's referred to as asynchronous foreground Group Policy processing by default. Essentially what this means is that while the computer is starting up, computer-specific Group Policy processing occurs at the same time that the system is working on presenting the logon dialog box to the user. In fact, computer-specific Group Policy processing might still be running when the user enters a username and password and starts to log on. Similarly, when the user logs on, user-specific Group Policy processing starts running and might still be running when the desktop appears. Certain GPO settings—Folder Redirection and Software Installation, for example—need "exclusive" access to the computer or user environment to run. In other words, they need to run synchronously, rather than asynchronously. The Group Policy processing needs to finish doing its thing before the system presents the user with a logon dialog box or the desktop. So how do we tell XP to process GPOs synchronously? By using a policy setting, of course!

Open Group Policy Editor (GPE) and expand Computer Configuration\Administrative Templates\System\Logon to see a policy called Always wait for the network at computer startup and logon. Enable this policy for your XP computers, and they'll always run foreground Group Policy processing synchronously. You'll increase the time it takes for a user to boot up a machine and get logged on, but you'll also eliminate the multiple reboot or logon problem when trying to deliver certain kinds of policy. Windows Vista is set to asynchronous processing, just like XP; however, Windows 2000 is set by default to synchronous foreground processing.

Policy Settings Don't Take Effect at All
Sometimes a Group Policy setting doesn't apply at all, and I see 1058 and 1030 event log errors in the Application event log on the client that's having problems. The errors seem to indicate that the system can't read the gpt.ini file. This is a common problem, unfortunately. Because many problems could cause these errors, the best solution is to narrow down the possible causes.

If you notice that this problem occurs only for computer policy settings and not for user policy settings, the cause could be a network-stack timing problem—the computer is booting so quickly that the network stack hasn't had time to initialize fully before the system attempts Group Policy processing, so computer-policy processing fails. However, by the time the user is ready to log on, the stack is up and running, so user-policy processing works just fine.

Microsoft added a nifty little registry entry to certain versions of Windows, which you can use to tell the system to wait until the network stack is finished initializing before Windows starts policy processing. This registry entry is described in the Microsoft article "Group Policy application fails on a computer that is running Windows 2000, Windows XP Service Pack 1, or Windows XP Service Pack 2" (http://support.microsoft.com/?kbid=840669). You'll also find it as a GPO setting in Windows Vista, under Computer Configuration\Administrative Templates\System\Group Policy\Startup policy processing wait time.

Other problems might cause these error messages. For example, perhaps the gpt.ini file really is inaccessible. This file is stored in the part of a GPO stored in the SYSVOL share on each domain controller (DC) in your environment. When the system performs either computer- or user-specific Group Policy processing, it needs to read this file to get information about the GPO. If the file isn't present on the DC the system is reading from, Group Policy processing will fail. You can verify which DC is servicing Group Policy processing by looking in the HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Windows\CurrentVersion\Group Policy\History\DCName registry value.

After you identify the DC in question, verify that SYSVOL is actually shared out, that the DFS service is running on the DC (SYSVOL uses DFS replication), and that the TCP/IP NetBIOS Helper Service is running on the client (the client uses this service to communicate with DFS). From a command shell on the client, you can type

net view \\<DCname 

to verify that SYSVOL is shared, and use the netstart command to verify that all required services are running. Also browse to the file location that showed up as inaccessible in the event log entry and verify that the file is actually there and that the file's permissions are the same as on another DC where you know policy is working.

For permission problems, Group Policy Management Console (GPMC) might be able to help. Open GPMC focused on the DC that's having a problem. To do this, change GPMC's DC focus by right-clicking the domain name and selecting Change Domain Controller, as Figure 1 shows. After you've focused GPMC on the problem DC, go to the Group Policy Objects container and select the GPO that's having problems. If GPMC spots permission problems on that GPO, GPMC will prompt you and offer to fix them.

Loopback Policy Is Confusing to Implement
If you're working in the Terminal Server component of the Windows Server 2003 environment, you want to be able to deliver different policy settings to users when they log on to the terminal server versus when they log on to their desktops or laptops. This scenario is exactly why loopback policy was created, but the policy can be confusing to implement.

Loopback policy says, when I'm logged on to a particular computer that has loopback enabled, deliver user policies that are defined for the computer object, rather than the user object. The easiest way to implement loopback policy is to put your Terminal Server computer objects into their own organizational unit (OU) within Active Directory (AD). Then create a GPO and link it to that OU. Within that GPO, enable the policy under Computer Configuration\Administrative Templates\System\Group Policy\User Group Policy loopback processing mode. This policy enables loopback processing for the computers in that OU. You might typically want this for "kiosk" or public-use computers, where you want a machine to behave a particular way regardless of who logs on to the machine.

The policy has two modes: merge and replace. The mode you choose will depend upon what you're trying to accomplish. Merge mode says, first run my regular user policies when I log on to the Terminal Server box, then run the computer-based user policies. Should the regular user policies and the computer-based user policies conflict, the computer-based policies prevail because they're processed last. Replace mode says, don't even process my regular user policies—just process the computer-based user policies.

In my experience, replace mode is simpler to manage and should be used unless you need some of the user's regular policies to apply when the user logs on to the Terminal Server system. Note that if you use merge mode, some policies might run twice when the user logs on to the terminal server. For example, if you have logon scripts defined at the domain level, the scripts will apply to both the user object and the computer object, and because the computer object is running in loopback merge mode, the system will process those logon scripts once for the user object and again for the computer object.

Make sure you enable loopback processing so that it affects only those computers that really need it (hence my recommendation to enable loopback policy on a specific OU that contains only loopback computers). If you enable the policy more generally, you might get unexpected results whose cause can't be detected because you enabled the policy by setting a particular registry value that isn't exposed in any reporting.

Unfortunately, there's no clear answer, but you should take note that Microsoft is moving IE configuration toward Administrative Templates–style settings and de-emphasizing IE Maintenance features. Basically, the reason for this move is Microsoft's poor implementation of IE Maintenance when the policy was first created. The IE Maintenance policy area has had many bugs and is generally difficult to use.

Still, you absolutely have to use IE Maintenance policy to do such things as setting the browser proxy settings, or Favorites. But for IE security configuration, your best bet is to ignore IE Maintenance and use the Administrative Templates policies found under User Configuration\Administrative Templates Windows Components\Internet Explorer. For example, if you need to configure trusted sites for a particular zone, you can use the Site to Zone Assignment List policy under User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page. You can also set individual zone security settings (visible at the IE Internet Options, Advanced page) within User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page\Internet Zone, Intranet Zone, etc. A cautionary note: Avoid setting IE security policy in both the IE Maintenance and Administrative Templates sections, as their interactions can be unpredictable.

Also, IE Maintenance has this annoying feature: If you're defining a GPO such as Connections Settings to set up a proxy, IE Maintenance imports those settings from the machine on which you happen to be editing that GPO at the time. So if you set a policy for settings on one machine, then go to a machine whose IE connection settings are different, when you click the button to modify settings, you'll see the new machine's settings and not those from the first machine where you were editing that GPO. This can cause no end of problems. For that reason, if you have to use IE Maintenance policy, always try to make subsequent edits to that policy from the machine on which you made your original changes (provided you haven't changed IE's configuration since the last time you edited that policy).

Removing a Machine from a Domain Won't Erase GPO Settings
Sometimes you just want to wipe the slate clean and remove all GPO settings that have been applied to a particular user or computer. For example, let's say you're going to move a computer out of an AD domain into a workgroup and you no longer want Group Policy enforced on it. In that scenario, you must follow a specific set of steps before you remove the machine from the domain. You can't just remove the machine from the domain, because any GPO settings set on that machine will be "orphaned" on the machine and you won't be able to easily remove them, as those settings came from domain-based GPOs that no longer exist in the workgroup.

Therefore, before you remove the machine from the domain, move the machine's account in AD to an OU that has no GPOs linked to it (and make sure to block any upstream GPOs by using the Block Inheritance flag on that OU). Then reboot the computer. For most policy settings, what will happen is that during the Group Policy processing cycle that happens at reboot, the machine will notice that none of the GPOs that it had previously applied are applicable anymore, and so those settings that can be removed (e.g., Administrative Template policy, Software Installation policy) will be removed during this processing cycle.

After the machine is "clean," you can safely remove it from the domain. The only caveat to this method is that some policies, such as security settings configured under Computer Configuration\Windows Settings\Security Settings, won't be removed because Group Policy doesn't know what their default state was. In that case, you can use the secedit.exe command-line utility to apply the baseline security template that was in place when you first installed Windows. This baseline is called setup security.inf and can be found in C:\windows\security\templates in XP Professional and Windows Server 2003. You can easily use this template to reset security by opening the local GPO Editor (type gpedit.msc from the Start menu Run dialog box) and navigating to Computer Configuration\Windows Settings Security Settings. Right-clicking that node, choose Import Policy from the menu and then select the setup security.inf file to import.

You'll Never Walk Alone
I hope this list touched on many of the problems you've had with Group Policy and provided some fresh answers to help solve them. There's no doubt that this stuff is complex—with lots of moving parts and interdependencies to complicate a powerful configuration-management system. Just know that you're not alone when it comes to struggling with some of these problems.