Manage Learn to apply best practices and optimize your operations.

How to create custom driver databases with Windows Deployment Services

Plug and Play isn't just for USB devices. Here's how to put it to work in your installation environment.

You can’t work with Windows for long without seeing plug and play in action. Insert a USB device and this service...

gets to work identifying the device, locating its driver, and configuring the resources that get it working.

Plug and Play (PnP) isn’t just for USB devices, though. The concepts surrounding PnP are a central part of the entire Windows experience. Network cards, video cards, just about any peripheral that plugs into Windows sees some measure of bootstrap automation from this handy service.

You can also take advantage of the Plug and Play experience during a Windows installation. In fact, the Windows Preinstallation Environment (WinPE) uses it to automatically locate and install any drivers it has access to on your installation media.

That’s great when that media includes the device drivers you need. If it doesn’t, you can create your own custom driver database with Windows Deployment Services in Windows Server 2008 R2. With a little extra effort, that database will ensure that every driver gets installed before you ever hit Control + Alt + Delete.

Step 1: Unpack

Add the Windows Deployment role with all role services to an available Windows Server 2008 R2 computer. Then, from the Windows Deployment Services administrative console, add, install and boot images from your Windows DVD media.

If you’re like many IT shops, you probably have an IT file share where you store drivers for the equipment you manage. You’ll need to “unpack” each driver into its constituent components. This process is a lot like unzipping a file, and sometimes requires multiple iterations until you get the files you need. These files often have a .CAT, .SYS, and/or .DLL extension, and are co-located with a file having a .INF extension. You'll need that INF file, as well as those going with it, for the next step.

Once images are installed and drivers are fully unpacked, right-click the Drivers node in WDS and launch the Add Driver Package Wizard. This wizard gives you the ability to select driver packages from an INF file, or to select all driver packages from a folder. Choosing Select all driver packages from a folder will upload all drivers in that folder and its subfolders into the Driver database.

The next screen will display information about any Driver Packages found in the folder structure. Select those you want to upload and click through to complete the wizard. Pay careful attention here to ensure you’re uploading those drivers for the right processor architecture -- x64 versus x86.

Once the upload is complete, start a Windows deployment using WDS and see what happens. If you’ve done everything correctly, that Windows installation should automatically install any drivers for the hardware and devices it finds.

Step 2: Group and Filter

Plug and Play works great -- when it works. It does occasionally get confused about which drivers belong with which computers. In these situations, it can be useful to separate out drivers by groups and filters. You can create a Driver Group back inside the WDS console by right-clicking the Drivers node and choosing Add Driver Group.

Each driver group will contain one or more Client Hardware Filters that are used to identify sets of clients by hardware composition. Filters come in two types: Hardware Filters and Image Filters.

Hardware Filters define sets of equipment via values in Windows Management Instrumentation (WMI). Five filter types are available: Manufacturer, Bios Vendor, Bios Version, Chassis Type, and UUID. Because these values are stored in WMI, you’ll need a reference computer with which to query WMI and gather the values for that set of hardware. You can run any of these five PowerShell commands on your reference computer to get the value from its WMI store:

  • Manufacturer: Get-WmiObject Win32_ComputerSystemProduct Vendor
  • Bios Vendor: Get-WmiObject Win32_Bios Manufacturer
  • Bios Version: Get-WmiObject Win32_Bios Version
  • Chassis Type: Get-WmiObject Win32_SystemEnclosure ChassisTypes
  • UUID: Get-WmiObject Win32_ComputerSystemProduct UUID

Image Filters define sets of equipment by characteristics of the operating system to be installed. Three filter types are available: OS Version, OS Edition and OS Language. Getting the correct values for these three image filters is slightly more challenging.

  • OS Version: This value is constructed from the Image version and Service Pack level values found in the properties of the Install image you intend to deploy. View those properties in WDS, select the Version tab, and concatenate the two values you find separated by a period. For example, if the Image version is 6.1.7601 and the Service Pack level is 1, the resulting value will be 6.1.7601.1.
  • OS Edition: Getting the OS Edition requires running two commands at the command prompt against the image you intend to deploy. First run the command dism /Mount-Wim /WimFile:<pathToWimFile> /index:1 /MountDir:<targetFolder>. Then, run the command dism /image:<targetFolder> /Get-CurrentEdition. This second command will give you the value to enter for OS Edition.
  • OS Language: This value is also obtained from your image’s reference computer. On that computer run the following PowerShell command: [convert]::ToString((Get-WMIObject Win32_OperatingSystem OSLanguage | Select-Object -ExpandPropertyOSLanguage), 16). Then, match the hexadecimal value that results to the Culture Name found in the National Language Support API Reference table found here.

The last page in the Add Driver Group Wizard provides the option to Install only the driver packages that match a client’s hardware or Install all driver packages in this group. Choosing the first will only install those drivers which Plug and Play can correctly match, while choosing the second will install every driver in the group. This second setting can be useful when Plug and Play can’t correctly identify (and, thus, won’t install the driver) a device or piece of hardware on a system.

Step 3: Deploy!

While the process to construct filters might be a bit cumbersome, WDS driver databases are an excellent way to extend the usefulness of Plug and Play. With the right drivers and a well-built install image, you can create your own installation environment of Plug and Play for everything.

Greg Shields is a Partner and Principal Technologist with Concentrated Technology, an IT analysis and strategic consulting firm. Contact him at

Dig Deeper on Legacy operating systems