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.