In-Depth

Group Policy XPerience

You can do more with Group Policy in Windows XP than in Windows 2000 Professional. Here’s a guide to the changes.

• By Jeremy Moskowitz
• 11/01/2002

Or, will your perfect Win2K Group Policy utopia all fall apart when you introduce your first Windows XP Professional client machine?

If you’re happily deploying Group Policy to Win2K clients, then you’ll be well poised to also deploy it to your XP clients. However, you should be aware of differences, additions and pitfalls with XP in order to maintain a working Group Policy implementation.

New! Improved!
XP has some additional features that can be set through Group Policy. However, it takes hoop-jumping to enable these features, so stay with me here. It’s likely today that you administer the Group Policy settings of your machines in one of two ways: either you run Active Directory Users and Computers directly on a server (or via Terminal Services) or your run it on your local Win2K Pro box using the MMC snap-in tools contained within Adminpak.msi, which ships with Win2K.

When you upgrade your desktop to XP, you’ll find the tools inside the Adminpak.msi won’t work. This is because the tools inside the Adminpak.msi that comes with Win2K Pro are incompatible with XP. This means you need to get the right version of the Adminpak.msi containing the new administrative snap-in tools compatible with XP. These tools expose some new features, particularly in regard to Group Policy. Download the right version, which is called the “Windows .NET Server RCi Adminpak.exe,” from http://support.microsoft.com/default. aspx?scid=kb;EN-US;q304718. Note that the Adminpak currently ships as an EXE but upon release will be delivered back as the familiar MSI file type.

Just What You Need—200 More Group Policy Settings
Since XP has more features than Win2K Pro, it stands to reason there’s more “stuff” that can be controlled using Group Policy. For instance, two new XP Group Policies allow you to disable the use of the Internet Connection Firewall and the Network Bridge features. In all, there are about 200 new Group Policy settings, one of which is seen in Figure 1. Some affect just XP, others affect both XP and Win2K systems. Note that when you manipulate AD Group Policies from your XP machine (with the tools contained within the new Adminpak), you get an additional benefit of seeing which policies support which clients. If you don’t manage your domain’s Group Policy on an XP client with the new Adminpak, you won’t know if the policy affects or doesn’t affect specific clients.

Figure 1. The latest version of Group Policy tells you what policies can be applied to various OSs.

The good news is that if you apply a policy meant for XP on a Win2K Pro machine, the policy is simply ignored. The bad news is that in order to properly manage all your systems (Win2K and XP), you need to be religious about manipulating your GPOs only from an XP system (that has the proper Adminpak loaded).

Recall that Win2K Group Policies are initially applied at startup (for Computer policies) and at logon (for User policies). Both Computer and User policies are then independently refreshed periodically at intervals in the background. The background refresh happens about every 90 minutes with a 30-minute randomization factor thrown in there so every client doesn’t “ask” the server at once for updates.

This is important depending on the type of policy delivered. For instance, if you use Group Policy to change the desktop wallpaper for a gaggle of users in an OU, each user’s desktop wallpaper will respond when, individually, the background refresh next hits its cycle. Conversely, when you use Group Policy to distribute software, it doesn’t show up (or get removed) when the background refresh hits. Rather, Software Distribution (and Folder Redirection) policies are only applied at Startup or Logon. This is a good thing, as you wouldn’t want your users to suddenly not have DogFoodMaker 7.0 while right in the middle of using it.

Out of Synch
Win2K, by default, applies policies synchronously. This means that upon startup, a Win2K computer waits for the network interface to initialize, locates a domain controller, downloads the applicable Computer GPOs (site, domain, and each nested OU) and applies them—all before presenting the Ctrl-Alt-Del prompt to the user. When the user logs on, the User GPOs are downloaded and applied before the desktop and Start menu appear.

XP, however, processes GPOs asynchronously. This means that upon startup, the computer doesn’t wait for the network interface to initialize before starting to process Computer GPOs. Rather, XP processes previously cached Computer GPOs while it presents the Ctrl-Alt-Del prompt to the user. At the same time, it downloads any new GPOs. These new GPOs don’t get applied until a bit later. Similarly, when a user logs on, the desktop and Start menu appear while the system processes any cached User GPOs. New GPOs are downloaded but processing is deferred.

Once the computer has started, the user has logged on and any cached Computer and User GPOs have been applied, newly downloaded policies are then processed in the background. This ensures that the latest Security Settings and Administrative Templates (Registry updates) are applied soon after logon.

This results in a faster boot time (when processing Computer policies) as well as faster logon time (when processing User Policies.) Microsoft calls this XP behavior “fast boot.” For some environments, it does speed things up a bit—at a cost.

The Dark Side of Faster Booting
The downside to this new approach is that, potentially, a user at an XP desktop could be logged on but not quite have all the GPOs processed. Then, after that person has been working for a while—pop! A setting takes effect out of the blue. This is because not all GPOs were processed before the user was presented with the desktop and Start menu. Your network would have to be slow for this scenario to occur, but it’s certainly possible.

The next major downside to this updated approach is that some features, potentially, can take an XP client several additional logons or reboots to have the changes applied. This strange behavior becomes understandable when we take a step back and think about how certain policies are processed on Win2K. Specifically, we need to direct our attention to Software Distribution and Folder Redirection policies.

I’ve already stated that on Win2K, these two types of policies must be processed in the foreground to prevent data corruption and unhappy users. But if XP doesn’t do synchronous processing, how are these polices handled? XP fakes it and tags the machine when a Software Package is targeted for an XP client. The next time the user logs on, the Group Policy engine sees that the machine is tagged for Software Distribution and then switches, for this one time, back into synchronous mode. The net result: XP typically requires two logons (or reboots) to get a software distribution package when Win2K Pro only requires one.

This problem is worse for Folder Redirection. Basic Folder Redirection with XP is like Software Distribution, in that it now generally takes two logons to take effect. However, the use of Advanced Folder Redirection (which checks which security groups the user is in) takes a whopping three logons to take effect. The first one tags the system for a Folder Redirection change; the second one figures out the user’s security group membership, and the third actually performs the new Folder Redirection.

Predictability=Good; Unpredictability=Bad
If you want your XP users to log on a bit faster, then, by all means, leave fast boot on. If you’re doing some “no-no’s” in Group Policy like cross-domain links of Group Policy or lots of site-based GPOs, then leaving this on will likely make each and every logon a bit faster.

If, however, you want your XP machines to act just like Win2K Pro machines, you need to set a Group Policy that reverts them back to the old behavior. Sure, it’s a bit slower to log on. It’s also a heck of a lot more predictable. Besides, your Win2K machines already act this way, and it probably would be good practice to have all machines in your environment react as similarly as possible—even if they’re different OSs.

To revert XP back to the Win2K “synchronous” behavior, set a Group Policy (preferably at the domain level) to enable the “Always wait for the network at computer startup and logon” policy which can be found in the Computer Configuration | Administrative Templates | System | Logon branch of Group Policy.