Adding drivers to RIS images without RIPrep (Windows XP and Windows 2000)
The other day, a new machine arrived at the office. Although it was a fast and sexy Dell Optiplex SX280, I dreaded going through the setup and installation procedure; maybe because I live in a dream world. In my personal administrators’ dream world, when a new desktop computer arrives the hardest task is trying to get your signature right on that funny brown handheld computer that the UPS dude hands you after dropping the box. That’s because in my dream world I use a fleet of tools and technologies that MS refers to as IntelliMirror. In a nutshell, IntelliMirror equals RIS plus AD plus Windows Installer. I won't tell you all the gory details about these; rather, for the remainder of this article I'll assume that you have used RIS before.
Back to my dream. Up until the arrival of the new Optiplex, all of our machines were mostly identical. Consequently, one RIS image was enough to cover them all. Whenever some user messed up the machine, I simply rebooted the machine into PXE and reinstalled the RIS image from the server. The RIS image only contains the OS and the necessary drivers. All other software is repackaged into Windows Installer packages (MSI) that are deployed through group policies (GPO) in Active Directory. The whole process is unattended and after thirty minutes the machine is clean and ready to be used again.
Some of the machines have slightly different hardware. A second video card, a parallel port extension, stuff like that. In a perfect dream world, how do you deal with these minor differences in hardware? You can have multiple RIS images (one per hardware setup) but managing multiple RIS images is tedious. You could try to incorporate all drivers for all the different hardware setups in one image but some drivers don’t coexist peacefully on one machine. Furthermore, for both of these methods you’d have to install the image, install the driver and then run RipREP to create an updated image. Alternatively, you could try to deploy the drivers using Windows Installer by “snapshooting” the driver installation as you would do with conventional application software installations. This approach looks very promising because you can assign drivers to individual machines and updating to a new driver version is also a lot easier. Unfortunately, the snapshot method for creating MSIs doesn’t really work for drivers. This is because the driver installer and Windows itself change registry keys that are not covered by the snapshot program. In the past I tried all of these methods with varying success. If one method didn’t work I tried the next until I found something that worked. What a mess!
To make matters worse, the new Dell machine had a network card (NIC) that wasn’t supported by the text mode RIS setup a.k.a. Preinstall Environment. When booting into PXE, I would get the message “The network server does not support booting Windows 2000. Setup cannot continue. Press any key to exit.” It didn’t help putting the driver into the image because the text mode setup runs before the image is copied to the machine. Since my RIS images are located on a domain controller, I had to somehow get the driver into the RIS image and the text mode RIS setup. MS provides information on how to do that in a Knowledge Base article [1]. I would like to reformulate the procedure here because the KB article is somewhat vague and ambiguous.
Putting a driver into text mode RIS setup
This procedure is only necessary for the hardware drivers that are required for text mode RIS setup: network card drivers (if your images are located on a RIS server) and storage drivers. For all other drivers there is an easier way of deployment but more on that later on.
Ingredients: Raw driver, RIS image and text editor. By raw driver I mean the .INF-file and the accompanying files, usually .SYS files and .CAT files. If the driver is in a ZIP file or a self-extracting archive you’ll have to unpack it. Some driver packages contain drivers in various languages and for various platforms, i.e. XP, Win2000, NT and so on. Pick the right architecture for your RIS image. If you find an .INF file in a directory, you need all the files in that directory.
- On the RIS server, you should have a share called
REMINSTthat contains the RIS images created through RIPrep and the CD based image (RISetup image). The RISetup image was created when you installed RIS on your server. Connect to theREMINSTshare. Assuming that your server is calledSERVER, the RIPrep and RISetup images are in\\SERVER\\REMINST\Setup\Language\Images. Let’s say the RISetup image is called RISetup and the RIPrep is called RIPPrep. - Create a directory called
$oem$in\\SERVER\\REMINST\Setup\Language\Images\RISetup. In$oem$create another directory called$1. In$1create the directoryDrivers. - In Drivers create a directory using a name no longer than 8 characters that describes the hardware for which you are installing the driver; for example,
Broadcom. You end up with the empty destination directory\\SERVER\\REMINST\Setup\Language\Images\RISetup\$oem$\$1\Drivers\Broadcom. - Copy the raw driver into that directory. The drivers that I came across all had a flat layout (everything in one directory) but if the source directory that contains the INF file has sub-directories, MS suggests that you create these sub-directories in the destination directory as well.
- Copy the INF and SYS files into
\\SERVER\\REMINST\Setup\Language\Images\RISetup\i386. - In
\\SERVER\\REMINST\Setup\Language\Images\RISetup\i386and its subdirectories, search for a file calledRistndrd.sif. It’s usually located directly ini386but MS says it’s ini386\templates. Add or update the following statements to the[Unattended]sectionDriverSigningPolicy = Ignore OemPreinstall = yes OemPnpDriversPath = Drivers\Broadcom
Make sure there is only one line starting with
OemPreinstall. For example, my SIF file already hadOemPreinstall = no. In this case do not add a second one, but change thenointoyes. The same applies to the other two statements. - Repeat steps the steps 3 to 6 for every driver you want included in text mode setup. Separate the entries in
OemPnpDriversPathby a semicolon.OemPnpDriversPath = Drivers\Broadcom;Drivers\Hamster
- On the RIS server, restart the BINL service by launching cmd.exe and typing
net stop binlsvc net start binlsvc
If you install this image onto one of your workstations, you will notice that the text mode RIS setup (a.k.a. pre-install environment) doesn’t complain anymore and dutifully copies the images onto the workstations hard disk. But when the machine reboots into graphics mode, it will not install the driver, leading to all sorts of trouble. For example, if the driver was for a network card, the system wouldn’t join the domain. What happened?
In the above mentioned KB article, MS says NOTE: If the RIS image was created with RIPREP, you must perform these steps on both the RIPREP image and the RISETUP image that corresponds to the RIPREP image.” Hmmh, these steps? Which steps? All of them? And how else can you create a RIS image, other than with RIPPrep? No matter how I interpreted this ambiguous sentence and whatever I tried, the driver would not be installed on the computer. There is a similar KB article on the same subject which explains things a bit differently to some extent, but that article didn’t help either. In some way that actually makes sense, because if I want a driver to be installed on a workstation, it should be included in the RIS image and not just the text mode setup.
Putting a driver into a RIS image
Through dumb luck I happened to stumble upon a third KB article [3] in which MS describes how to fix a bug in SYSPREP. The bug causes multiple identical entries to be added to DevicePath. What is DevicePath? It’s a registry value that contains a list of paths in which Windows searches for drivers when it detects new PNP hardware. Windows automatically performs an unattended installation of any suitable driver it finds. The default value for DevicePath is “%SystemRoot%\inf” and to be precise, it’s a list of locations in which Windows looks for INF files. The INF files then tell Windows where to look for the real driver files (SYS and CAT and the like).
Why don’t we just copy the raw driver files into a directory that’s part of the image and then update the DevicePath accordingly? As the driver directory belongs to the image, it will be copied to the machine’s harddisk. When the machine reboots after the image was installed, Windows should (re-)detect PNP hardware it doesn’t have a driver for and look up possible driver locations from DevicePath. This time Windows will find our driver and install it. Bingo! It’s kind of like pre-staging the driver by copying the driver files onto the target machine and telling it where to find the driver in case the hardware for it is detected. How do you do this?
- Create the directory
\\SERVER\\REMINST\Setup\Language\Images\RIPrep\i386\Mirror1\UserData\Drivers\Broadcom. Remember that RIPrep stands for the name of your image and Broadcom signifies your hardware. These names are just examples and you will need to adjust them to your requirements. - Copy the driver files into the newly created directory.
- On the server or your personal workstation, fire up
regedt32if it’s Windows 2000 orregeditif it’s an XP machine. (My personal workstation has Windows XP on it and so I useregedit.) - Load the
Softwareregistry hive that’s part of the image by selectingHKEY_LOCAL_MACHINEand choosingLoad Hiveon theFilemenu. Navigate to\\SERVER\REMINST\Setup\Language\Images\RIPrep\i386and pick the Software file.
\Mirror1\UserData\WINNT\SYSTEM32\CONFIG - Type
RIS Imageas the temporary name of the hive. - In the registry tree, navigate to
HKEY_LOCAL_MACHINE\RIS Image\Microsoft\Windows\CurrentVersionand in the right pane double click theDevicePathvalue. - Append
;%SystemDrive%\Drivers\Broadcomto the value. - Unload the hive by navigating to
HKEY_LOCAL_MACHINE\RIS Imageand selectingUnload Hiveon theFilemenu. Don’t forget this step because otherwise the hive will not be saved until you reboot your personal workstation. - Install the RIS image on a test machine.
- Enjoy.
Pre-staging the driver is also much cleaner and safer solution. The old-school way of deploying drivers using RIS required downloading an image onto a computer, installing the driver by hand and uploading the image back to the server using RIPPrep. Installing the image on another machine that doesn’t have the hardware for this particular driver can cause all sorts of conflicts. The more drivers you are trying to deploy that way, the more likely you will run into trouble. Pre-staging the driver is different in that the driver files reside on the machine but the driver will only be installed and active if the right hardware is available.
As always in information technology, there will be a situation in which even this gentler, softer way of installing drivers doesn’t work. And this wouldn’t be a Diary Products article if I hadn’t run into such a situation myself. But don’t worry, my perfect dream world is not going to turn into a nightmare. More on that in another article, but to give you a sneak preview, I’ll tell you this: the new Optiplex system comes with drivers that require Windows 2000 SP4. All of my RIS images are SP2-based and I deploy SP4 using an SP4 using a Windows Installer Package (MSI) that is assigned to my workstations through a GPO. Right after the image is installed, it will boot into an SP2 Windows and then try to install the pre-staged SP4 drivers and crash. Stay tuned.
References:
[1] How to Add Third-Party OEM Network Adapters to RIS Installations: http://support.microsoft.com/kb/246184
[2] How to Add a Third-Party OEM Network Adapter to an RIS Installation: http://support.microsoft.com/?kbid=315279
[3] OemPnpDriversPath appears multiple times in DevicePath http://support.microsoft.com/kb/285948/EN-US/