Driver Management (Part 2) - MDT 2008
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.
Overview
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.
Process
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
[Default]
StorageDriverSysPrepGroup=MassStorageDrivers
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
[Default]
DRIVERPATHS1=\\SERVERNAME\SHARE\%Model%
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.
Process
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.