Windows XP Service Pack 2 (SP2) is a complex update with many ramifications for IT pros. TechRepublic's Windows XP Service Pack 2 Quick Guide drills down on critical SP2 need-to-know areas, with sections on fundamentals, changes that occur after installation, deployment procedures, problem areas, and removal.
Service Pack 2 is one of the most complicated pieces of software that Microsoft has ever released, short of a major new version of a program. Its size—twice that of Service Pack 1—and complexity make deploying it in the enterprise a challenge. Fortunately, by using Windows 2000 Server's Group Policy feature, you can automatically upgrade Windows XP workstations on your network without ever leaving your office. Here's how it's done.
You’ll need the network installation version of Windows XP Service Pack 2. It doesn’t matter how you obtain the file, whether from Microsoft’s Web site or from a Windows XP service pack CD. If you download it from Microsoft, you'd better have a fast connection. Service Pack 2 weighs in at over 250 MB and will take quite a while to download. Microsoft also uses a long filename for the service pack: WindowsXP-KB835935-SP2-ENU.exe. After you download the file, you may want to rename it to something easier to type, such as winxpsp2.exe.
Create an installation directory on your server, from where you'll distribute the files, and copy winxpsp2.exe into it. Next, extract the Service Pack 2 files from the file by typing winxpsp2 /x at a command prompt in the temporary directory and pressing [Enter]. When you see the Choose Directory For Extracted Files dialog box, type c:\tempdir, where tempdir is the name of the installation directory you created, and click OK.
Installing Windows XP service packs
You can install Windows XP service packs through Group Policy as easily as you can other application patches and updates. Group Policy offers an excellent means of ensuring that your operating systems are up to date. As with applications, however, you should explore how the application of a service pack will affect each user and plan accordingly. It’s rare that a service pack causes problems instead of fixing them, but you should be aware of any potential problems and any post-SP fixes that address those problems so you can deploy them at the same time. Before applying the service pack via Group Policy to all of your workstations, you should try to deploy the service pack via Group Policy in a test environment.
The process for deploying a service pack is much the same as for an application upgrade, with two main exceptions: You’ll assign the package rather than publish it, and you’ll apply the Group Policy Object (GPO) through the Computer Configuration branch rather than the User Configuration branch.
Start by preparing the distribution share for the service pack. This is the temporary folder that you created and copied the SP2 files to. Configure permissions on the folder, and share it to make it accessible to workstations on your network.
Once the files are in place, you can define the GPO that will cause the service pack to be deployed. Open the Active Directory Users And Groups console. Open the properties for the container to which you want the policy applied. For example, to apply the policy at the domain level, right-click the domain and choose Properties. Then, click the Group Policy tab, select an existing GPO or create a new one, and click Edit to open the Group Policy Editor.
In the editor, open the Computer Configuration | Software Settings | Software Installation branch. Right-click in the right pane and choose New | Package. Rather than browsing to the share where the service pack files are installed, type the UNC path to the file server share where you copied the Service Pack files, such as \\server\share\installdir\i386\update\Update.msi, and click Open. When the Deploy Software dialog box appears, leave the Assigned option selected and click OK to create the package.
Applying the package
With the package in place, the next time your Windows XP workstations reboot, Service Pack 2 will install on them. The service pack will install in unattended mode before the user sees a login screen. Because the service pack is so large, you probably want to warn your users in advance that it will take a while for the package to install when they restart their machines.
Keep in mind that the Group Policy refresh interval will control how soon the service pack will be applied. While you can change this refresh value (the default is 90 minutes), in most cases, it’s more trouble than it’s worth. Simply allow the policy to refresh as scheduled. Also, note that if you define the policy at the domain level, the change will not always occur as you expect it to. It has been my experience that you must sometimes reboot the clients more than once before the domain-wide policy changes are applied. When applying the policy at the organizational unit (OU) level, the change typically happens the first time you reboot after the policy refreshes.
Here’s one final bit of advice on planning and deploying application updates and service packs through Group Policy: Consider the impact on your servers and availability issues when deploying the software. A typical upgrade can generate a significant amount of network traffic. This potential problem is magnified as the number of systems being upgraded increases. For example, you wouldn’t want several hundred users all deploying a service pack at the same time—your network would probably slow to a crawl.
To keep this from happening, stagger the upgrade by deploying it through multiple OUs at varying times. Link the applicable GPO to one OU and allow the policy to apply the upgrade to those users. Then, when the majority of users in that OU have had their systems upgraded, link the GPO to the next OU to repeat the process for its users. Continue linking the GPO to the remaining OUs one at a time until the deployment is complete. If you have sufficient servers and network segmentation to make it feasible, an alternative to this method is to create multiple distribution points and GPOs to distribute the upgrade load across multiple servers.
If for some reason the service pack doesn’t appear to be installing properly after the workstations reboot, check the Event Viewer on the workstation. Under the Application branch, look for errors coming from Userenv and Application Manager. By checking these errors, you can often discover problems with the installation. Common errors may include ones dealing with the installation files being damaged or the installation source being unavailable. If the service pack installation fails, you'll have to reapply the policy or manually install the service pack.