The Deployment Guys

Helping to deploy your world automagically...

Driver Management (Part 2) - MDT 2008

Driver Management (Part 2) - MDT 2008

  • Comments 92
  • 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 covered ConfigMgr and the second (this post) 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 MDT Windows PE boot images to enable OS deployment. The key driver types required are network and mass storage drivers.

Finally we need to understand the options MDT 2008 provides for installing drivers:

1. Out-of-Box Drivers - Drivers are imported into the Deployment Workbench. During OS deployment MDT performs a PnP scan of the computer and chooses which drivers to install from all available drivers.  You can filter drivers using groups. These tell MDT to only consider certain drivers when deploying an OS.

2. DRIVERPATHS - This is an option that is specified in the MDT deployment point rules. It specifies a path to a folder containing all of the drivers you would like to deploy to the computer. During OS deployment all files within that path are copied to the computer. No PnP scan is performed on the drivers contained in the folder.

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


I do not use out-of-box drivers to install "NICE" drivers on clients, I use the DRIVERPATHS method. I like the way that driver groups work but there is one scenario that driver groups does not cover. Devices that aren’t found by a PnP scan such as USB devices, multi level drivers and devices not enabled during deployment (like Bluetooth) will not be installed using the Out-of-Box installation method. You could use a combination of these methods to deploy drivers but I prefer to use one method that covers all drivers.

However I do use Out-of-Box drivers (with driver groups) to manage two key areas:

1. Drivers that must be added to Windows PE boot images (Network and Mass storage drivers) - MDT will dynamically inject these drivers into your Windows PE boot images.

2. Mass storage drivers that will be injected during image creation - MDT will dynamically inject mass storage drivers into client during image creation.

I create an application for each of the "BAD" drivers. These applications are then assigned with the correct hardware type using MDT database or deployment point rules. This allows me to selectively install the applications based on hardware type.

So now that you know how I manage drivers lets look at how I configure MDT to support this process.

Supporting infrastructure

The following steps must be followed to prepare the MDT infrastructure for driver management:

1. Create and a share folder on the deployment server. This folder will contain the drivers for each hardware type. I usually create a folder called models and share it as models$.

2. Create a driver group for mass storage drivers - I call this group "MassStorageDrivers"

3. Update the deployment point rules to assign the driver group to the StorageDriverSysPrepGroup property



    Note - All mass storage drivers in this group will be injected into the computer before running sysprep, so the drivers can be picked up after reboot. This can only be used when creating an image.

4. Create a driver group for Windows PE images - I call this group "WinPE"

5. Assign the Window PE driver group in the Windows PE tab of the Deployment Point.


    Note - This ensures that only drivers in this group are injected into the Windows PE boot image. This option is not available in LAB distribution points. It is important to note that LAB deployment points should only be used for creating images not deploying images.

5. Create a driver group that contains no drivers - I call this group "NoDrivers"

6. Ensure that the "NoDrivers" driver group is the only one selected in the driver groups tab of the Deployment Point.


    Note - This will ensure that only drivers that are specified using the DRIVERPATHS property are installed.

6. Update the deployment point rules to specify the DRIVERPATHS property



   Note - %Model% will be replaced by the WMI value gather during the MDT deployment process. All drivers for each hardware type will be stored in a folder corresponding to this value.

Now that we have prepared MDT for driver management lets look at how these settings are used.


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

The process involves the following steps:

1. Create a folder for the new hardware type in the models folder. The models folder name must match the model value returned by WMI. I have found the simplest way to determine this value 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

2. Gather together all of the required "GOOD" drivers for this hardware type and place them in the new folder. I usually create a sub folder for each driver type. For example "Model\NIC" or "Model\Audio"

3. Create an MDT application for each "BAD" driver that must be installed

4. Associate the applications with the model using the MDT database or rules

5. If Required - Import mass storage drivers into the deployment workbench. Add these drivers to the "MassStorageDrivers" group during the import process.

6. If Required - Import network/mass storage drivers required for Windows PE. Add these drivers to the "WinPE" group during the import process.

    Note - The version of Windows PE used by MDT is based on Windows Vista. This means that you must to import Vista drivers to support Windows PE.

7. Update the deployment point.

    Note - If you have multiple deployment points then ensure that they are all updated.

8. Update any Windows PE boot images on WDS servers or DVD/CD media


Mass Storage drivers can be particularly troublesome to manage when deploying Windows XP and Windows 2003. The most recent release of MDT (March 2008) now includes support for injecting mass storage drivers  before running sysprep, so the drivers can be picked up after reboot. This is a great new feature of MDT but it can only be used when creating an image. MDT CAN NOT inject drivers into an image that has already been syspreped.

So what does this really mean? If you have a new hardware type that requires a mass storage driver not currently supported by your image then you will need to recreate your image :(.

Note - ConfigMgr can inject drivers into an existing image.

Note - MDT will inject Vista and Windows 2008 mass storage drivers


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


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

  • Ben,

    This has been long awaited by my part.  Thanks for taking the time to post this.  Just a few questions.

    1) Regarding the WMIC - CSProduct Get Name command.  I ran this on my laptop for example, and here is what I got: 1951WBF.

    Are you suggesting to name the driver folder something like this: Models$\1951WBF ?

    2) Regarding the customsettings.ini - DriversPaths1.  Do I need to have a separate entry for each model?  For example,


    DriversPaths2=\\server\models$\Power Edge 2600

    3) Associate the applications with the model using the MDT deployment rules.  Can you explain this further?  Let's say I already have all of my applications configured in MDT.  Right now I have them added in the Task Sequence to install as an application.  Is this necessary or can I use customsettings.ini to point to the source directory of the application install files?  Can you explain this further.

    Great stuff.  This has been very useful.  


  • Ben, as always, you rock!  I'm going to give this a shot right now.

  • I am often asked what the best way is to manage drivers with both BDD/MDT and ConfigMgr. With this in

  • Hello,

    thanks for this deployment tip. I try now since a long time to deploy Windows XP SP2 with BDD. I have a HP notebook with a Intel SATA storage adapter. I add the Intel Matrix driver to the out-of-the-box driver, but the install fail every time. I can't find the mistake.

    I'm tankfull for an idea



  • Tobias,

    Have you checked the log files to find out why it is failing?  You'll probably find the reason there.

    Look for the bdd.log (amongst others) in the MININT directory.



  • Ben - I'm using VPC (and tried VMWare Wksn 6) as well to boot of the LiteTouch.iso to connect to the MDT 2008.  PE starts fine and sees the network (had to add the AMD driver for VMWare) but both VPC and VM cannot see te C: drive.  Any ideas?  VM is set for IDE and VPC is set as is.  The virtual drives are preset to 8gb.

  • Hi Rich,

    It looks like you have an IBM machine. This is how they define their model types. So yes I am suggesting that you use this folder name. I usually include a text file in the folder that identifies the smodel type with the real product name.

    You do not need to create seperate driver paths entries. This is taken tare of automagically by the %model% part of the path.


    For further information on how to assiociate applications with the model type please have a look at one of my old  blog posts:



  • Hi Tobias,

    Are you adding injecting the driver when you create the image?

    Did you add the driver to the group specified by StorageDriverSysPrepGroup?



  • Hi jparekh73,

    I don't have too much experience with VMware workstation.

    You will need to integrate the mass storage drivers for VMware into yuor boot image and the OS install process.

    I would suggest that you post the question on myitforum.



  • Hi Ben,

    Ok, got it now.  A question regarding the rules processing for the hardware based applications.  If I set this up according to your post, do I still need to add the applications to my task sequence?  I guess I'm not seeing the real benefit of the rule processing in this scenario.  

    In my environment I have setup the "BAD" drivers to install as applications and I tag those in to the State Restore phase in my Task Sequence.  

    Just looking for some clarification.  



  • Hey guys,

    I'm running into a snag with this.  I can PXE boot fine, go through the LTI setup, and it begins running the task sequence.  Once it gets to Installing Operating System, it sits for about 30 seconds and errors out with 32 errors.  The errors repeatedly cannot find the deployment server, and the final one at the bottom states that it cannot find it because there is no network device on the machine.  I'm able to authenticate when first starting the LTI setup but once it gets here it fails.  I've added the available NIC drivers for this computer (Dell Latitude D610) to the WinPE image but still nothing.  Let me know if you need to exact error message or if this is enough.  As always, appreciate your help guys!

  • Hi Mwest,

    There are two things you need too do.

    1. CAn you open the command box in the bottom left hand corner and run ipconfig. Does this return an IP address? If it doesn't then you will need to find the correct Vista drivers for the 610. I think the 610 uses a broadcom B57 nic.

    2. Make sure that you delete the MININT and _SMSTaskSequence folders between tests. If these exists then "WEIRD" things will happen :).



  • Hi Rich,

    You do not need to add applications to the task sequence. It will dynamically install the applications using the "Install applications" task in the state restore phase.



  • Hi Ben,

    What if they're not silent installs?  Just want to make sure this doesn't mess anything up.

    As it is now, for the non silent installs, my techs have to intervene for a few app installs during state restore.  

    Would this behave the same as it does now?


  • Hi Ben,

    I loved the out-of-the-box drivers in BDD for the good drivers. I created a driver group for each model in my environment and selected the correct driver group in the properties of each build. Now I want to upgrade to MDT wich has a lot of improvements but they removed this function.

    Is there a way or a script from the old BDD builds that I can use so I could select a driver group for a Task sequence just like you could select the Install Operating system.



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