Specifying New Drivers on Unattended Win2K Pro Installs

Improved $OEM$ features let you easily script installs even if the installation CD-ROM lacks needed hardware drivers

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:

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

OEMPnpDriversPath="extravideo"

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.

First, you can put as many drivers as you like in one directory. To extend my example of the computer with the PixelPainter video board, let's suppose that the computer also has a SCSI board whose drivers aren't on the Win2K distribution CD-ROM. If the SCSI host adapter uses a pair of driver files called myscsi.sys and myscsi.inf, you can simply copy those two files into the i386$OEM$extravideo directory and change nothing else. When Setup needs to find SCSI drivers, it will look in the extravideo directory.

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

OEMPnPDriversPath="video;scsi1;scsi2"

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.