Windows XP Service Pack 2 (SP2) is a big deal. It provides immediate benefits, but it also comes with some potential pitfalls. Before you do a mass rollout of XP SP2, arm yourself with my favorite tips and tricks for deploying SP2 and dealing with some difficulties you'll likely run into after you deploy it.
Use Group Policy to Deploy SP2
Rolling out XP SP2 in the enterprise is no small task. Whether you have 5, 50, or 500 machines, you could spend a lot of time just running the setup program. To speed the job, use the power of Group Policy to deploy SP2 to your users.
It might seem like the easiest thing to do would be to create a Group Policy Object (GPO) that's linked to various organizational units (OUs) in Active Directory (AD), as Figure 1 shows. However, this approach is chancy because, if something goes awry with the upgrade, all XP computers in a department could risk failure. Randy Smith describes some steps to mitigate this risk in "Windows XP SP2: Centralized Deployment and Defense," August 2004, InstantDoc ID 43199. Specifically, he explains how to
- extract the service pack to a share or Dfs mount
- create a new GPO to deploy SP2, link the GPO to the domain level, and have the GPO apply SP2 to a security group that contains all your XP machines
However, if you move all your XP machines into one security group and apply the GPO to that group, you'll still be upgrading all XP machines in every department at one time. To avoid exposing all of a department's XP systems at once, I suggest you instead create multiple AD security groups. Into each group, put selected XP computers from several departments. Then, link the GPO to the domain and use security group filtering to apply the GPO.
Figure 2 illustrates this approach in a network that uses a typical domain and OU structure. As you can see, I create three security groups, each containing XP computers from various departments. For example, XPGROUP1 contains one computer from the Sales OU, one from the Facilities OU, and one from the Accounting OU. Figure 3 shows how I put this approach into practice. First, I create the GPO to deploy SP2 and link the GPO to the domain. In the Security Filtering section, I remove the Authenticated Users group and add XPGROUP1. Because the new group contains a cross-section of Windows XP machines, no department is upgraded wholesale. Then, I simply repeat the steps by creating additional security groups, populating them with the computers I want to update, and adding those new groups in the Security Filtering section.
Delaying SP2 Deployment
If your clients use Microsoft Software Update Services (SUS) or Automatic Updates to contact Microsoft and automatically download patches, they'll find SP2 flagged as a critical update. Indeed, SP2 has been listed as a critical update since mid-August 2004. However, to prevent SP2 from installing on clients before administrators have thoroughly tested it, some administrators have resorted to disabling SUS or blocking access to the Windows Update site. This approach has a serious downside, however, in that it also prevents clients from obtaining other critical updates.
Instead of blocking all access to the Windows Update site, administrators who want to wait to install SP2 should read the documentation and follow the procedures spelled out in the TechNet article "Temporarily Disabling Delivery of Windows XP Service Pack 2 Through Windows Update and Automatic Updates," http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2aumng.mspx. The associated download provides an .adm template for Group Policy that blocks pre-XP SP2 machines from automatically installing the service pack. Thus, your XP clients can receive the other critical updates they need while preventing only the deployment of XP SP2. You can read more about this strategy in the FAQ "FAQ—Temporarily Blocking Windows XP SP2 Delivery Through Windows Update and Automatic Updates," http://www.microsoft.com/technet/prodtechnol/winxpro/maintain/sp2aumngfaq.mspx. After April 12, 2005, the registry changes that the .adm template makes are ignored and SP2 is installed whether you're ready or not.
Living with SP2
After deploying XP SP2 to your clients, you can enjoy the fruits of your labor. SP2 adds more than 600 new policy settings, which you can tweak to your heart's content. The new settings are visible when you create a GPO (or edit an existing one) from an XP SP2 machine. For a listing of all the .adm template and Microsoft Internet Explorer (IE) policy settings, including the policy path and default setting for each, download the "Group Policy Settings Reference for .adm Files Included with Windows XP Professional Service Pack 2" Excel spreadsheet at http://go.microsoft.com/fwlink/?linkid=15165. To see only the new XP SP2 settings, click the spreadsheet's Update History worksheet.
One difficulty that's sure to come up as soon as you deploy SP2 is that Windows Firewall is automatically enabled. For many companies, Windows Firewall is both a blessing and a curse. It's a blessing because, in its default configuration, the firewall allows no outside communication to the client. Of course, it's a curse for the same reason. If you try to use Group Policy Management Console's (GPMC's) Group Policy Results Wizard to determine the effect of policies on a specific SP2 machine on which the firewall is enabled, you get the error message that Figure 4 shows.
To correct this problem, you could disable the firewall, but that isn't a good idea. Instead, leave it enabled and open only the port necessary to allow remote procedure call (RPC) communication (port 135). I suggest creating a GPO that opens port 135 and linking the GPO to the domain level. The Windows Firewall: Allow remote administration exception policy does this; you'll find it under Computer Configuration\Administrative Templates\Network\Network\Connections\Windows Firewall\Domain Profile. Simply enable this policy setting—you can optionally specify from which addresses the target machine should allow requests—and the Group Policy Results Wizard will continue to work as it did before you loaded SP2. Be aware that this policy also opens port 445, which allows Server Message Block (SMB) traffic so that administrators can manipulate files on remote machines.
Ongoing GPO Management
When you create GPOs in AD, you can do so from anywhere. For example, you can log on locally to a domain controller (DC) and create a GPO. You can then walk back to your desktop and modify that GPO through GPMC or the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in. Hopping between machines like this usually isn't a problem—unless you use an XP SP2 system to create the GPO, then use a non-SP2 machine to modify it.
In that case, when you create the GPO, you're using the XP SP2 versions of the .adm templates. Those new templates give you all the new SP2 policy settings. But if you then try to modify the GPO on a non—XP SP2 computer, you'll get an error message similar to the one you see in Figure 5. The About Windows window in the figure shows that I'm trying to modify this GPO on an XP SP1 machine. To clear this error, you need to press OK about 50 (yes, 50) times.
The cause of this difficulty, which is known as the LISTBOX ADDITIVE problem, is a bug that manifests only if you use a non-XP SP2 machine to modify GPOs that use the SP2 .adm templates. When the underlying gpedit.dll program loads the new .adm files on non-SP2 computers, older versions of the OS, which use an older gpedit.dll file, can't process syntax that occurs only within XP SP2 .adm templates.
Microsoft summarizes the problem and provides a hotfix at http://support.microsoft.com/?kbid=842933. You need to deploy this patch only on machines that are used to create or edit GPOs. There are patches for Windows Server 2003, Windows 2000, and Windows XP (for installation on machines with or without XP SP1.)
After you patch those machines, however, you still have a small problem: How can you "upgrade" existing GPOs to contain the XP SP2 .adm templates? One way is to open each and every GPO from an XP SP2 machine. You don't need to change anything; you can simply open the GPO for editing, then immediately close it. Opening the GPO automatically overwrites its existing .adm templates with the .adm templates from the XP SP2 machine. No policy settings are lost or changed because those settings aren't stored in the .adm template, which is simply a definition of what settings and registry changes can be deployed. The actual policy settings reside in another file, registry.pol, which is updated only when you change the settings.
If you have many GPOs, of course, opening each one for editing from an XP SP2 machine could take quite a while. Before you undertake the job, you might want to check the TechNet Script Center Script Repository at http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx for a script that will do it for you. Writing this script has been on the Scripting Guys' to-do list for a while, although the script isn't available yet. Finally, before you upgrade any GPO—whether manually or through a script—you should use GPMC to make a full backup of all your GPOs, just to be on the safe side. (For step-by-step instructions on backing up GPOs, see "Don't Wait—Back Up Those GPOs Now!", September 2004, InstantDoc ID 43588.)
Final Thoughts
Before you deploy SP2 and start using its new features, I highly recommend that you do a bit of reading. The following references will smooth the deployment and help you get the most out of the new functionality:
- "Changes to Functionality in Microsoft Windows XP Service Pack 2," go.microsoft.com/fwlink/?linkid=29126
- "Managing Windows XP SP2 Features Using Group Policy," go.microsoft.com/fwlink/?linkId=31974
- the enterprise implementation guide, planning guide, and planning template, all of which you can download from Microsoft's Web site at http://tinyurl.com/42wjv
- "Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2," http://tinyurl.com/6wm5b
You'll find all these references on TechNet's XP SP2 Web site at http://tinyurl.com/26uwc.
