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)
[Settings]
Priority=Model,Default
[Default]
[HP Notebook 123]
DriverGroup001=Windows 7\x64\%model%
DriverSelectionProfile=nothing
[HP Desktop 234]
DriverGroup002=Windows 7\x64\%model%
DriverSelectionProfile=nothing
[Dell Laptop 345]
DriverGroup003=Windows 7\x64\%model%
DriverSelectionProfile=nothing
[Lenovo Laptop 456]
DriverGroup004=Windows 7\x64\%model%
DriverSelectionProfile=nothing
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:
https://blogs.technet.com/b/mniehaus/archive/2009/07/17/querying-the-mdt-database-using-a-custom-model.aspx
I hope that this information is helpful for your design strategy of how to manage Out-of-Box drivers.
Bill Spears
Microsoft Corporation
Premier Field Engineer
Comments
- Anonymous
August 17, 2013
muito bom esse site, porem para ajudar gostaria que divulgassem esse www.baixedrivers.com - Anonymous
August 20, 2013
Hello,I'm working with MDT 2012 Update 1, i have the correct driver (if i install server manual and use that driver it works) if i import the driver into MDT, i can see it being injected but the deployment fails because the driver is not being installed before booting into the OS (windows 2008 R2 Web)What can i do to debug this issue?Kind regards,Jay - Anonymous
November 06, 2013
hang on, you declare Model,Default priority but you don't define [Model]. How come? - Anonymous
November 07, 2013
Same question,[Settings]Priority=Model,DefaultBut never to be used under[Default] - Anonymous
November 11, 2013
Hello,Thanks a lot for your post.I would like to ask, in the customsettings.ini, where you say/write: "DriverGroup001=Windows 7x64%model%"the "DriverGroup00x" refer to the Windows Deployment Services (WDS)-servers-[server name]-drivers?I'm confused cause when you right click on Drivers you have the option to Add Driver Group.So, do you mean this Driver group or should I write the customsettings.ini as you did? - Anonymous
November 20, 2013
Actually, in reality this method produces nothing of a use.As I mentioned before, you declare Model but don't define it.If the driver structure is slightly different from your example - this quickly becomes just a useless bunch of text. - Anonymous
December 16, 2013
Without [model] it skips the [default], had to add [model] - Anonymous
April 27, 2014
The comment has been removed- Anonymous
March 30, 2016
Thanks! This really helped.
- Anonymous
- Anonymous
July 01, 2014
What if you have for eg. [HP Notebook 123] in Windows 7 and in Windowns 8 Folder with different Drivers??? - Anonymous
October 29, 2014
phils got it right, this quickly becomes useless if you have win7 + win8 drivers for the same model - Anonymous
November 25, 2014
No, you would just organize your folders by OS->Manufacturer->Model. For example:
Windows 7
HP
Notebook 123
Windows 8
HP
Notebook 123
Then you have a Win7 TS and a Win8 TS, and the DriverGroup is just OS%Make%%Model% - Anonymous
November 26, 2014
We are using Symantec Ghost based images deployed with Managesoft. I was wondering if there is a way to use the driver injection with this setup. I don't have an install.wim in the ghost image, I would have to start all over again.
Thanks,
John - Anonymous
March 13, 2015
I was trying to design multiple drivergroups, where drivergroup001 would be your MakeModel path, and Drivergroup002 would be common files that all models would need, an then load the drivers from both using one Inject drivers (selection profile = nothing) task. But it doesnt seem to be working. I get the MakeModel group, but not the common.
Does that sound like something that should work? I dont know if I have an error somewhere, or if this just doesnt work. - Anonymous
April 15, 2015
This is a great article but you can step it up one better with Total Control like in this article. I use the other model mentioned in the article because I am operating with more than one Task Sequence to install different Windows versions. This allows me to incorporate the task sequence variable to search in a specific set of drivers for the correct OS.http://deploymentresearch.com/Research/Post/325/MDT-2013-Lite-Touch-Driver-Management. Just make sure the "wmic computersystem get model" matches the name of the folder. - Anonymous
July 20, 2015
How do the driver groups work? In my CS.ini, all I have is DriverGroup001. Under what circumstances are DriverGroup002, and so on, necessary? Thanks - Anonymous
September 11, 2015
The comment has been removed - Anonymous
September 17, 2015
Bill,
I am having an issue getting the drivers setup. I notice that the drivers are injected and copied into the store but not installed. I looked at the ZTIDrivers log and saw that. Any ideas of what is happening - Anonymous
November 24, 2015
The comment has been removed- Anonymous
March 06, 2016
HEllo All , Well I think the instructions are great , for the first part ! but then lack any real instructions on how to get to the Customsettings.ini (easily found) and what it does at what steps and what can go wrong..I'm with Shawn at the moment , but will work it out, its on me has Im sure ive done something wrong somewhere..LOL
- Anonymous
- Anonymous
November 29, 2015
Fantastic, it solved all our deployment problems over here! Thanks! - Anonymous
May 04, 2016
The comment has been removed - Anonymous
May 26, 2016
I know this is old, but I am using the task sequence during the image deployment to set that variable for the installation. The questions I have are when Lenovo make a machine the system name may change - For example one P500 system name is 30A7000TUS and the other is 30A7002WUS - When I check the Lenovo site for the driver pack it is the same for all P500's, so I need to have two folders with duplicate drivers for imaging? Also, can you explain the function of multiple driver groups, why is needed? If you call drivergroup001 - for each what does it matter as it matches on the system model name so DriverGroup001=Windows 7\x64%model% but your folder in MDT do not match a model name as shown in your screen shot. Lastly, In your screen shot your drivers will not match as the driver name has to match the system name - Anonymous
August 26, 2016
Hi Bill,Really this is help full to me thanks for your effort and do we need to add any task sequence variable in the task sequence properties (editing inject drivers and giving drivers path in that variable) what is the drivergroup? do we need to create any folder in mdt or can we give it directly in the customsetting.ini file as you mentioned above?-Thanks in advance - Anonymous
April 26, 2017
Hi, Long shot but do you know if there is a way to be able to manually select a driver profile after you have selected what OS image to install?I already have a step after selecting the OS to ask for the computers name which is very handy.