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.

Getting started

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.