The Cheap and Easy Way to Remotely Deploy Win2K SP2

Service pack deployment has been the bane of many systems administrators since the early days of Windows NT 3.5. Deploying service packs in Windows 2000 is no exception, especially for those administrators in enterprises with numerous machines. Administrators often solve the dilemma of having to install multiple service packs or other software packages by spending lots of time and money evaluating and purchasing third-party products. However, some administrators might not have the time to evaluate and compare the effectiveness of third-party products or have the financial resources to purchase a suite of utilities.

Although Win2K's Active Directory (AD) provides the Group Policy feature, which administrators can use to deploy service packs and other software packages, some enterprises, such as my company, choose not to implement AD. So, when I had to deploy Service Pack 2 (SP2) on many Win2K machines, I checked whether Microsoft had any service pack deployment tools. According to our technical account manager, no such tools were available, and the third-party products that I evaluated were either too costly or too complex for my simple needs. Frustrated, I gave up my search and endeavored to create a script that reliably and consistently deploys SP2 on remote Win2K machines.

The result is ServicePack2Deploy.bat. This script initiates a silent, remote install of SP2 from an administrator's workstation. The script works on Win2K Server, Win2K Advanced Server, and Win2K Professional machines running SP1. To use ServicePack2Deploy.bat in your environment, you need to prepare for its deployment, understand how the script works, customize the script, and know how to launch it.

Preparing for Deployment
Installing software remotely from the command line might be new territory for some administrators. You'll need access to a command line on the remote machine. You can use Telnet, Secure Shell (SSH), the Microsoft Windows 2000 Server Resource Kit's Remote Command Service, or some other method to access the command line. I needed a simple utility that I could execute from my workstation and that wouldn't require a lot of front-end work (e.g., installing agents or software on the remote machines). Sysinternals' PsExec filled my needs nicely. You can obtain this freeware from the Sysinternals Web site (http://www.sysinternals.com/ntw2k/freeware/psexec.shtml). To use ServicePack2Deploy.bat, you need PsExec 1.21 or later.

Besides PsExec, ServicePack2Deploy.bat uses three other utilities: SP2's update.exe and the resource kit's netsvc.exe and sc.exe. The script uses update.exe to install SP2. You can download the SP2 files, which include update.exe, from the Microsoft Windows 2000 Downloads Web site (http://www.microsoft.com/windows2000/downloads/default.asp).

To install a service pack on a Win2K machine, you must be running the Print Spooler service on the target remote machine. According to the Microsoft article "Update.exe Cannot Start If the Spooler Service Is Disabled"(http://support.microsoft.com/support/kb/articles/q270/1/49.asp), this behavior is by design. The netsvc .exe and sc.exe utilities help ensure that the Print Spooler service is running, as I explain later.

I recommend that you keep all the SP2 files and utilities on a network share that's visible from the remote machines on which you want to install SP2 and from the workstation on which you plan to run ServicePack2 Deploy.bat. When you keep the SP2 files and utilities in a central location, every administrator has access to the same set of files and utilities, which helps ensure the script's repeatable and reproducible outcome. Although you can store and run the utilities locally, you could encounter problems if different machines have different versions of the utilities. I keep the SP2 files and utilities on a file server. PsExec, netsvc.exe, and sc.exe are in a directory called utils.

After obtaining SP2 and the utilities and placing them on a network share, you need to create the necessary user credentials to access those files. My company has an isolated production domain that contains a mix of Win2K and NT 4.0 machines. This setup is popular because it lets administrators use an administrative domain user account to easily manage their servers. However, when I initially tried to run ServicePack2Deploy.bat on a remote server in that environment, I ran into a snag. By design, the remote server was unable to use my credentials to retrieve the SP2 files and utilities on the file server. You'll likely run into similar problems in your environment. To work around this problem, you need to create a local user account on the file server and give the user account Read & Execute permission to access the file server from the network. Don't create a domain user account, because you need to hard-code the username and password in the script. Using a local account that has Read & Execute permission to only one file server minimizes security risks. (If you're the cautious type, you might want to modify the script to call an encrypted text file that contains the user account information.)

Understanding How the Script Works
ServicePack2Deploy.bat might not be the most elegant solution, but it works well. Here's how the script works:

Customizing the Script
I've tested ServicePack2Deploy.bat on Win2K Server, Win2K AS, and Win2K Pro machines running SP1. You can find ServicePack2Deploy.bat in the Code Library on the Windows Scripting Solutions Web site (http://www.winscriptingsolutions.com). To use this script, you must have some form of basic network connectivity to the servers for which you're responsible. If your environment contains a firewall between the file server and the remote server, the script might fail to execute correctly. To verify your ability to establish a Universal Naming Convention (UNC) connection from the target server to the file server, you can map a drive from the target server to the file server with the local user account you created earlier. Most standard networking errors appear in the log, which helps with troubleshooting. A good source for looking up error messages is the Win2K Search Support Web site (http://www.microsoft.com/windows2000/support/search/default.asp).

Before you can run ServicePack2 Deploy.bat, you need to modify several lines of code. In the :START section, you need to modify the code that Listing 4, page 4, shows. Follow these steps:

If you placed PsExec on your local machine, you need to comment out the code that sets the PsExecPath variable. In addition, you need to customize some code in the :NEXT section. Listing 5 shows this code and provides instructions on how to customize it.

Launching the Script
Before you run any script that adds new software to your production servers, you need to thoroughly test the software and the script. After you test ServicePack2Deploy.bat and SP2 in your environment, you're ready to run the script. Open a command shell window, drag the script onto the window, and press the space bar. After the name of the script, insert the name of the target remote machine on which you want to install SP2. For example, as Figure 3 shows, I've entered server3. Finally, press Enter. If you inadvertently press Enter before inserting a machine name, you'll receive the script's syntax. Typing a question mark (?), the /? switch, or the word help after the script's name also provides the script's syntax.

The SP2 install process typically takes about 15 minutes, but that time might vary depending on the speed of your hardware. I designed the script to run in silent mode, so don't close the command shell window if you don't see any immediate feedback. After the script finishes and the remote machine reboots, the command shell window closes automatically. Update.exe has an option that lets you uninstall the service pack should you encounter problems with the SP2 installation.

Save Time and Money
With ServicePack2Deploy.bat, you don't need to spend lots of time and money to install SP2 in a large enterprise that has many Win2K machines. Because the script uses utilities that are free or in the resource kit, you don't need to buy costly programs. Because the script is easy to customize and use, you don't need to spend lots of time deploying SP2 in your environment.