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.

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

Group Policy XP
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.

comments powered by Disqus

Reader Comments:

Sat, Apr 23, 2005 Ajay India

It was an excelent article......

Wed, May 12, 2004 Anonymous Anonymous

Nice but all copied from MS site

Thu, Jan 29, 2004 Bin zurich domain

Good tips..............

Fri, Aug 8, 2003 IDJ UK

Found some users took a long time to logon as they had very large "My Documents" folders. Set a domain wide GPO to prevent caching of Offline files.

Fri, Jul 4, 2003 Anonymous Anonymous

great overview!

Fri, Jun 20, 2003 Jack Detroit, MI, USA

Message to the Novell guy: The rating is supposed to be for the article, not the software it describes. Get a clue.

Great article.

Fri, May 23, 2003 Anonymous Anonymous

Very useful. Thank you

Tue, May 20, 2003 keenan Buck beds

Very good, clear and concise

Mon, May 19, 2003 Gody The Netherlands

Anonymous: Novell is going down... and we won't miss it ;-)

Thanks for writing this article it's pretty good ccept for the fact the ms link is typed wrong... a space in the middle has to be removed to make it work. And the adminpack the writer is referring to is no longer available. Going to search for one on the ms site now... C ya all

Fri, Apr 18, 2003 Paddy London

Useful pointers for further investigation - well written - pantheon summary!
Could show the guys & girls at MSDN a thing or two with regard to concise, digestible writing style.

Mon, Mar 31, 2003 Anonymous Anonymous

Great Review ! To the Point !

Thu, Feb 13, 2003 Anonymous Anonymous

Good article. BUT....With the advance of technology and the need for security we can expect things to get more difficult. I find it very confusing for a company to release a product that is said to revolutionize an industry only to release a different version a short time later that renders the previous version basically useless. The headaches that go with new tecnology are to be expected, but why do we as Admins have to jump through SO many hoops to something that should be MUCH user friendly? I, for one am an advocate of the Windows enviroment, I only wish it was a bit more seamless.

Sun, Feb 9, 2003 mike Anonymous

novell preachers need to get a life . Of the 1700 clients that I service on 10 run novell. its not all its proported to be

Fri, Feb 7, 2003 Anonymous Anonymous


Wed, Feb 5, 2003 Ron New Zealand

good tips, could have used some further links

Wed, Feb 5, 2003 Anonymous Anonymous

Lots of usefull info

Wed, Feb 5, 2003 Anonymous Anonymous


Tue, Feb 4, 2003 Anonymous Anonymous

A good beginning

Tue, Feb 4, 2003 Anonymous Anonymous

Good article

Tue, Jan 14, 2003 Anonymous Anonymous

Well written and to the point. Very useful.

Tue, Jan 14, 2003 Anonymous Anonymous

Nicely done

Fri, Jan 3, 2003 OpenGuy Anonymous

Microsoft stuff is always so complex... I worked with ZENWorks (with eDirectory) and now with ADS and I can only tell you one thing: Microsoft ADS is years behind... Microsoft networking is always complex. Something that can be done in one step with Novell need a minimum of three times more with them. You should open your eyes...just take a look at the other choice. The article was really good!

Thu, Dec 5, 2002 Anonymous Anonymous

Article is decent explanation but what the novell guy said is true. It really doesnt have to be this complex

Fri, Nov 8, 2002 Anonymous Anonymous

very useful tips. thanks.

Thu, Oct 24, 2002 Anonymous Anonymous

Right reality doesnt count just Microhype..have you rebooted today...Brainwashed

Thu, Oct 24, 2002 dman NYC

Great article. Good points and concise. Thank you

Tue, Oct 22, 2002 Anonymous Anonymous

there is always one novell troll going around. lamo.

Nice article.

Tue, Oct 22, 2002 Anonymous Anonymous

there is always one novell troll going around. lamo.

Nice article.

Tue, Oct 22, 2002 DE_CORAZON Anonymous

Very good tips. As the technology gets more advanced it is always good to learn more tips.

Tue, Oct 22, 2002 Anonymous Anonymous

How many buzzers and whistles will Microcrap create to run a Network. Get a real network system..Novell NDS was able to do this with Zenworks years ago. One interface not to Explorer for Permissions..not this AD trusted maybe..are you root of the tree..if not Reinstall..what planet are you on..are you Global Catalog..DC..AC..partition partition whose got Primary partition..Reboot to restore..sorry wrong contanier return to go...just Novell console or nwadmin.dsrepair. Microsoft sux this is what happens when Programmers write Networking tools that have no idea how to run a network. Thank God that Novell dropped domains and their headaches years ago. Better hire a dozen Administrators for one Admin.

Tue, Oct 22, 2002 Inetraptor NYC

Good tips... specially dealing with folder redirection.

Thu, Oct 17, 2002 Anonymous Anonymous

Well written, concise.

Wed, Oct 16, 2002 Dustin Snyder Cleveland, OH

Some very good pointers. Glad to see it pointed out how to manage "XP Policies" in AD.

Wed, Oct 16, 2002 Bacchus MI

Great coverage of issues we are confronting

Wed, Oct 16, 2002 Anonymous Anonymous

nice overview

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.