• Home  / 
  • Research
  •  /  MDT 2013 Lite Touch Driver Management

MDT 2013 Lite Touch Driver Management

In MDT 2013 (Lite Touch), there are two types of drivers to worry about when deploying Windows. There are drivers for Windows PE 5.0 (the boot image) and there are drivers for the Windows Operating System that you deploy.

Driver management for the boot image is pretty straight , but driver management for the Operating Systems that you deploy is more complex. The real answer is it depends. To simplify I have broken down drivers for the Windows Operating system in to three core scenarios (see later in this post). But first, let's start with the boot image drivers.

 

Drivers for Windows PE (the boot image)

The boot image you use for deployment is based on Windows PE 5.0 (a subset of the Windows 8.1 operating system). For the boot image you need at Nic and Storage drivers at minimum, but sometimes you need to add other drivers as well (such as mouse drivers for remote cards like ILO etc.)

The good thing about Windows PE 5.0 is that it supports the same hardware as Windows 8.1, so if you are lucky you don't need to add any drivers at all to it. But in this article you find guidance if you need to add any driver. You also need to set the scratchspace in Windows PE to increase the temporary storage that is used when the Windows setup engine is injecting drivers.

To be successful with boot image drivers in MDT 2013 Lite Touch I recommend that you do the following

  • Create two folders in Out-Of-Box drivers, name the folders WinPE 5.0 x86 and WinPE 5.0 x64.
  • Import any needed x86 drivers into the WinPE 5.0 x86 folder, and any needed x64 drivers into the WinPE 5.0 x64 folder.

    Note:  You should only use Windows 8.1 drivers for the boot images, even if you plan to deploy Windows 7 SP1 with MDT 2013 Lite Touch.

    DriversInWinPE
    WinPE drivers imported.

  • Create two selection profiles, one named WinPE 5.0 x86 (where you select the WinPE 5.0 x86 folder in Out-Of-Box drivers), and one named WinPE 5.0 x64 (where you select the WinPE 5.0 x64 folder in Out-Of-Box drivers.
  • Then configure the deployment share properties to use the correct selection profile. In the Windows PE x86 Components tab, in the Driver Injection area, select the WinPE x86 selection profile. Do the same for Windows PE x64 Components tab, but select the WinPE x64 selection profile.
  • Also in the deployment share properties, in the Windows PE x86 Settings tab, in the Lite Touch Boot Image Settings area, set the Scratch space size to 128, do the same in the Windows PE x64 Settings tab.

    DSProperties
    Deployment Share configured to use the WinPE 5.0 x64 selection profile.

 

Drivers for Windows Operating systems

To simplify things I recommend starting with one of three core scenarios when configuring drivers for MDT 2013 Lite Touch. The three scenarios are based on the size of the company, the number of operating systems being deployed, the level of control desired, and the number of hardware models.

Scenario #1 –  Total Chaos

This scenario has the following assumptions. This is for a small company, they are only deploying one operating system, say Windows 8.1 x64, and they have a few hardware models from the same vendor. The key things here are that they are deploying just one family of operating systems and that the hardware is from the same vendor. The reason is that the larger vendors do test compatibility among their own models per operating system family, so it's quite rare that a driver from one model will interfere with another driver.

Solution

For this scenario I recommend that you stick with the default simple PnP ID detection based method for drivers. Shorthand story is, just download and extract the drivers for each model to a folder, and import that folder into the Deployment Workbench.

AddedPred¨
Deployment Workbench with drivers imported for Scenario #1

 

Scenario #2 – Added Predictability

This scenario has the following assumptions. This is a small or midsize company, they are deploying multiple operating systems, say Windows 7 SP1 x64 and Windows 8.1 x64, and they have a few more hardware models but still from the same vendor. The major difference from the first scenario is that are deploying multiple operating systems. Since the default method is using PnP ID detection among all imported drivers we need to have a way of filtering the drivers so that only Windows 7 drivers are considered for Windows 7 SP1 deployments, and that only Windows 8.1 drivers are considered for Windows 8.1 deployments. The feature in MDT 2013 that we can use for this filtering is called Selection Profiles.

Solution

For this scenario I recommend that you use the default PnP ID detection based method with the addition of using selection profiles as a filter for the drivers. The configuration in MDT 2013 is that you first create two folders inside Out-of-box drivers, named Windows 7 x64 and Windows 8.1 x64. Then you import the drivers the correct folder in the Deployment Workbench.

After importing the drivers, you create a selection profile created for each operating system driver folder, and then configure the Inject Drivers action in the Task Sequence to use the correct selection profile.

CreateWin81SelectionProfile
Creating the Windows 8.1 x64 selection profile.

win81SelectionProfileIntS
Configuring the Inject Drivers action to use a selection profile.

 

Scenario #3 – Total Control

This scenario has the following assumptions. This is a small, medium or larger company, they are deploying multiple operating systems, say Windows 7 SP1 and Windows 8.1, they have many hardware models, and from multiple vendors. The major difference from the second scenario is that they are using hardware from multiple vendors, and the fact that they want more granular control of their drivers.

Note: This method is my personal favorite, because even if it takes some extra time to setup, I get complete control of the driver injection process.

Anyway, since there are multiple vendors involved, the testing and compatibility matrix between each model cannot be guaranteed if you base detection on PnP only. You need to be able to filter not only on operating system but also on a per model basis. Even though you technically could use selection profiles for this as well, this is not what they were designed for. There is another feature called DriverGroup that will help you do some more advanced filtering.

Solution

For this scenario I recommend that you don't use the default PnP ID detection based method, but instead use DriverGroup as a filter for the drivers. The configuration in MDT 2013 is that you first create two folders inside Out-of-box drivers, for example named Windows 7 x64 and Windows 8.1 x64. Then you create subfolders for each model you have. Then you download and extract the drivers for each model, and per operating system. Then import each per operating system folder and per model into the correct folder in the Deployment Workbench.

Please note that selection profiles and driver groups work together meaning if I have a selection profile including driver A, and a driver group including driver B, both drivers will be added. Most times you only want one or the other but they can be combined. When using drivers per model I recommend you to use the selection profile named Nothing for the Inject Drivers action. The real trick for this scenario is to name the driver folders according to the name of the model, then you can set the DriverGroup001 variable to %Model% in either the Task Sequence or in the rules.

Also, to avoid having issues with drivers not detected by plug and play within the folder (DriverGroup), I recommend forcing driver injection by changing the Inject Drivers action property to "Install all drivers from the selection profile". The property is a bit misleading, because it's also valid for driver groups, but the label does not really say that  🙂

TotalControl001
Create the driver folder structure in Deployment Workbench.

TotalControl002
Add the Set Task Sequence Variable action with DriverGroup001 set to Windows 8.1 x64%Model%.

TotalControl003
Configure the Inject Drivers Action to use the "Nothing" selection profile.

About the author

Johan Arwidmark

83
Leave a Reply

avatar
71 Comment threads
12 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
25 Comment authors
SamAllyn JacobsJulien CoudertstomsJohan Arwidmark Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
Sam
Guest
Sam

Hi Johan

Can you kindly tell me how to inject multiple drivers for different models using a single Task Sequence.

I will really appreciate.

Sam
From UK

Julien Coudert
Guest
Julien Coudert

Hello,

I followed this tutorial :

https://developers.hp.com/hp-client-management/blog/automating-mdt-drivers-hp-client-management-script-library

Injection of the drivers is not working …

On this article the author use the value "Win10\%Product%" for the variable "DriverGroup001".

On your article you use "%Model%", I don't understand the difference …

Could you, please, explain it ?

Thanks and sorry for my poor English.

stoms
Guest
stoms

We are using the "Total Control" scenario to inject drivers for different models.
How can we combine this with selection profiles to inject common drivers e.g. for docking stations for all laptops?

I have created a selection profile that matches the name of the Make and Model and selected the model drivers as well as the Displaylink drivers.
Is this the correct way to do this?

Gianluigi
Guest
Gianluigi

Hi Johan, I own all your books and I used the "Total Control" scenario since MDT 2010.
However we are in the process of migration to Windows 10. So I bought your book DF vol. 6, that continue to present the "Total Control" as a feasible way to manage the driver, but it simply doesn't work with MDT version 6.3.8456.1000. Are you aware of any bug on this topic? Thanks! 🙂
I posted a topic here https://social.technet.microsoft.com/Forums/en-US/abfbb359-a216-4ea7-92db-c34b39f981e2/using-mdt-version-6384431000-drivers-not-injecting?forum=mdt&prof=required

jasonrw
Guest
jasonrw

Hi,

Great tutorial! How do you get the "Set Drivergroup" step in your task sequence? I don't have it in mine. I just have "Inject Drivers."

Thanks

joebrug
Guest
joebrug

Absolutely right.. needed the Kernel Mode Driver Framework update in the reference image. Working great again, thanks Johan

joebrug
Guest
joebrug

Dell OptiPlex 7020.. Anyone deploying windows 7 x64 to this?
I tried deploying my current image to it, and as I thought, it booted and errored out because no network drivers, etc. I created an OptiPlex 7020 folder in Out-of-Box DriversWindows 7 x64 in MDT and imported the drivers from dell driver pack. Re-deployed the image to a desktop, now it errors out during "Setup is preparing your computer for first use" and just keeps rebooting after pressing OK. How do I determine what is failing?

Keke
Guest
Keke

Hi Johan,i used scenario #3 deployment solution. My OOBE is structured like your screenshot. I created 3 TS (Windows 7 x32, Windows 7 x64 and Windows 8.1 x64). In each TS i added Task Sequence Variable DriverGroup001 with value "Windows 7 x32%Model%" in the preinstall section just before Inject Driver. My understanding is : 1 – Do i need to add someting in my CS.ini to call my variable DriverGroup001 ?2 – Do i need to modify some script to call my variable DriverGroup001 ?3 – If i choose "Nothing" and "Install all drivers from the selection profiles" in PreinstallInject… Read more »

RickB
Guest
RickB

Johan,

Thanks for the video.

Another question: do you know if there's a way to call/execute a task sequence from another task sequence? I have a 'template' task sequence that has about 25 driver packages with their corresponding WMI queries, and I'd like my OSD users to leverage that template task sequence from their OSD task sequence. The alternative would be that they would have to update their OSD task sequence with the contents of my template task sequence every time I add a new driver package.

yhttech
Guest
yhttech

Johan, I'm in the progress of building and testing a new MDT environment at my school. I've built the share, and started testing deployment to the different models we have. So far I have 6 machines tested, 5 Dells and one HP laptop model. The issue I'm having is with the HP laptop. The drivers were imported into the MDT environment in folder OSPlatformModel. Deploying to a Dell Vostro 260s works using this structure (The only other system that needed OOB drivers) – I've set my CS.ini file to start like:[Settings]Priority=Model, DefaultProperties=MyCustomProperty [Vostro 260s]DriverGroup001=Windows 7×86%model%DriverSelectionProfile=nothing [HP ProBook 6455b]DriverGroup002=Windows 7×86%model%DriverSelectionProfile=nothing The… Read more »

RickB
Guest
RickB

Johan,

Thanks for the video, it's very informative and educational. Another question for you: do you know of any documentation available that shows a process diagram of the imaging process with the respective components (ie drivers, WinPE), and all the different log files and their location depending on where you are in the imaging process?

pitchdown
Guest
pitchdown

Added:
the missing drivers are :

ven_8086@dev_0F31@SUBSYS_06031028
ACPINTCF1A1
ACPIDLAC30023&36B2D927&0
ACPIINT33FB1

These are added to the MDT-selection profile, but not installed on the dell venue pro 5130 after installation with mdt2013.

Anybody who knows a solution for this issue?

pitchdown
Guest
pitchdown

Hello,
i also try to install the dell venue pro 5130 with MDT.
This is working well, except for 4 drivers (camera-drivers, and sensor-driver).
These drivers are added to MDT, but the hardware is not recognized after the installation.
When pointing to the driver-location manually , the hardware is installed right away.

Any idea why these camera and sensor-devices are not installed with the imported drivers?

Thx

RickB
Guest
RickB

Johan,

Thanks for the prompt reply. Can you tell me how the variable should be configured for driver packages instead of drivergroup when using SCCM? Thanks much. Maybe post an explicit article on MDT 2013 Zero Touch Driver Management with screenshots?

RickB
Guest
RickB

Does the Total Control method work for SCCM 2012 SP1, and if so, are the steps/methods exactly the same, or are they any different?

davidlink
Guest
davidlink

A past user commented on Dell Venue 11 Pro tablets and finding that several different model names are reported when doing a WMI query such as Dell Venue 11 Pro 7130 vPro, Dell Venue 11 Pro 7139 vPro, etc. This will occur depanding on what Bios the Venue 11 Pro's are running. for example, prior to Bios A10 a Venue 11 Pro would return a wmi query of "Dell Venue Pro 11 7130", but after updating the bios to A10 or greater the wmi query will return Dell Venue 11 Pro 7130 vPro.

iburnell
Guest
iburnell

Hi Johan. I wonder could this be used with SCCM 2012 (with MDT 2012.1). I'm using the MDT Task Sequence and want to find a "cleaner" way to apply driver packages (total control) rather than having multiple steps in the Task Sequence for all the different models. MDT has already gathered the Make, Model and architecture so it would be greate to use drivergroup,driverselectionprofile to somehow identify the %make% %model% to "apply driver package" to install. I notice SCCM uses the command line osddriverclient.exe /install:packageidnumber, so what I'm trying to do is to automate through the use of the MDT… Read more »

DanVega
Guest
DanVega

I forgot to post back, but yes I just edited the Modelaliasexit script and it worked perfectly.

hendrixs
Guest
hendrixs

Hi Johan, This is probably a silly question, but my deployment share currently has the tick box checked for both x86 and x64 platforms. If I am not deploying any x86 operating systems right now does that mean I can uncheck x86? I am only deploying x64 OS. Secondly, we are only deploying Dell machines so I use their CAB files for importing drivers. Now even though I only select the x64 sub-folder sometimes x86 drivers get imported along with them. I assume this is just because of how the CAB gets packaged and can't necessarily be avoided. If the… Read more »

klarion
Guest
klarion

Maybe you're right. I need to check that modelalias script and test it. Btw. I read somewhere that you are writing a new book? Any release date yet? Deployment Fundamentals 4 was very good and I learned so much from that book. Keep up the good work!

klarion
Guest
klarion

Thanks for your answer. I'm finding it little hard to fully automate the drivergroup selection. We use lot's of Lenovo machines and Lenovo is using quite interesting naming standard for those machines and if we could manually choose the drivers during deployment it would be easier for us.

klarion
Guest
klarion

Thanks for your answer. I'm finding it little hard to fully automate the drivergroup selection. We use lot's of Lenovo machines and Lenovo is using quite interesting naming standard for those machines and if we could manually choose the drivers during deployment it would be easier for us.

klarion
Guest
klarion

Hi Johan,

I was asking earlier about setting the DriverGroup variable manually during Wizard pages. I looked from your DF4 book about customizing the LiteTouch Wizard but my scripting skill are not so good so I was hoping you could give some kind of example 🙂 I'm trying to make a Wizard page with drop down list that contains predefined values that can be selected and driver group would be set based on that.

aillian
Guest
aillian

And so my spaces were stripped on that structure. Lame.

I found a good setup here: lh4.ggpht.com/-qFM1D2eGBX0/UDJCIGelagI/AAAAAAAAAEE/v-_WO1mxHQE/33C7326B3C730BA39458AE1C3B7F465C68B06149.png?imgmax=800

aillian
Guest
aillian

Corey – I see your confusion. I had the exact same question when I came to this blog post. Each new task sequence you run has it's own drivergroup001 setting, so you can point to whichever OS version you are wanting to install with the same DriverGroup001. So if you just set your task sequence variables exactly like in the blog post, you will be good. You can just copy needed drivers from one OOBE directory to another. That way as you get new models in you can just import and as long as you don't check the box that… Read more »

Babagunoosh
Guest
Babagunoosh

Howdy Johan, I just wanted to thank you and let you know that I have learned so much from reading your book and also from your site. Some background info: I am fairly new to MDT. I work for a school system and have in the last year inherited an older MDT server (Server 2008 R2 with MDT2012), and from what I can tell, was not setup the best way by my predecessor. I think he thought that just creating sub folders in the drivers section of the workbench – Out of Box drivers section was creating the total control.… Read more »

absentspace
Guest
absentspace

Hi All, I'm wondering if there is a best practice for creating a practical test environment. It seems like every time I add a new model to our environment, something that works stops working and it takes a couple of days to get everything back in order. Background, we deploy predominantly HP notebooks with the occasional desktop and very rarely we deploy to another vendor's hardware. I started out using the total chaos method, but that made it increasingly difficult to identify problems when they occur, so i'm beginning to transition to total control, even though we predominantly deploy Windows… Read more »

klarion
Guest
klarion

Johan,

What is the page number? 🙂 I didn't notice it. I have the book.

klarion
Guest
klarion

Johan,

What is the page number? 🙂 I didn't notice it. I have the book.

klarion
Guest
klarion

Hi,

I really like the total control method because it just works great. Would it be possible to manually set the driver group variable in deployment wizard? It would be great if you could manually browse and select what drivers to use.

DanVega
Guest
DanVega

Well, I guess it doesn't really matter since MDT doesn't import duplicate drivers. But it still seems like it would make management easier if only one folder needed to be maintained for that series while continuing to use the model variable.

DanVega
Guest
DanVega

Hi Johan, I've been using the total control method and the ModelAliasExit script as mentioned in the DFv4 book. We've started getting in some Dell Venue 11 Pro tablets and I've found that several different model names are reported when doing a WMI query such as Dell Venue 11 Pro 7130 vPro, Dell Venue 11 Pro 7139 vPro, etc. Since they use the same driver set, do I need to edit the ModelAlias script? How do I make it treat those models the same? To further complicate it the Dell Venue 11 Pro 5130 uses a different driver set, so… Read more »


>