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.

In some ways, Windows 2000 Server and Windows Server 2003
administrators have it easy when it comes to deploying software. All they have
to do is create a software installation group policy, and away they go. Windows
NT administrators have it a little harder, but when it comes to deploying Service
Pack 2 for Windows XP, all you need is the proper logon script. 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 file
name for the service pack: WindowsXP-KB835935-SP2-ENU.exe. After you download
the file, you may want to rename the file 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 the Winxpsp2.exe file 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.

Next, create a group in User Managers For
Domains called WinXP Users. Add all of the user accounts representing users
running Windows XP to this group. After that’s done, create a file share
pointing to the directory where you extracted the Windows XP SP 2 files and
grant rights to the WinXP Users group.

Finally, you’ll need a copy of Ifmember.exe from the Windows
2000 Resource Kit
. If you already have a version of it from the Windows NT
Resource Kit, that’s fine; however, Microsoft no longer keeps a version of the
NT Resource Kit on its Web site. The Windows 2000 version will work fine. Copy Ifmember.exe to the C:\Winnt\System32\Repl\Import\Scripts
folder on your primary domain controller.

Ifmember.exe is used in logon scripts to check to see if a
user is a member of a group or not. You’ll use it in conjunction with the
membership of the WinXP Users group you just created to run the Update program
for Windows XP Service Pack 2. This will keep you from having to worry about
the effects of creating a logon script to install a Windows XP utility where
you have multiple workstation operating systems.

Installing Windows XP service packs

You can install Windows XP service packs through logon
scripts as easily as you can execute other workstation configuration settings.
If you don’t use logon scripts on your server, you’ll have a little bit of
extra work because you’ll have to create the initial logon scripts and then add
them to every user in User Manager For Domains, or at least those to which you
want to deploy SP 2.

Once the files are in place, you can modify the logon script
you’ll use to deploy the service pack. From your Windows NT Server, open the C:\Winnt\System32\Repl\Import\Scripts
folder. Here, either edit your current logon script or create a new one. In the
file, include these lines:

\\servername\netlogon\ifmember.exe "WinXP Users"
if errorlevel 1 \\spservername\sharename\update\update 
/passive /forcerestart /d:c:\sp2backup

Here you’ll replace servername
with the name of the primary domain controller where you store your logon
scripts; spservername with the name
of the server where you’re storing the extracted Service Pack 2 files; and sharename with the name of the share you
created for Service Pack 2.

As you can see, I’ve included a few extra switches for the
Update command. The /passive switch displays a progress bar that users can
watch to ensure that Service Pack 2 installs properly. The /forcerestart switch
will cause the Windows XP workstation to reboot automatically when Service Pack
2 finishes installing. The /d: switch sets the location for the backup files
that Service Pack 2 will use to store old Windows XP files in case you need to
back out of the Service Pack.

Applying the package

With the logon script in place, the next time your Windows
XP workstations reboot and a user whom you’ve made a member of the WinXP Users
group logs in, Service Pack 2 will install. The service pack will install in
unattended mode but, unlike applying Service Pack 2 from a group policy in
Windows 2000, it will install after the user logs on. Because the service pack
is so large, you probably will want to warn your users in advance that it will
take a while for the package to install when they log on to their machines.

Caveat service pack

Here’s one final bit of advice on planning and deploying
application updates and service packs through logon scripts: 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, consider staggering the upgrade
by deploying it through multiple groups at varying times. Modify the ifmember
line of the logon script for each group, and allow the logon script to apply the
upgrade to those users. Then, when the majority of users in that group have had
their systems upgraded, modify the logon script to apply the script to the next
group of users to repeat the process for its users. Continue to modify the
logon scripts to the remaining groups one at a time
until the deployment is complete. An alternative to this method, if you have
sufficient servers and network segmentation to make it feasible, is to create
multiple groups and logon scripts 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 those
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.