My job requires me to manage computer networks all over the country. Last fall, I was asked to design a network for a new hospital in Texas. I talked management into waiting until Windows 2000 had been released before moving forward with this project. Now that Windows 2000 has been released, I can’t put the project off any longer. My goal is to get the Texas network up and running as quickly as possible so that I can limit the amount of time that I spend in Texas to a day or two. Naturally, I was looking for shortcuts for the gargantuan task of installing device drivers and applications onto each workstation. After researching a bit, I discovered that Windows 2000 has some built-in tools that make the job easier and faster.
There are several options that you can use in order to mass-produce a specific configuration. All of these methods have good points and bad points. Space restrictions prohibit me from discussing each option in detail. Therefore, in this Daily Drill Down, I’ll discuss the Windows Installer Service, which is my favorite method of mass-producing a configuration. Then, I’ll briefly describe some of the other installation options that you can use: a server-based setup, a batch file, and an image file.
The Windows Installer Service
The Windows Installer Service is a Windows 2000 component that standardizes the application installation process by building the rules for installation into the operating system rather than into the Setup program. To accomplish this task, the application stores itself in Windows through a database file called the Windows Installer package.
Some terms to know
Before I continue, you need to become familiar with a few terms that I will be using. The following terms are also used in Microsoft documents about the Windows Installer Service:
- Resource: Any component that an installation program normally adds to Windows. It may be a file, a registry entry, a DLL, an icon, or anything else.
- Component: A collection of resources that function as an integrated unit. It can be installed or uninstalled without having to worry about individual resources. Anytime that a component is installed or removed, the resources that make it up are also installed or removed.
- Product: The application as a whole. It’s usually made up of several components. For example, Microsoft Office is a product that’s composed of such components as Microsoft Word and Excel.
The package file
The package file tells Windows 2000 about the product. Most products that are designed to run on Windows 2000 ship with their own package file. The package file is usually found in the root directory of the CD-ROM that contains the product. The package file has a filename with an extension of MSI, which indicates that the file is a Microsoft Installer Service database. The package file makes it very easy to install products in a standardized manner. In the real world, however, you may use older programs that don’t have a package file. If so, or if you have a large mixture of programs and complex device drivers, you need to create your own package file. You can create one with a tool called SYSDIFF.
The SYSDIFF tool
The idea behind the SYSDIFF tool is that, if you have several systems with identical hardware, you only have to set up one system. Then, you run SYSDIFF in something called SNAP mode, and you create a snapshot of the system’s configuration. Next, you perform a clean install of Windows 2000 on the new systems. (By clean install, I mean not adding any special device drivers or applications.) Now, you run SYSDIFF in something called DIFF mode in order to create a difference file. Then, you use the SYSDIFF tool to build a package file based on the differences between the clean system and the fully configured system. Below is a summary of the SYSDIFF syntax:
SYSDIFF [/SNAP | /DIFF | /APPLY | /DUMP | /INF] [/LOG:LOG_FILE] [/M] [/?] [/DSP] [/P] [/Q] [/C:”COMMENT”] SNAPSHOT_FILE SYSDIFF_FILE DUMP_FILE OEM_ROOT
In this line, /SNAP, /DIFF, /APPLY, /DUMP, and /INF refer to the modes in which SYSDIFF will run. LOG_FILE is a log file that SYSDIFF creates during the process that you initiate. If you use the /M switch, file changes that occur during the program will appear to be default user files. This switch is used only in /APPLY and /DUMP mode. You would use /? to display help on the SYSDIFF program. The /DSP switch tells SYSDIFF not to generate a distribution share point when it runs in /INF mode (because one already exists). Normally, SYSDIFF scans all files and folders on a computer for changes, but you can use the /P switch to force SYSDIFF to scan only the user profile. The /Q switch tells SYSDIFF to run in quiet (unattended) mode. The /C:”COMMENT” switch is the name given to newly created packages as they appear onscreen during setup. SNAPSHOT_FILE and DIFF_FILE are used as normal filenames whenever these types of files are created. DUMP_FILE is used as a filename when you run in DUMP mode; SYSDIFF uses it to create a diagnostic file. Finally, OEM_ROOT is the path through which SYSDIFF creates the \$OEM$ structure. SYSDIFF places the INF file there. The INF file is called Sysdiff_file.inf.
SYSDIFF can become very complicated, but the basic procedure isn’t too difficult to understand. First, you must install Windows 2000 on a new computer. Then, locate the Sysdiff.inf file. This file contains information about certain registry keys and files that SYSDIFF should exclude when it compares the two files that you create. Look at this file to make sure that it’s acceptable. If you must modify Sysdiff.inf, the instructions for doing so are located within the file. Now, take a snapshot of the clean installation of Windows 2000 by entering this command:
SYSDIFF /SNAP [/LOG:LOG_FILE] SNAPSHOT_FILE
Once you create the snapshot file, you need to configure the system with the necessary applications and device drivers. Then, use SYSDIFF to create a difference file. Enter the following command:
SYSDIFF /DIFF [LOG:LOG_FILE] SNAPSHOT_FILE SYSDIFF_FILE /C:”COMMENT”
Note that the comment can contain only the names of the applications that you’re installing. The process may take some time. If you abort before you see a message indicating that the process is complete, the files that you create will become invalid. You’ll have to erase those files and create a new file. After SYSDIFF runs successfully, you can view the difference file by entering the following command:
SYSDIFF /DIFF [/LOG:LOG_FILE] SNAPSHOT_FILE SYSDIFF_FILE /C:”COMMENT”
This procedure works through the entire process of creating a difference file again. This time, however, it writes the information to the screen. It’s the only way of viewing the contents of the difference file. Now, you’re ready to apply the difference file. To do so, the system root folder must exist in the same location on the destination computer as it did on the computer that created it. The destination computers must run Windows 2000, which must be installed in the \WINNT folder. To apply the difference file, enter the following command:
SYSDIFF /APPLY /M /SYSDIFF_FILE
If you’re running low on hard disk space, you may use the /INF switch. If you do, the SYSDIFF file will contain pointers to the applications rather than the actual applications themselves. The syntax for this command would be:
SYSDIFF /INF /M SYSDIFF_FILE OEM_ROOT
Besides the Windows Installer Service, there are other options for mass-producing a configuration.
One method involves using a server-based setup to install Windows 2000. In this procedure, all of the setup files are stored on the server, along with one or more scripts that are designed to install Windows 2000 into your environment. The advantage to using this method is that it works regardless of whether the hardware is the same for all of the clients or not. It’s a good technique to use if you’ve got an established network and you want to upgrade the existing network clients to Windows 2000 Professional.
The downside to a server-based setup is that, although setting up Windows 2000 is relatively easy, it can become difficult to write scripts for installing applications. This fact is especially true of applications that require you to restart the computer after installation.
Another method that you can use involves using a batch file to automate the dirty work. This method can make your life easier if you have an extremely large number of clients to configure. However, such batch files are extremely tedious to write. Therefore, it’s probably not worth your time to write a batch file for just a few clients. Another downside is that it’s practically impossible to install most device drivers through batch files. Doing so involves a lot of scripting. Unless you’re very talented at scripting or you have a lot of time to kill, I wouldn’t recommend this method.
Still another way of mass-producing a particular configuration is to copy it directly to each computer’s hard drive. Windows 2000 contains a tool that you can use to create an image of a hard drive. Thus, you can set up a computer exactly the way in which you want it to be set up, and you can make an image of the configuration. Then, you can plug in a hard drive from a client machine and duplicate the configuration onto the new hard disk.
This method has several advantages. First, it’s pretty much idiot-proof. The process of creating and copying the image file is very easy. Microsoft has also written the code behind the process in such a way that it makes the process very quick (comparatively speaking). Instead of performing a sector-by-sector or file-by-file copy, Microsoft’s copy routine uses a different method that’s supposed to be much quicker than the normal methods of copying a hard disk.
Unfortunately, this method also has certain disadvantages. First, all of your hardware must be identical for the process to work. All of the machines must have the same processor, memory, hard disk size, video card, and so on. Another disadvantage is that the process requires you to disassemble every computer. With some brands of computers, it’s very difficult to get the hard disk out of its case. To make the process work correctly, you must know how to set the jumpers on the hard disk. Basically, it’s a good method as long as your hardware is identical and as long as you don’t fear the cuts, bruises, and electrocution hazards that are associated with dismantling computers.
Brien M. Posey is an MCSE who works as a freelance technical writer and as a network engineer for the Department of Defense. If you’d like to contact Brien, send him an e-mail. (Because of the large volume of e-mail he receives, it's impossible for him to respond to every message. However, he does read them all.)The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.