Slipstreaming Service Packs and Hotfixes

If you can manage the tedious process, the rewards are worthwhile

An important component of any Windows installation is hardening—that is, configuring the system after the installation process to make it more secure. The keys to hardening Windows 2000 are to install service packs and hotfixes, modify registry settings, and change insecure default configurations. However, not every organization puts its Win2K systems through this hardening process. As a result, thousands of computers across the Internet are vulnerable to intrusion and Internet-based worm viruses.

You need a way to install Win2K in an already-secured state so that you can safely connect it to a hostile network such as the Internet. Installing service packs and hotfixes is the first step toward that state. Unfortunately, Microsoft hasn't provided adequate tools for streamlining the process, and the company isn't likely to support the hacks I describe in this article. But through the use of third-party shareware and a bit of experimentation, you can install Win2K in an already-secured state.

A word of caution: This article isn't for the faint of heart. The hotfix-slipstreaming process is cumbersome and tedious, and Microsoft might suddenly decide to tweak something that would render these instructions useless. But if you're faced with the task of installing and hardening many Win2K servers, the process is definitely worth the effort.

Distribution Files
You can customize a Win2K installation in many ways, but one method that Microsoft doesn't support is to build a custom bootable installation CD-ROM—a useful method that you can use as the basis for other methods. The first step is to build a master Win2K distribution directory. This distribution directory will be the source for your bootable CD-ROM and should be well secured to maintain its integrity.

Copy the entire contents of your Win2K CD-ROM to a directory on your hard disk. You won't need all the files on the CD-ROM, so to make room for other utilities and updates, you might want to remove the files and directories that you won't use. You can safely remove the following directories and files: bootdisk, setuptxt, support, valueadd, read1st.txt, and readme.doc. If you'll use this distribution only for clean installations and not for upgrades, you can also safely remove the following files and directories: i386win9xmig, i386win9xupg, i386winntupg, autorun.inf, and setup.exe. You might also want to add files that you commonly install. On my CD-ROM, I've created a software directory for commonly installed software and an updates directory for—you guessed it—product updates.

Slipstreaming Service Packs
Slipstreaming is the process of integrating a service pack into a Windows distribution. One advantage of slipstreaming is that the service pack becomes the base file set for the distribution. If you ever add or remove components, the system will always use these updated files, rather than the original source files. Another advantage of slipstreaming service packs is that the system creates the Protected Store with a higher level of encryption. Microsoft Security Bulletin MS00-032 (Patch and Tool Available for "Protected Store Key Length" Vulnerability) talks about a flaw in the encryption level of the Protected Store. You might not realize that in addition to installing the hotfix (or latest service pack), you must also run keymigrt.exe for every account on the system. If you slipstream the service pack, you don't need to take this step because the maximum level of encryption is in place from the start. The disadvantage of slipstreaming service packs is that you can't uninstall the service pack. So, you need to make sure the service pack works properly with your configuration before you slipstream it.

Obtain the latest service pack (e.g., Service Pack 3—SP3) from Microsoft, and slipstream it into your master distribution by running it with the —s parameter, as follows:

w2ksp3.exe —s:

The service pack will let you monitor the updating process and notify you when it's complete. Provided you have enough disk space, you might want to make a backup copy of your distribution. The process gets a bit tricky at this point, and a minor misstep can break your installation.

Slipstreaming Hotfixes
Although Microsoft doesn't support the practice, you can slipstream hotfixes. Typically, when you add or reinstall a Windows component (e.g., Microsoft IIS), you need to reinstall all hotfixes to ensure that you have the most recent files. The reason for this requirement is that when you add a component, the setup process examines installation text files (.inf files) to determine where to obtain the files necessary for the component you're installing. When you install a service pack, it updates the .inf files to point to the updated files that the service pack includes. However, when you install a hotfix, it doesn't update these .inf files; therefore, to slipstream a hotfix, you need to make those modifications manually.

To get started, create a temporary directory and download all Win2K hotfixes released since the most recent service pack to the temporary directory. Next, rename all the hotfixes so that they use the 8.3 naming convention that the setup process requires. To do so, open a command prompt, change to the temporary directory you created, and type

ren *.* ???????.*

This command changes, for example, q318593_w2k_sp3_x86_en.exe to q318593.exe.

Next, you need to extract the contents of each hotfix. To do so, from the same command prompt, type

for %i in (q*.exe) do start /wait %i /x

When you press Enter, you'll see something like the following:

C:> start /wait q318593.exe /x

A pop-up box also appears, prompting you for a location for the extracted files. Enter a directory name based on the hotfix number (e.g., q318593). Click OK and repeat the process for each hotfix.

Now you need to start copying hotfix files to your distribution directory. But first, from the command prompt, change to the i386 directory of your master distribution and type

expand —r *.in_

to expand all compressed .inf files for later modification. Now, starting with the earliest hotfix, copy each file—one at a time—to the i386 directory of your master distribution. Copy all files except hotfix.exe, hotfix.inf, spmsg.dll, spuninst.exe, and svcpack1.dll. You can also ignore the symbols and update directories (with one exception noted below).

After you move a file, delete the corresponding compressed version that resides in the i386 directory. For example, if you move the kernel32.exe file, you need to delete the kernel32.ex_ file. This deletion forces setup to use the uncompressed version of the file. If no compressed version exists in the i386 directory, you must determine the location of the original file—which is where the expanded .inf files come into play. Using Windows Explorer or the Find command from a command prompt, search all .inf files for the filename you just copied. Suppose you copied the admin.dll file to the i386 directory and were unable to find a corresponding admin.dl_ file in the i386 directory. You must now search all .inf files for the admin.dll string. You'll probably find several matches, but you're looking for a file that contains a line such as

admin.dll=1,,20540

This line, which is defined in the fp40ext.inf file's [SourceDisksFiles] section, tells setup where to locate the listed file. The first number (in this case, 1) is a Disk ID, which is defined in the same .inf file's [SourceDisksNames] section. This Disk ID typically points to the Win2K CD-ROM, a service pack installation source, or a compressed cabinet format (.cab) file. If you open the fp40ext.inf file, you'll see the lines that Figure 1 shows.

If you look at the admin.dll line that I mentioned, you'll see that the Disk ID points to the fp40ext.cab file in the directory that contains the cdromsp2.tst file. However, because you just copied admin.dll to the i386 directory, you need to change the source location.

First, create a new location under the [SourceDisksNames] section (note that it might also be named SourceDisksNames.x86). Add the following line to that section:

0=%SERVICEPACK_NAME%,"",0,%34000%

Note that this .inf file contains only one Disk ID, and it points to the fp40ext.cab file. In other files, you might find that a line similar to the above example has already been added. If the line already exists, go ahead and use that one.

Next, locate the admin.dll line and change

admin.dll=1,,20540

to read as follows:

admin.dll=0,,20540

Now, when the setup process searches for admin.dll, it will look in the master distribution (i.e., Disk ID 0) rather than the original .cab file (i.e., Disk ID 1). You must repeat this step for each file that doesn't have a corresponding compressed file in the i386 directory. As tedious as this process already seems, it gets worse.

Some files related to IIS, SMTP, and Network News Transfer Protocol (NNTP) services have different names in the .cab files. Typically, the filename is a variant of the original filename. For example, the mailmsg.dll file is named smtp_mailmsg.dll in the ims.cab file and nntp_mailmsg.dll in the ins.cab file. If you search all .inf files, you won't find any references to mailmsg.dll, but you'll find references to smtp_mailmsg.dll and nntp_mailmsg.dll. Although no fixed rules exist for how the system renames files, I have yet to see a filename that's not an obvious variant of the original.

To deal with these incorrect filenames, make a copy of the file (e.g., mailmsg.dll) in the i386 directory and rename the file to use the same name that appears in the .inf files. Then, locate the filename under the [SourceDisksFiles] section and follow the aforementioned instructions for changing the Disk ID to point to a new location.

One file type that you'll find—but for which you won't encounter matching files in the i386 directory or in any .cab file—is catalog files. Catalog files, which are identified by the .cat extension, handle driver signing. The sp3.cat file contains the checksums for driver files that have passed Windows Hardware Quality Labs (WHQL) testing. When Microsoft updates a driver, the company must distribute a new signed catalog file.

If you look closely, you'll notice that each hotfix contains either an updated sp3.cat file (or sp4.cat for SP4, and so on) or a catalog file with a name based on the hotfix's Q-number. When you copy sp3.cat files, you must locate the most recent version of the file and copy it to the i386 directory. Because catalog files are cumulative, the newest and largest file will be the safest bet. Copy the newest catalog file to the i386 directory and make note of the copied filenames because you'll use those filenames later.

Next, create a path named $OEM$$$hotfixes at the root of your distribution directory. Copy the hotfix installation programs to this directory. Note that this directory is at the same level as the i386 directory—not a subdirectory, as some Microsoft documentation states. When you run setup, the system copies the hotfixes subdirectory to the %systemroot% directory (e.g., C:winnthotfixes). After you copy all hotfixes to that directory, download qchain.exe from http://support.microsoft.com/default.aspx?scid=kb;en-us;q296861 and place it in the same directory.

The final step is to modify the svcpack.inf file so that it contains data similar to that which Figure 2 shows. Under [ProductCatalogsToInstall], you should modify the list to reflect the catalog files that you previously copied to the i386 directory.

If you followed all the instructions correctly, you now have a master distribution that contains all the service pack files plus any post­service pack hotfixes. If you ever add or reinstall a system component, you can be sure that your system will always use the latest files.

Building Winnt.sif
I always recommend installing Win2K as a minimal installation and adding components and services one at a time as you need them. For example, if you're setting up a Web server, start with a basic installation, then add IIS Web services. After you have IIS running and properly secured, you can add additional services, such as SMTP and DNS services, one at a time.

To start with a totally clean installation, you'll need to use a special file named winnt.sif. This file is identical to any unattend.txt file, but what makes it special is that when you name it winnt.sif and place it in the i386 directory, it runs automatically, even when you're installing from a bootable CD-ROM. The key to trimming down your Win2K installation is through the winnt.sif file's [Components] section. This section lets you disable components that you don't need. To disable everything, modify the winnt.sif's [Components] section as Figure 3 shows.

Earlier, you only copied files from the hotfixes; you didn't update any registry entries. Therefore, some tools (e.g., Windows Update) will report the hotfixes as not installed. To ensure that the system properly installs all hotfixes—beyond simply copying files—you need to run the hotfixes during installation. The best way to do so is to use the winnt.sif file's [GuiRunOnce] section. You copied all the hotfixes to the %systemroot%hotfixes directory, so be sure to point all commands to run from that directory. Figure 4 shows a sample [GuiRunOnce] section. Note the final call to qchain.exe, which ensures that the system copies the proper files when you're installing multiple hotfixes, regardless of the order in which you install them.

Go ahead and make any other customizations you want to the winnt.sif file. Then, save it in your distribution's i386 directory.

Making a Bootable CD-ROM
You'll find various documented methods for building bootable Win2K CD-ROMs. But the method I find the easiest is using WinISO Computing's WinISO shareware program. WinISO lets you extract an image from a CD-ROM and save it to an image file called an ISO. Open WinISO and select Make ISO from CDROM from the Actions menu. Create an ISO from the Win2K CD-ROM, and save it to a file. Next, open that file and delete all subdirectories, leaving only the files that reside in the root directory.

Now, add each of the directories from your master distribution. (You can either drag them or use the WinISO's toolbar's Add button.) After you have all the directories you need, save the image file. Most CD-ROM recording software can burn a CD-ROM directly from an image file. Check your software's documentation for specific instructions. However, you might find yourself burning several CD-ROMs as you tweak and test your installation.

A final important step is to test your distribution. For information about doing so, see the Web-exclusive sidebar "Testing the Distribution," http://www.secadministrator.com, InstantDoc ID 26136.

Tedium Worth the Payoff
You might need to perform some tweaking, but you now have a solid Win2K installation CD-ROM. Although this process seems dreadfully tedious and certainly isn't for everyone, having a Win2K installation that's safe to connect to the Internet is a great payoff.