Utility Spotlight
Automate Device Driver Integration
Michael Murgolo
When you’re deploying thousands of Windows-based computers, configuring a single system and duplicating its hard drive (or system image) onto other corporate computers can save you a lot of time and free up IT resources. Starting with Microsoft Windows 2000, system components like Plug and Play and tools like the System Preparation Tool (Sysprep) have allowed IT administrators and system builders to create one or more images to support a variety of hardware configurations. This column applies to Windows XP and Windows Server 2003. Some of the tools and techniques will change for Windows Vista. Visit
microsoft.com/technet/windowsvista to find information as it becomes available.
To reduce the number of images that are needed for multiple hardware setups, Sysprep provides an answer file, called Sysprep.inf. This mechanism allows you to deploy one image to various hardware setups. Rather than being limited to supporting a specific set of hardware devices that match the master system on which the image was created, an image can be rolled out to computers with varying hardware specifications (such as modems, sound cards, network cards, video cards, and so on). For a given hardware platform (x86, x64, or IA64), the only Windows
® component that dictates how many images will be required is the Hardware Abstraction Layer (HAL). For a discussion of HAL types and their relation to creating Syprep images, see Microsoft Knowledge Base
article 309283.
The entire process of creating a reference installation of Windows XP or Windows Server™ 2003 was covered in the March/April 2006 issue of TechNet Magazine. Additional guidance is available through the "Computer Imaging System Feature Team Guide" of the Business Desktop Deployment Solution Accelerator and the "Server Baseline Imaging Guide" of the Windows Server Deployment Solution Accelerator. Links to these are provided in the "Additional Resources" sidebar of this column. There is also documentation about unattended installations and using Sysprep in the help files of the Windows Deployment Tools (Ref.chm and Deploy.chm). These can be found in the Support\Tools\Deploy.cab file on the Windows XP and Windows Server 2003 product CDs.
This column is going to focus on how to automate the inclusion of additional device drivers in an unattended installation or a Syprep prepared image so that a single reference image can be deployed to numerous computer models with varying components. Upon startup, the installer will automatically detect and install the appropriate drivers for each individual machine. I will also describe scripts that can be downloaded to assist with this process.
How Windows Locates Device Drivers
When Windows XP or Windows Server 2003 is being installed or is running minisetup after Sysprep, they initiate automatic Plug and Play detection and try to automatically install drivers for any new hardware. Windows looks for matching device drivers by reading information from the .inf files that are generally included with device drivers. The process will read .inf files located in each folder listed in the DevicePath entry of the HKLM\Software\Microsoft\Windows\CurrentVersion registry key. By default this entry only contains the %SystemRoot%\inf folder, which contains the .inf files for device drivers that are included with the Windows operating system. If third-party drivers were manually installed when prompted by the Found New Hardware Wizard, then the %SystemRoot%\inf folder will also contain copies of the .inf files for those drivers. These will be renamed oemx.inf (where x is a number indicating it was the x+1 third-party device driver installed).
Therefore, by default only device drivers included with the Windows operating system will be installed automatically without user intervention. If a matching driver is not found, Windows displays the Found New Hardware Wizard (when a user with administrative rights is logged on) and asks where to search for the driver. Fortunately, there is a mechanism for adding folders to the list that Windows searches through when looking for device drivers. This allows devices to be installed automatically during an unattended installation or when running minisetup after Sysprep.
When creating your deployment image, if you have Plug and Play drivers that are not included on the Windows installation CD, you need to specify alternate paths (only the portion of the path relative to the %SystemDrive% root folder) in the OemPnPDriversPath key in the Unattended section of the unattended installation answer file (unattend.txt) or Sysprep answer file (sysprep.inf). When setup or Sysprep runs, it will append each folder to the DevicePath entry in the registry, adding %SystemDrive%\ to the beginning of each folder listed. Each folder that contains .inf files for a device driver needs to be specified in the OemPnPDriversPath entry. The folders named in the path must contain not only the drivers but also the catalog and .inf files.
Here’s a simple example of how this process works. Say I’m creating a Sysprep image and I need to add a NIC driver for computer model XYZ from vendor A and a video driver for model 123 from vendor B. Typically, you will download the drivers from the computer or device vendor’s Web site. The download might be a self-extracting executable file or a Zip archive. You extract the driver files from the download and place them in subfolders off the root of the drive (or in subfolders of the $OEM$\$1 folder for an unattended installation). The folders for this example might look like
Figure 1. For these drivers, the OemPnPDriversPath entry would look like this:
OemPnPDriversPath = Drivers\VendorA\XYZ\NIC;Drivers\VendorB\123\Video
For more details about adding Plug and Play drivers to Windows installations see Knowledge Base article 254078 (the "Additional Resources" sidebar has the link).
.gif)
Figure 1 Driver Folders
How Windows Picks Which Driver to Load
Now that Windows knows where to look for drivers, how does it decide which driver to use? This decision is controlled by the Plug and Play process. The following is a brief and oversimplified description of this process. (The "Additional Resources" sidebar can point you to documents that cover all the gory details.)
The Plug and Play specification requires that hardware devices have embedded device identification strings. Components of the operating system called enumerators query devices for their identifiers. There are three types of device identification strings: device IDs, hardware IDs (HWID), and compatible IDs (CID). Let’s take a closer look at these.
Device ID A device ID is a vendor-defined identification string. This is the most specific ID that setup uses to match a device to an .inf file. A device has only one device ID. Device IDs actually have the same format as hardware IDs. If an enumerator reports a list of hardware IDs for a device, the device ID should be the first ID in the list.
Hardware ID The hardware ID is the most specific device identifier that the vendor of the device defines. A device can have one or more hardware IDs.
Compatible ID The compatible ID is an indication that a device is compatible with another device, which means that the same driver can be used to drive both of them. The operating system can load a driver on the basis of the device’s compatible IDs if the device does not require a specific matching driver or if a specific matching driver is unavailable. A device can have zero or more compatible IDs.
When a device is detected, the appropriate enumerator (PCI, USB, Root, and so on) gets the device identification strings. Depending on the device and its associated bus, these strings can look like the following samples:
PCI\VEN_102C&DEV_00E0&REV_04
SCSI\DiskSEAGATE_ST39102LW_______0
IDE\DiskMaxtor_91000D8_____________________SASX1B18
The Device Identification Strings reference provides more details on the ID formats.
After Windows collects the IDs for the device, it searches all of the .inf files in the DevicePath looking for matching IDs. To locate a driver match, Windows Setup compares the device’s hardware IDs and compatible IDs to those listed in the .inf files on the system. Setup then creates a list of possible drivers for the device—these are drivers whose .inf files contain an ID (listed in the [Models] section) that matches one of the device’s IDs. If no match is found, the Found New Hardware Wizard starts and prompts the user for a driver.
Setup assigns a rank to each possible driver, indicating how well each driver matches the device. The lower the number, the better a match the driver is for the device. A rank of 2, for instance, is better than a rank of 4. And a rank of zero represents the best match. Ranking is based on such criteria as whether the ID that’s been attained from the device is a device ID, an HWID, or a CID (the more specific IDs are better matches); whether the driver’s ID is an HWID or a CID (again, more specific is better); whether the driver was signed or unsigned (signed is better); and whether the matching ID was found in an OS or platform-specific section of the .inf file. The details of this selection process can be found in the "How Setup Selects Drivers" article listed in the "Additional Resources" sidebar.
Adding Drivers to the Image
Of course, you also have to determine which drivers need to be added to the image for a particular computer model. Here’s how this process works. An easy first step is to install Windows from the setup CD on the particular computer model. After setup is completed, look in Device Manager. Any device that has a question mark next to it likely does not have a driver loaded because Windows does not have a default driver for it (see Figure 2). At minimum, drivers for these devices will need to be added to the image. (Note that if this computer has a vendor-supplied installation of Windows, you should capture the contents of the hard disk with a disk imaging tool like Norton Ghost before performing this fresh installation of Windows. You will need to restore the original installation and look at it later.)
.gif)
Figure 2 Devices Missing Drivers
Looking at the entries in Device Manager after a fresh installation of Windows may not be helpful since many of the entries that lack a driver will offer only generic details. Device Manager may tell you what type of device is missing a drive, such as an Ethernet Controller, or even worse it might simply tell you that there is an unknown device. Neither of these entries tell you the vendor or model of the device.
The next two places to look are the computer vendor’s Web site and the computer vendor’s installation of Windows (which is why I told you to image the existing installation). The vendor’s Web site will usually have a way to locate and download drivers for each computer model they make. Here you can look for drivers that match the device type you need to install. (Sometimes you may have to download and try installing more than one driver to identify the correct version.) For unknown devices, you will have to do some educated guessing.
Since identifying drivers from the vendor’s Web site can be difficult, a good place to look is on the vendor-supplied Windows installation. On a computer running the vendor’s installation of Windows, look in Device Manager for entries that could represent the "unrecognized" devices. This can help you identify which drivers you need to download from the vendor’s Web site.
You may notice that some devices that were recognized by the new Windows installation function properly even though they have a different name or driver version. This means that the vendor supplied a different (usually newer) driver for the device. Should you stick with the in-the-box driver that comes with Windows or use the latest driver supplied by the computer or device vendor? There is no single answer to this question. It depends, in part, on the number of device drivers you have to manage for all the computer models that your image needs to support (using in-the-box drivers will reduce this number) and whether the new driver provides any necessary improvements or capabilities not included in the default Windows driver. Of course there is no substitute for lab testing to see which driver works best for a device.
If all of this sounds like a tedious and labor-intensive process, believe me, it can be. Because of this, I have developed a few VBScript apps to take some of the manual labor out of this process. You can get these scripts and a document that details their use in the download for this article. Brief descriptions are provided in the "Image Setup Scripts" sidebar.
Troubleshooting Driver Selection and Installation
You’ve installed Windows on a reference computer, added all the drivers to your image, run Sysprep, and created an image file. What do you do if a driver problem occurs when installing the image on another computer model?
The %SystemRoot%\setupapi.log file holds the key to most of these driver mysteries. This log file maintains the information that SetupAPI records about device installation, service-pack installation, and hotfix installation. You can use it to help track down the causes of most driver problems. The white paper titled "Troubleshooting Device Installation with the SetupAPI Log File" (see the "Additional Resources" sidebar for a link) provides great detail on how to read and interpret what is found in the setupapi.log file.
Conclusion
As you have seen, creating an image that supports multiple computer models requires some research, configuration, and testing. However, I hope that the information and tools provided here take some of the mystery and the drudgery out of accomplishing this goal because the end result is faster, more efficient rollouts.
Michael Murgolo is a Senior Infrastructure Consultant for Microsoft Consulting Services. He is focused in the areas of operating systems, deployment, network services, Active Directory, systems management, automation, and patch management. He is a subject matter expert in the area of desktop deployment and migration.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.