The Deployment Guys

Helping to deploy your world automagically...

Driver Management (Part 1) - Configuration Manager

Driver Management (Part 1) - Configuration Manager

  • Comments 64
  • Likes

I am often asked what the best way is to manage drivers with both BDD/MDT and ConfigMgr. With this in mind I thought I would create two blog posts dealing with this topic. The first post (this one) will cover ConfigMgr and the second BDD/MDT driver management.

Please note this is not the only way to manage drivers, there are many different ways to manage drivers. However this is an approach that I have used many times with much success.


Before I get into the details I would like to provide a quick overview of driver management.

The first thing we must understand is the type of drivers that you need to manage. I place drivers into two categories:

  1. NICE Drivers - Drivers that install using an INF file.
  2. BAD Drivers - Drivers that must be "installed" - This could be a Bluetooth driver, finger print reader software or even DVD software that is specific to a particular model type. I also refer to these drivers as "Hardware based applications".

Next we need to understand where drivers are used during the deployment process. There are two areas where they are used:

  1. Host OS - These are drivers that are installed on the Host OS.
  2. Boot images - These are drivers that are required by the ConfigMgr Windows PE boot images to enable OS deployment. The key driver types are network and mass storage drivers.

Finally we need to understand the options ConfigMgr provides for installing drivers. Whenever you import drivers you must add them to a driver package. Once the drivers have been added to a package there are two methods you can use to install the drivers:

  1. Auto apply drivers - Driver packages are primarily for distribution purposes. ConfigMgr performs a PnP scan of the computer and chooses which drivers to install from all available drivers in all available driver packages.  You can filter by driver categories, is tells ConfigMgr to only consider certain categories when choosing drivers.
  2. Apply driver package - All the drivers in the package are injected, whether they are needed or not.

So now that I have covered the basics lets discuss how I manage drivers.


I find the simplest way to describe how I manage drivers is by using an example. The example I will use I perhaps the most common scenario in OS deployment, adding support for a new hardware model.

At a high level the process involves the following steps:

  1. Create a new package that contains all of the required drivers for this hardware type
  2. Add an “Apply driver package” task to the task sequence with a WMI filter based on model type
  3. If required I configure the “Apply driver package” to apply a Mass Storage driver
  4. Create an application for each driver that must be installed
  5. Add all applications to the task sequence with a WMI filter based on model type

I can hear everyone asking the question, why do I use the "Apply driver package" process rather than the "Auto apply drivers" process? Well nice of you to ask, I appreciate the flexibility that the "Auto Apply Drivers" action gives but it does not cover all scenarios. I prefer to use one method of driver installation that will install all drivers (simple is best). The two scenarios that are not covered by "Auto apply drivers" process are:

  1. Devices that aren’t found by a PnP scan such as USB devices, multi level drivers and devices not enabled during deployment (like Bluetooth). 
  2. Mass Storage drivers.  On pre Vista operating systems, boot critical drivers have to be installed with Apply Driver Package.

The second obvious question is what is a WMI filter and why do we use it? You cannot add one “Apply driver package” task to the task sequence that will automatically determine the hardware and install only the package you require (this is what I would like :)). So to get around this issue you need to add an "Apply driver package"  task to the task sequence for each hardware type. You do not want to apply every package to every machine so we need some way of ensuring that each package is installed on the correct hardware type only. Fortunately ConfigMgr has the ability to filter tasks based on a WMI query.

It is also worth noting that if a Mass storage is required for a particular hardware type then ConfigMgr will inject it for you! This was not previously possible with pre Vista operating systems. This is one of my favourite features of ConfigMgr.


So enough of all this talk lets get down to the actual steps required to implement driver management.

Create a driver package (GOOD Drivers)

1.  Gather together all of the good drivers for the new hardware type and place them in a folder.

2.  Open the deployment console and Navigate to Site Database - Computer Management - Operating System Deployment - Drivers

3.  Right click on Drivers and select Import (This will launch the Import new driver wizard)

4.  On the Locate Driver screen select Import all drivers in the following network path (UNC)

5.  Specify a UNC path to your drivers folder in the Source folder field and click Next

6.  On the Driver Details screen ensure all drivers are selected and click Next

7.  On the Add Driver to Packages screen click New Package

8.  On the New Driver Package window update the Package Name filed will an appropriate name (e.g. Toshiba - Tecra M5)

9.  Update the Driver Package Source field with an appropriate location, this will most likely be stored with your other packages. Click Next.

10. If you need to add any network or mass storage drivers to your boot images then perform the following step. On the Add Driver to Boot Images screen select any boot images that require the updated drivers and click Next.

NOTE: You will need to update the boot image distribution points for this change to take effect.

11.  At the Summary Progress and Confirmation screens accept the default settings and Close the wizard.

12. Once you have created your driver package then you should assign it to distribution points at all sites where this hardware type is deployed.

Add driver package to the task sequence

Once we have created the driver package we need to add it to our task sequence.

1.  Create a folder that will contain all of your "Apply Driver Package" tasks. This folder must be added before the Setup windows and ConfigMgr task. When I have a group of similar tasks to add to the task sequence then I create a folder for these tasks. This is shown in the screen shot below.

2.  Add an"Apply Driver Package" task to this folder specifying the driver package that you have created in the previous step. If this model type requires a mass storage driver then select it as shown below.


3.  Next we need to add a WMI condition to this task.  The first thing we need to do is determine the value of the WMI model field for our hardware type. I have found the simplest way to do this is via a WMIC query.

    The following steps detail how to perform a WMI, ensure that these steps are run on the new hardware NOT the server:

      a. Open a Command Prompt

      b. Type WMIC

      c. To determine the Model, type CSProduct Get Name

4. Select the task Options tab

5. Select the Add condition drop down menu and select Query WMI.


6. Add the following text to the WQL Query field where <MODEL> is replaced by the WMI value for your hardware type - SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%<MODEL>%" and click OK

NOTE: For some model types there can numerous variations of the WMI model value. For example the HP D530 or many IBM computers. In these scenarios you can specify part of the value in the <MODEL> field. For example when the WMI value for a HP D530 is "HP D530 [ABC12345]"  then you can specify "HP D530".


Install Hardware based applications (BAD Drivers)

The last part of the driver management puzzle is the BAD Drivers or hardware based applications.

The first thing you need to do is create an application in ConfigMgr that will install the application. I will not provide step by step guidance on this process but it is important that the following two settings are enabled:

1.  The program must be set to run "Whether or not a user is logged on"

2.  The option "Allow this program to be installed from the Install Software task sequence without being advertised" must be enabled

Once you have created the application you need to add it to our task sequence.

1.  Create a folder that will contain all of your "Application Installation" tasks. This folder must be added after the Setup windows and ConfigMgr task. I usually call this folder "Hardware Based Applications".

2.  Create a folder within the folder you created in the previous step. This folder should be named after the hardware type (e.g. Toshiba - Tecra M5).

NOTE: When installing hardware based applications I create a folder for each hardware type that contains all of the applications for that hardware type. I then apply the WMI conditions to the folder, NOT the application.


4.  Next we need to add a WMI condition to this folder.

5.  Select the task Options tab

6.  Select the Add condition drop down menu and select Query WMI.

7.  Add the following text to the WQL Query field replacing <MODEL> with the WMI value for your hardware type - SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%<MODEL>%" and click OK

8.  Add an"Install Software" task to this folder specifying the application that you have created in the previous step.

9. Repeat this process for all hardware based applications!


So that's how I manage drivers .... simple :)

For more information no driver management please refer to the ConfigMgr online documentation library.

Driver Management (Part 2) - Manageing drivers with MDT 2008 can be found here.

This post was contributed by Ben Hunter a Consultant with Microsoft Services New Zealand.

  • Hi Ben

    Thanks for an exilent post, looking forward to the WD part.



  • Ben put together a really nice artice on driver management in MDT and ConfigMgr. File this one away!

  • Do you recommend using the "Apply Driver Package" in conjunction with "Auto Apply Drivers" ?

    I've tried to use it after the "Auto Apply Drivers" Step to install the more "Problematic" Drivers which the previous step didn't recognized (Like Nvidia's 6100 Driver instead of MS's Nvidia 6100 WDDM Driver) but with no luck, The MS Driver allways took over ispite the fact that nvidia's driver were Newer\Better

  • In this case I would recommend installing the Nividia driver using an application.

    If the installer is an installshield installer, create a custom install file that suppresses the reboot.

    Record an answer file first by extracting the source package to a folder (mine is extracted to C:\NVIDIA\WinVista\169.25)

    Then run setup and record an .iss file with all the options required.:

    C:\NVIDIA\WinVista\169.25setup.exe -r -f1C:\NVIDIA\WinVista\169.25\nvidiasilentsetup.iss

    You can silently install every time thereafter with:

    C:\NVIDIA\WinVista\169.25setup.exe -s -f1C:\NVIDIA\WinVista\169.25\nvidiasilentsetup.iss

    An .iss file example follows, at the end you should note the BootOption (0 means no reboot):

    [InstallShield Silent]


    File=Response File

    [File Transfer]













  • Ben, when you say 'injected' as for the apply driver package, do you mean unused drivers are actually statically in the driver store? Or is this only for the pnp scan and once the OS is installed these are not found on the Host?


  • Hi CCA,

    By injected I mean that the drivers are in the driver store. This means they are available when a device is plugged in later.



  • Ben we have been using almost the same concept however we created a Vista X86 driver package and Vista X64 Driver package.  The reason for this is we are maintaining drivers for about 8 different Dell models that share a lot of the same drivers.  For example if I add the Dell Optiplex 755 Drivers this will also use the same chipset drivers as several other Dell workstation models.  The problem here is SCCM lets you add the drivers to the repository once and if you accidently add them again it errors out.  The only reason why we would add them again is it is much easier to create a packge and point it to a folder with all the appropriate drivers for a certain model rather then hunt and peck looking for the drivers from the repository.

    This also has it down-falls.  Since everything is associated to 2 groups X86 and X64 it may cuase issues by Vista selecting a wrong driver however this has not happend yet.  You are also injecting a lot of drivers not needed for that model.  So here is an example of what I am referring to, when adding drivers for a computer that may allready have them in the repository you get the errors indicating it allready exists.  Well this is a real pain in the ass if I have to go and manually add every single chipset driver that may be needed for a certain model.  Maybe chipset makes sense to create a seperate category or even use application packages for these?

    I would like to follow your method however I was curious how you deal with drivers that are the same driver across muliple models?


    Error: Some driver(s) can not be imported successfully. Please see following details.

  • Hi Bzwart,

    You are correct. If the driver has already been imported then you will need to manually add it to the driver package. This can be a hassle, but at least you only have to do it once for each model type.



  • Hi Ben,

    Looking forward to your post on this process with MDT/BDD!



  • Ben,

    What is the suggestion for installing Common Windows XP update modules (ex. Q889816, Q909667) or the Universal Audio Arch drivers?

    This is an element of my task sequence that I need to cleanup a bit before I roll MDT out.  I appreciate your feedback.

    Thanks man!


  • Hi Rich,

    I like to include these patches in the base im age.

    I just create another application to install them.

    That way I don't have to worry about installing them for every client that requires them.



  • Hi Ben,

    Sounds like I should be bringing down my captured WinXPSP2 Image and adding these updates such as the UAA High Def Audio class driver to my gold image, then recapture, and redistribute to MDT?

    I was sort of confused with what you were trying to get at when you say you create another application to install them.  

    Thanks brotha!


  • Hi Rich,

    I like to create an application for each task that I perform when creatig an image.

    So what I would do here is create an application with source files. The source files would be the patches. I would then write a vbscript that installs these patches. The command line for ths application would then run the vbscript.

    I then add the application to the task sequence.



  • Ben,

    I understand now what you meant earlier in relation to writing a script to execute the install of the patches.  I bring my XP gold image down every 3 months to update the capture with security updates.  At that time, I see if there is anything else that I could add to the image, such as hotfixes, and the items mentioned above.  

    Is there anything wrong with doing it this way, opposed to adding them in via task sequence?  


  • Ben,

    I've had an issue with installing a video driver for an HP 8510W w/ MDT.  For some reason the driver does not want to inject.  The driver is an Nvidia v156.31 (sp36726.exe) from HP's website.  If I had install the driver it loads just fine.  

    I'd rather not have to add this driver and install as I do the rest of my "bad" drivers.  Is there any other way around this using MDT?



Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment