Group Policy Annoyances

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.

End of Article

   Previous  1  [2]  Next