SolutionBase: Distribute Windows XP Service Pack 2 from a Windows NT 4.0 server using logon scripts

Group policies make it easier to centrally distribute Windows XP Service Pack 2 from Windows 2000 Server or Windows Server 2003, but Windows NT servers don't offer group policies. Instead, NT administrators can distribute Windows XP SP2 using logon scripts. Here's how.

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.

Editor's Picks

Free Newsletters, In your Inbox