MDT/OSD Driver Management overview

Wanted to write down some notes on various Device Driver deployment issues related to MDT and SCCM.

I had done some work recently with Microsoft IT with their latest Windows 8 roll out using MDT 2012. It was quite enlightening to see some real world device driver installation issues get worked out. The Microsoft IT OS Deployment team had an extensive lab where they had at least one of every kind of officially supported machine present for us to do some testing on.

First thing I did was add my previously released ZTIYellowBang.wsf script to our standard Task Sequence. Then I would get a report of every device that was missing a driver at the end of the deployment. This helped speed things up during the early phases. I didn’t have to go to each machine and get the PnP ID for the missing device, the information was automatically copied to the logging server share, all I had to do was grep the output looking for errors.

Driver Type – InBox

In box refers to those drivers that are included in Windows directly, back when Windows came in a physical box, now the images come in *.iso, *.vhd, or *.wim. And rarely on a physical DVD. Microsoft has done a very good job working with Independent Hardware Vendors (IHV), and OEM’s to get the most important and common device drivers added to the OS directly. This is great news for most of us, it means that for the most recent OS’es like Windows 8.1, we should expect great driver coverage for devices over a year old, and good driver coverage for newer devices.

Driver Type – Windows Update

When an IHV submits a driver to get signed, they go through the Windows Hardware Certification process. Needless to say, I will only use drivers that have been fully signed by Microsoft. The driver signature is the best indicator that the device and driver has been tested and is ready for production. If the driver is not signed, then it’s usually a good sign that the device is not yet ready for prime time. During the signing process, the IHV can add the device to Windows Update. This makes it super easy to find the driver, I can go to the site, type in the PNP ID and get the latest driver package directly from Microsoft. This should be the same driver package as if I updated the device in the device manager, and selected to search Windows Update for the correct driver.

You can test these driver packages by going into the device manager (devmgmt.msc), clicking on the device in question, and updating the driver. IF you point to the folder where you extracted the driver package, Windows will install the driver.

A clean driver package will have at least an *.inf file (this contains the metadata used to install the driver) and a *.cab file that is the digital signature (remember my comment above about signed files?). Depending on the driver, it will also most likely have a *.sys file, which is the actual driver. I say “sometimes”, because some devices don’t need a driver, all the configuration items can be contained in a *.inf file, like a Modem (remember those?).

Driver Type – Exe Package

The advantage of the site is that I can download “clean” drivers, rather than drivers that have been re-packaged by the IHV. Going to the Device Manager to update a device driver as described in the previous paragraph can be a little cumbersome for some non IT professionals, so some IHV’s like to re-package drivers with a *.exe installer that will handle the installation for you. Unfortunately, the MDT driver handing system (ZTIDrivers.wsf) can’t use the *.exe packages as-is. It’s designed to handle the “clean” driver packages that you might download from the catalog site. IF you wanted to install a driver that was contained in an *.exe wrapper through MDT ZTIDrivers.wsf you would need to extract out the driver. Typically the *.exe only contains some fluff, and you can easily use the extracted driver package in MDT, however some (IMHO) poorly written drivers may require some user mode content that can only be installed via the *.exe file. Only testing can verify.

MDT (Boot) Critical Drivers

There are some drivers that *must* be handled by the MDT/SCCM driver handling system. These include: Storage, Wired Networking, and System drivers. Anything that is required outside of the inbox drivers to boot up the OS, get access to the boot/OS disk, and access the wired network. For these classes of devices, you must extract out the “clean” driver package, and incorporate them into the MDT Driver System. IF you don’t, we can’t perform the basic MDT/OSD installation operations on the machine, no network, error 0x0000007b, or the machine won’t even boot.

Non Critical Drivers

There are other drivers that are not critical to the MDT/SCCM installation process, drivers like High End Video Drivers, Audio, Wi-Fi devices. These can be handled later on in the State Restore phase, and can even be installed outside of the MDT driver installation process, You could install them for example as an application. Based on the Make or Model, for example. However, I still like using the MDT Driver system for most driver packages.

Drivers that Play well with others

The MDT driver installation system handles drivers in a system that’s a little chaotic. MDT does not do a detailed job of matching each device with the precise best match driver. Instead, it will copy down all *potential* matches to the local machine, letting the OS sift through the collection and making the correct choice ( See Windows Driver Ranking: ).

Most of the time this is not a problem, and you can leave most drivers in a common pool and everything is OK. There will be occasions where you will need to prune out duplicates, and remove older drivers that have been replaced by newer ones.

One problem we get into is when OEM’s have validated their hardware X *only* against driver version Y, and they won’t test/certify any different (newer) driver packages. Sometimes this is because the OEM just hasn’t gotten around to testing the new drivers, but sometimes it’s because of known driver incompatibilities.
MDT may copy a newer version of the driver to your machine, and the OS will accept the newer package.

However, MDT (Boot) Critical drivers *must* be drivers that play well with others. Especially if you want a single WinPE image that can handle all of your machines, otherwise you may have to create multiple WinPE images per OEM. (At which point I would be very angry at the IHV).

Drivers that do NOT play well with others

We get into real complex scenarios when two OEM’s use a similar hardware device from the same IHV (matching PNP ID’s), but for some reason, the device driver package on one OEM’s web side breaks the other OEM’s device. I have heard some Anecdotal stories about some Intel networking drivers from HP that break Dell machines (or vice versa). It’s possible that two OEM’s have different implementations of the same IHV part number. The IHV may develop “slightly” different drivers for each OEM to get around some design consideration, however it may break the other OEM’s implementation. Now in an ideal world, once the IHV has broken common compatibility between devices, it would make the driver only load for the specific OEM. Removing the common PnP ID PCI\VEN_8086&DEV_0001 and including only the more specific PCI\VEN_8086&DEV_0001&SubSys_12345678.

Typically, to get around this problem many IT Pros will group their drivers by Make and Model. You can program the MDT ZTIDrivers.wsf script to only load drivers from a specific folder in MDT. See:

This is fine for Non Critical Drivers.

Driver Preference

So, when presented with a device, and several sources of drivers, here is what I usually prefer for drivers:
• Use the in-box driver for a device
• Use the version on Windows Update (MDT ZTIWindowsUpdate.wsf script!)
• If it’s a boot critical device (Network and/or storage), get an *.inf version of the driver. (for WinPE)
• Driver is generic and not make or model specific. Use MDT/OSD driver store with an *.inf version of the driver.
• Driver is make and model specific (bad OEM), use selection profiles in MDT to deploy specific versions. [1]
• Driver is installed as an application (bad OEM), develop a custom script to install based on some custom heuristic. [2]

Kudos to OEM’s like Dell (Warren Byle) who has done great work to produce driver *.cab files that can be directly imported into ConfigMgr & MDT.

[1] One of my pet peeves is when OEM’s will use the same hardware across several make/models, but will only certify a specific version of a driver on any given Make or Model. Typically because they are too lazy to test against the latest driver version from the IHV’s. :^p
ConfigMgr/MDT will give all compatible drivers to the OS during installation, so if you must use specific versions, you need to use some custom mapping in MDT (like selection profiles) to accomplish this.

[2] OEM applications are affectionately referred to as Crapplets. And I generally try to avoid them unless required for general device usage.

Flow Chart




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s