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.
ARE YOU REAPING the benefits of Group Policy yet? Are you finding that
you’re able to roll out a consistent environment for all your Windows
2000 users? Are your users happily getting the software you deployed and
happily saving their files to their “My Documents” folder (with you knowing
their data is secretly saved on the server)?
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.
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
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
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
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.
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