As I explain in my 1998 series of columns about unattended installations, Windows NT 4.0 lets you script unattended network-based installs even when the installation CD-ROM doesn't include a hardware driver that your system needs. (For a list of the articles in that series, see "Related Articles in Previous Issues," page 158.) Scripting an unattended install for such a case isn't easy, however—every hardware driver you want to add requires you to perform numerous steps and extensively edit your installation script.
Because Windows 2000 incorporates Plug and Play (PnP), including new or updated drivers in an unattended network-based Win2K installation is much easier than in NT 4.0. You can easily tell Win2K to automatically install devices such as sound cards and video capture hardware, even if the devices' drivers aren't on the installation CD-ROM. (Of course, you must have Win2K drivers for the devices; when it comes to driver support, we Win2K users are still afterthoughts compared with Windows 98 users.)
Unattended Network-Based Win2K Installs
When you install Win2K from a network, you don't need to use the installation CD-ROM. The basic steps for doing a network-based unattended Win2K installation are as follows:
- Create the network distribution share, copy the contents of the i386 folder (i.e., the Win2K installation files) to the share, and set permissions on the share.
- Add a $OEM$ folder so that you can customize the installation (I explain this step later).
- Use Setup Manager, as I explain in "Unattended Installs with Windows 2000 Professional," June 2000, and further enhancements, which I explain later, to create answer files, which are simple ASCII text files.
- Create a 3.5" disk that contains the necessary drivers and enough of the OS to let you boot a machine that has an empty hard disk, get on the network, and access the network distribution share. After you boot to the network share, execute the Winnt command to start the scripted install.
This procedure is basically unchanged from the NT 4.0 procedure, although some details are different.
The biggest difficulty in the entire process is the last step: making a bootable 3.5" disk that contains enough code to let you access a network share. I wish I could tell you that you can easily create this disk, but you can't. What I've found works best is simply to use Microsoft Network Client 3.0 for MS-DOS, which Microsoft includes in the NT Server 4.0 CD-ROM's \clients subdirectory. By including a minimum of programs and doing a bit of fiddling, you can usually cram enough Win98 code (or better yet, DOS 6.0 code, if you still have a copy) and the Network Client for MS-DOS onto a disk to let you access the distribution share. However, I rarely succeed in building the disk with TCP/IP, so you might consider instead creating a NetBEUI-based network client and running NetBEUI on the server that holds the network distribution share. I realize that this approach isn't the perfect answer for many people, but remember that you have other ways to put Win2K on a system, including Remote Installation Services (RIS), the Microsoft System Preparation Tool (Sysprep), and the CD-ROM-and-3.5"-disk approach that I describe in "Unattended Installs with Windows 2000 Professional."
What I want to highlight in this column, however, are the new $OEM$ features that Win2K affords. Remember that NT 4.0 lets you create a directory called $OEM$ inside the network distribution share's i386 directory, and $OEM$ in turn lets you do some neat things. Inside the \i386$OEM$ directory, you can place setup bitmaps, logos, extra hardware drivers, and commands for Setup to run after NT 4.0 has installed. To tell NT 4.0's Setup to look for the \i386\$OEM$ folder, you simply include the command OEMPREINSTALL=YES in the answer file's \[Unattended\] section.
Win2K offers these abilities and a few more. Without a doubt, one of the most valuable of Win2K's enhancements is that you can easily add new hardware drivers to an unattended-install script.
Adding Drivers with Win2K's $OEM$
Suppose you've just purchased a new video board—a board so new that the Win2K CD-ROM doesn't include drivers for it. If you use an answer file to do an unattended installation for your computer, the installation will stop at some point and Setup will ask you for the driver for your new video board. An installation that requires input from you is hardly unattended. What can you do?
You can create a directory under \i386\$OEM$, name the directory anything you like, and put the Win2K drivers for your new video board into the directory. (Before you put your unattended-install script into production, test the drivers to make sure they're Win2K-compatible.) Exactly what makes up a Win2K video driver varies. Some video drivers consist simply of two files—one with the .sys extension and another with the .inf extension. Other video drivers load entire desktop control utilities. You'll generally find your video board's complement of driver files on the 3.5" disk or CD-ROM that comes with the board, in a folder named Win2000 or something similar. Then, add the OEMPnPDriversPath command to the answer file's \[Unattended\] section. This command tells Setup to look in the directory that OEMPnPDriversPath points to if Setup can't otherwise find a needed driver.
For example, suppose I've got a new video board called the PixelPainter whose Win2K drivers consist of the files pixpaint.sys and pixpaint.inf. I create a directory called \i386\$OEM$\extravideo on the network distribution share and put both driver files into that directory. Suppose also that I have a working answer file named script.inf. I add the command
to script.inf's \[Unattended\] section.
In Win2K, installing new drivers unattended is that simple—quite an improvement over NT 4.0 scripted installs. You don't even need to tell Win2K that the driver is a video driver: Although I named the directory extravideo, I could just as easily have given it any other name.
In a few years, you'll be installing Win2K on circa-2003 machines on which most of the hardware and drivers will be new. Consequently, you'll have a lot of new drivers to offer Setup—video drivers, SCSI drivers, sound drivers, USB device drivers, and so on—so your network distribution share will have more than one set of updated drivers. How can you offer more than one set of drivers to Win2K's Setup? You have two ways to do so.
|Related Articles in Previous Issues|
| You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com/.|
Inside Out, "Unattended SCSI Adapter Driver Installations,"
November 1998, InstantDoc ID 3951
Inside Out, "Automatically Install Display Drivers,"
October 1998, InstantDoc ID 3863
Inside Out, "Unattended Install Tricks,"
September 1998, InstantDoc ID 3773
Inside Out, "Advanced Unattended Installs,"
August 1998, InstantDoc ID 3685
But for a number of reasons, you might not want to put all your drivers into one folder. The folder's contents could become hard to keep track of after the number of driver files exceeds a few dozen. Or, a couple of pieces of hardware might have drivers with similar names—for example, two SCSI vendors might be uncreative and name their drivers scsi.sys. In either case, you can take the second approach and use more than one folder.
Creating as many driver folders as you like causes no problem. Just put all the folders into the \i386\$OEM$ directory. For example, you might put some drivers in a folder named \i386\$OEM$video, others in the \i386\$OEM$\scsi1 folder, and still others in the \i386$OEM$\scsi2 folder. Your OEMPnPDriversPath command would then be
Notice the syntax. You specify only the part of the directory below \i386$OEM$; a list such as \i386\$OEM$video; \i386\$OEM$\scsi1; \i386\$OEM$scsi1 won't work. You separate the directories with semicolons and enclose the entire list in quotes.
And That's Not All
Like NT 4.0, Win2K offers you a number of options for network-based system installs and uses an $OEM$ directory. But Win2K lets you do considerably more with $OEM$ than NT did. I'll show you some more new $OEM$ tricks in future columns.