How to manage Out-of-Box Drivers with the use of Model Specific Driver Groups in Microsoft Deployment Toolkit 2012 Update 1
Hello. My name is Bill Spears and I am a Premier Field Engineer in the Windows/Platforms group at Microsoft. In today’s blog I will discuss the approach that I use to manage Out-Of-Box drivers within the deployment process of MDT (Microsoft Deployment Toolkit 2012 Update 1).
If you are used to deployments of legacy Operating Systems (such as Windows XP), Out-of-Box driver management sometimes became a very confusing task, and many folks ended up having very long driver paths in their answer files (OEMPnPDriversPath) and ended up having a large folder structure of drivers on each machine that contained drivers for any and all hardware that was to be deployed in that environment and in turn, this was a nightmare to manage. The good news is that managing your Out-of-Box drivers is now much easier and cleaner when deploying Windows 7 via Microsoft Deployment Toolkit 2012 Update 1. Now you can import all of the Out-of-Box drivers that will be needed into your MDT Deployment Workbench, and then those drivers can be injected offline into your install WIM depending on which hardware you are deploying the image to.
Driver injection works as follows: When a machine is booted via the Litetouch media, PNPEnum.exe collects a hardware inventory of the devices in that machine to determine which drivers will need to be injected in to the image before the image is installed on the target machine. By default the inject driver step in the task sequence will query for driver matches in the “All Drivers” Selection Profile. So by default, you could get away with dumping all of your drivers in to the Out-Of-Box Drivers node of MDT and have most deployment scenarios install with the correct driver. In reality, this is a horrible way to approach driver management. The reason I say that is because sometimes you will have multiple drivers that state via their INF file that they will work for a particular device (PNPID), when in reality, that’s not always true. This could be the result of a poorly written driver, or it could be that even though you have a driver that is a match based on the INF, you may need to force the use of a different version of that driver for a particular model of hardware. For Best Practice, it makes more sense to create a folder structure under the Out-of-Box Driver store to better manage how you add drivers to your MDT Workbench. I prefer to create a subfolder for Each Operating System, then each architecture type (x86,x64), then each hardware model, as shown in the screen shot below:
In the screenshot above, notice the folder structure created under the Out-of-Box Drivers Node. Import the drivers for each specific model into the respective folder.
This also makes it easier when it comes time to add updated drivers for existing hardware types, or add a new folder for a new hardware type when you start getting newer model machines. Having this well organized folder structure now also lets you be very granular of what drivers you make available during your deployment by making use of MDT Variables and Rules. Consider the scenario of where PNPEnum.exe detects a piece of hardware with a certain PNPID, but where we have multiple drivers in our Out-of-Box drivers node that claim to be a match for this hardware based on the driver’s INF file information. Without the use of Selection Profiles or DriverGroups, you would not be able to force which driver gets installed. The driver who wins the built in driver ranking process would end up getting installed. By using DriverGroups, you can force the Driver Injection step of the task sequence to only look in a specific folder for its choice of drivers. Therefore you are in control of what specific drivers are available to what specific machines. This is possible by adding Model specific settings to your customsettings.ini file that point to the specific folder containing only drivers for that model based on the %model% variable that we detect during the Gather phase of Litetouch.
Now that we have our drivers imported into our folder structure in the Out-of-Box Drivers node in a manageable folder structure, it’s time to configure the customsettings.ini to add the custom Model sections. This is outlined in the screenshots below:
First, to find the model name of your machine, you could use one of the following methods.
In the screenshot above, notice I’m running the command: wmic computersystem get model to obtain the model name. Alternatively, you could obtain this info via MSinfo32 as shown below:
The screenshot above is a portion of the output from the MSInfo32 command. Notice the System Model name. Next we will configure the customsettings.ini.
Next, add the following to your customsettings.ini (Rule tab of Deployment Share properties)
[HP Notebook 123]
[HP Desktop 234]
[Dell Laptop 345]
[Lenovo Laptop 456]
Notice we are using the Model variable to go to that specific section of the rule file, which then sets the path to only look in the subfolder that you force it to look in. Now you can rest assured that when you run this task sequence on a particular model machine, you know exactly where it will be looking to find the drivers based on what hardware is detected in that machine.
If new drivers become available from the OEM for a particular model, you would simply need to replace the new drivers in the proper folder of your Out-of-Box Drivers node. If you will be deploying this task sequence to a new piece of hardware, you would simply create a new folder in your Out-of-Box Drivers node, then import the new drivers into this folder, then create the necessary subsection for that model in your customsettings.ini (as shown above) and then you will be ready to deploy to the new hardware.
One thing to note about Driver injections is that the driver must have an INF and SYS file in order for us to install the driver this way. If a driver installs via an EXE and there is no way to extract that driver to reveal the actual INF and SYS file, then you would be forced to add that driver EXE package as an application and install it as an application. Note that in that situation, you would need to handle the Network Adapter Drivers and Mass Storage Device drivers differently to ensure that the Operating System could communicate with the storage device and the network adapter in order to complete the install, and then the Vendor’s EXE program could be launched as an application to install the other drivers.
Note that there are multiple approaches to handle Out-of-Box Driver Management with your deployments, and this is just one approach and it is the approach that works best for me. Which method you use will be dependent on what works best for you in your particular situation, as there is not always a one size fits all solution to the design process of building and managing your images. The key benefit I find from using this method is that you know exactly where your drivers are coming from and once you have the framework setup, it’s easy to add updated drivers for existing models, and easy to add new models to your deployments, and most of all, it is very organized.
Another thing to note is that when using this procedure to deploy Lenovo machines, other special considerations may need to be made. This is due to the fact the Lenovo reports back a model string that frequently changes. This is explained further in the following blog which also has a recommended solution for dealing with this scenario:
I hope that this information is helpful for your design strategy of how to manage Out-of-Box drivers.
Premier Field Engineer