ConfigMgr 101: Driver Management

I have worked on many OSD projects in the past and remember the pain of setting up the required drivers. It wasn’t until recently however that I remembered how painful this process can be when I started setting up a customers images again.

First of all I want to start by discussing drivers. You all know what a driver is and what a driver does. They generally come in a couple of forms either the raw INF file or a setup with the drivers embedded in a setup.

Secondly, let’s think about how you manage drivers in ConfigMgr. We can point the import wizard at a UNC path and simply import the INF or OEM files from that path and sub folders. This makes drivers which are simply delivered in this format nice and easy to work with. In the OSD world I like to call these nice drivers!

The second types of drivers which are bundled into setup files I like to call bad drivers, these are the ones which are often a nightmare to get installed and sometimes we even have to run the vendor setup to get the drivers to work. These are not nice to work with and we have to spend time looking at how the setup works and how we get it silently installed, just like working with applications.

Collecting Drivers

Before looking at ConfigMgr I just want to step outside of that environment for a minute. When I am getting drivers ready to import into ConfigMgr I like the process to be as simple as possible with the minimum amount of drivers required. The basic reason for this is to keep my library tidy and neat.

For example, my current customer runs Intel based OEM hardware from a supplier. The network card drivers which Intel provide for the card in these machines actually contains around 60 drivers, this practice of importing all of these drivers is madness, you will quickly end up with your driver library getting out of control and also using up storage when these drivers may never get used.

I usually start with getting a model of each hardware I am building, installing my target operating system and the vendor provided drivers. From here I know that in Device Manager all my hardware is correctly installed and has the correct driver.

My final step in this process is to use an application called Driver Magician which is priced at $29.95. It is a great little buy, when you install Driver Magician you then have the ability to export all non-Microsoft drivers to say a USB stick. This folder structure requires and special characters removing first. Once this is done you can copy to your master driver location and then import into ConfigMgr and apply the appropriate labels.

Using my example above today I reduced the set of drivers from a possible 159 to simply 7. Yes revisions may require different drivers but you can deal with these in the same way. I just simply don’t see the point in storing hundreds of drivers which may never be used by any target hardware in my estate.

Management Within ConfigMgr

Now into ConfigMgr. I like to store my source folders in a simple hierarchy, as follows… <Drive>:\OSD\Drivers\<Model>\<Driver Type>. If I am using Driver Magician then this can still apply as <Driver Type> can also be the exported name of the driver.

Once I have everything ordered correctly I can then import the drivers into ConfigMgr and use categories to then say these drivers are for a specific model and even a specific type of hardware, say sound card or video card for example. This allows me to easily view all my drivers for a specific model of hardware without looking in the Driver Package (more on this soon). This also allows me to mass select a list of drivers and add them to a specific Driver Package.

Driver Packages

When in the task sequence we have a couple of ways of applying drivers. The first is using the Auto Apply Drivers task sequence step. This step runs a plug and play enumeration on the device and matches up the PnP ID of the device with a driver from the driver library, you have a few options here to either limit selection to specific categories and also to consider best matching drivers.

The other option is to use the Apply Driver Package task sequence step. Using this step all the drivers in the package are applied to the driver store on the Windows installation. I can use the task sequence variable Model to only apply this package to certain hardware models or use a WMI query against Win32_ComputerSystem for ‘LIKE’ statements for instance which handles hardware revisions.

I prefer using driver packages simply because I know all the drivers will be locally applied. I don’t need to worry about the device been plugged in for the driver to be picked up, this generally isn’t a problem unless you have external hardware but later down the line should you plug something external which you have a driver in the local driver store then it will simply apply the driver rather than asking for credentials to install the device.

Summary

The summary I think here is keep it simple, it should not be difficult, keep it clean and concise. Also use external tools like Driver Magician to keep your driver set limited if possible. It will improve the speed of your build the less you apply, only send down what is required.