Chris Nackers Blog

ConfigMgr and MDT Deployment Solutions

Useful Blogs

User Groups

Configuration Manager 2007 R2/SP2 Driver Management

The post will cover the most common methods that I know of for driver management in ConfigMgr.  For once I won’t be talking about MDT integration!

Auto-Apply Drivers

Auto-Apply consists of importing all your drivers into ConfigMgr and then utilizing the “Auto-Apply Drivers” step in a Task Sequence, this step will match PNP ids and inject the drivers that match the detected ID’s.  You can limit selections by utilizing “Categories” or you can simply just let it have free reign on your driver database.  The only step i’ve had to work with on this TS step is the “Install only the best matched compatible drivers” vs “Install all compatible drivers.”  I had a few models that wouldn’t install all drivers unless I used “Install all compatible drivers.”  The biggest problem with this method is that it will grab the newest compatible driver, so if you just imported the latest greatest for a new model you have, many of those drivers will work for older models and will be used for those models even if you don’t want them to be.

Pros:

1) Quick, easy

2) Don’t have to know what specific drivers you need, provided there is a matching driver, your device will be installed correctly, that works great for some people

3) Matches drivers based upon PNP

Cons:

1) Sub-devices can be missed sometimes

2) No control over what drivers are being put where, you have some control with “Categories”, but not the degree of control some people like, it will grab the newest/greatest driver it can find that matches your device

3) Matches drivers based upon PNP :)

Step in the TS this method focus’s around:

image

Other main focus points you will want to be concerned with:

image

Using Driver Packages

This is commonly known as the “control freak” method.  When using this method you typically want to control the specific drivers going to each model.  Usually this is driven by a Task Sequence step with a WMI query to match up the Model.  The major issue with this is that ConfigMgr won’t let you import duplicate drivers, and if you are using common manufactures, 50-80% of your drivers could be same for every model.  So what you end up doing is creating driver packages in ConfigMgr, but not actually importing the drivers, you instead put the in the driver package source files and then distribute those to the Distribution Points, thus allowing you full control over what drivers are in the package.  This leads to a bit more maintenance since you have to work with the drivers from a folder perspective and you mostly maintain them outside of ConfigMgr.  You would still import NIC and Mass Storage drivers (for XP) as you would need those imported ideally to inject them into your boot images, although you could inject them into the wim yourself if you really wanted to.  This method works great when you have to be concerned with certain versions of drivers going to certain models, a great example for us is we need our video drivers to be Certified by Solidworks, to get support, we need to ensure the machines are using a correct Certified driver.  The problem with the new unified drivers is that the newest version that i need for my new laptop also happens to work for my 2 year old workstation class machine, however that newest driver isn’t Solidworks Certified.  Again the theme of this method is control.

This is the method i have personally used up to this point, I now use the 3rd method which i’ll talk about in a bit. 

Pros:

1) Complete control over what is going where

2) Control! x2

3) Injects all drivers in that package, anything in that package is available to the OS

Cons:

1) Can’t easily import duplicate drivers

2) More administrative overheard

3) Not typically managing most of the drivers from with ConfigMgr

4) You will have the same drivers in multiple packages, taking up more space, possible concern for some

 

Hybrid of Auto-Apply and Driver Packages

After reading this post by Keith Garner, I got to thinking about how I could do something similar in ConfigMgr.  When i really sat down to think about it, the only drivers that really mattered to us was controlling the video drivers.  So I decided, why couldn’t i do PNP for everything but the video drivers.  Even more on that, unless it’s a machine running Solidworks, i really don’t care what video drivers are installed.  So I basically ended up with this structure:

-Common Drivers (Will use PNP)

-Common Video Drivers (Will use PNP)

-Specific Video Drivers (one package for each model requiring a specific video driver)

I imported all my common drivers into ConfigMgr, imported all my video drivers, then seperated them out into common drivers and the specific drivers.  I then created all the driver packages i needed for each model that required a specific video driver and added the required driver to the package.  I made use of “Categories” to control what was being used for PNP detection.

Pros:

1) Advantages of PNP detection along with the control over drivers by using driver packages when needed

Cons:

2) Takes a little configuration and setup

The first section in my Driver Management part of my Task Sequence is for Windows XP Mass Storage drivers, I do a WMI query for the deviceID and then inject the appropriate MSD, this allows me to not have MSD in my other packages and I can have a single driver package for all MSD’s and then just inject when appropriate. 

image

image

image

Next, I do a Auto Apply driver step that injects all my Common Drivers, I have these all under a Category called “Common”, this would be audio, modem, card readers, anything that isn’t a video/display device.

image

image

Next I have a section for Video Drivers, the driver(s) I want to control in my case.  First we inject any Common Video Drivers for models I don’t care about. Just get the best video driver available installed for me.

image

image

This is driven by a WMI Model query on the backend for all the models I don’t care about, notice I use “LIKE” statements to get around HP’s funky part #’s:

image

Next we get into the specific models that I want to inject specific video drivers:

image

Here we are using a Driver Package for each TS step with a WMI query on the backend, this Driver Package contains the Certified driver that I need for that model:

image

image

That’s it! That is how i now manage my drivers, I feel this to be the most effective method for our environment.

Hope this helps or inspires someone else.

-Chris

Comments

TrackBack said:

# April 29, 2010 6:18 PM