MDT 2010 Lite Touch Driver Management

By arwidmark / April 25, 2010

In the “A Drivers Saga – The Control Freak meets The Dynamic Developer” session at MMS 2010 in Las Vegas, me and Michael Niehaus presented different methods of managing drivers with MDT 2010 and ConfigMgr 2007. I focused on MDT 2010 Lite Touch, and Michael Niehaus did the ConfigMgr part. On top of that Michael started blogging about his part of the session… so now I have to do my part 🙂

Michael’s blogs on ConfigMgr Driver Management can be found here: 

Part 1:
http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx

Part 2:
http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-2.aspx

Part 3:
http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-3.aspx

Back to MDT 2010 Lite Touch, we have two “types” of drivers to worry about when deploying Windows. We have drivers for Windows PE (the boot image) and we have drivers for the Windows Operating System that we deploy.
Driver management for the boot image is pretty straight forward, so I just wrote down my recommendations in this guide. Driver management for the Operating Systems that we 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, similar to what Michael did in his ConfigMgr Drivers article.


Drivers for Windows PE (the boot image)

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

The good thing about Windows PE 3.0 is that it supports the same hardware as Windows 7, so if you are lucky you don’t need to add any drivers at all to it. But in this article is guidance if you need to. We also need to set the scratchspace in WinPE 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 2010 Lite Touch I recommend that you do the following

  • Create two folders in Out-Of-Box drivers, name the folders WinPE x86 and WinPE x64.
     
  • Import any needed x86 drivers into the WinPE x86 folder, and any needed x64 drivers into the WinPE x64 folder. Note that you should only use Windows 7 drivers for the boot images, even if you plan to deploy Windows XP with MDT 2010 Lite Touch.
     
  • Create two selection profiles, one named WinPE x86 (where you select the WinPE x86 folder in Out-Of-Box drivers), and one named WinPE x64 (where you select the WinPE 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.


Drivers for Windows Operating systems

To simplify things we usually start with one of three core scenarios when configuring drivers for MDT 2010 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 or midsize company, they are only deploying one operating system, say Windows 7 x86, 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 we 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.

Deployment Workbench with drivers imported for Scenario #1

 

 

Scenario #2 – Added Predictability

This scenario has the following assumptions. This is a midsize company, they are deploying multiple operating systems, say Windows XP and Windows 7 x86, 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 XP drivers are considered for Windows XP and deployments, and that only Windows 7 drivers are considered for Windows 7 deployments. The feature in MDT 2010 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 2010 is that you first create two folders inside Out-of-box drivers, named Windows XP x86 and Windows 7 x86. Then we import the drivers the correct folder in the Deployment Workbench.

After importing the drivers, 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.

Creating the selection profiles.

Configuring the Inject Drivers action to use a selection profile.

 

 

Scenario #3 – Total Control

This scenario has the following assumptions. This is a larger company, they are deploying multiple operating systems, say Windows XP and Windows 7 x86, they have many hardware models, and from multiple vendors. The major difference from the second scenario is that are using hardware from multiple vendors.
Since we have multiple vendors involved the testing and compatibility matrix between each model cannot be guaranteed. We need to be able to filter not only on operating system but also on a per model basis. Even though we 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 us do some more advanced filtering.

Solution

For this scenario I recommend that you use the default PnP ID detection based method with the addition of using DriverGroup as a filter for the drivers. The configuration in MDT 2010 is that you first create two folders inside Out-of-box drivers, named Windows XP x86 and Windows 7 x86. 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.

Note: If you are having issues with drivers not detected by plug and play within the folder, you can force 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  🙂

Create the driver folder structure in Deployment Workbench

Add the Set Task Seuqence Variable action with DriverGroup001 set to Windows 7 x86\%Model%

Configure the Inject Drivers Action to use the “Nothing” selection profile.

 

Regards / Johan Arwidmark

About the author

arwidmark

RoBL - May 5, 2010

Hi Johan,

Nice post, Can you explain/tell why we should go for “Scenario #3 – Total Control” en not go for the DRIVERPATHS001 option in the CustomSettings.ini this is still working end less complex in my opinion.

DRIVERPATHS001 = \DeployServer01Deploy_Win7DriversWin7_x86%model%

I read something that the next version/build of MDT2010 does not support the DRIVERPATHS001 feature is this the reason for Scenario #3 ?

arwidmark - May 5, 2010

DriverPaths still works in MDT 2010, even if they are considered legacy… I like drivergroups because they match the virtual folder structure in the deployment workbench….

Stephan - June 9, 2010

Hi Johan,

Thanks for the great info! We are using MDT 2010 with Lite Touch in a non-AD environment. I have been testing driver management like explained in Scenario 3 and it works great. But I still have a problem regarding drivers that has an application bundled to it. Is there a way to handle the installation of the driver applications per specific computer model in the before mentioned environment?

eschloss - June 18, 2010

when using scenario 3, can I create subfolders under the model and still have the DriverGroup001 variable work?

jonconwayuk - July 3, 2010

“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.”

How do you work out the correct Make and Model values for naming the driver folders? Just need some clarification as method 3 looks like it would be ideal for my environment but I’m just not sure on how you get the correct name for the Make and Model. E.g. we use HP Compaq DC7800 and DC7900 computers so would the name need to be “HP Compaq DC7800” or “HP DC7800” or “DC 7800” etc.

P.W.H - July 14, 2010

I want to make a single image say windows 7, that contains the drivers for all of my 7 different hardware vendor models. I want to load this onto a reference machine and take an image of it.
Then imagex that image onto any of the various hardware models and have that model fully supported.
What is the best way to inject the drivers onto the reference server so that they are available to the various target servers, or is it true that MDT2010 isn’t an appropriate tool for creating that type of image ?

Paul_R - October 18, 2010

I like Scenario #3 – Total Control. I have question about how you use the name of the model for the folder. The example I give is some time HP has this as the model HP Compaq 6910p but sometimes we will see this HP Compaq 6910p (number string). How does MDT handle the extra number string? Does it still drop the correct drivers for the Model?

arwidmark - October 18, 2010

There are many solutions to handle model aliases

Using and Extending Model Aliases for Hardware Specific Application Installation
http://blogs.technet.com/b/deploymentguys/archive/2009/09/10/using-and-extending-model-aliases-for-hardware-specific-application-installation.aspx

BDD 2007 Tips – Creating Model Aliases
http://blogs.technet.com/b/benhunter/archive/2007/03/28/bdd-2007-tips-creating-model-aliases.aspx

/ Johan

jeroenv - January 14, 2011

I have a problem deploying with the Scenario #3 method. I have it set up to deploy windows xp, but when I use the task sequence variable as WinXP%Make%%Model% the computer goes into a 7B blue screen after copying the files. When I set the variable manually to WinXPDell Inc.Optiplex 755 it works fine. Any idea’s on where to look?

Regards,
Jeroen

arwidmark - January 14, 2011

7B is missing mass storage driver. MDT 2010 Lite Touch does not support injection of mass storage for XP as part of the normal deployment process, they need to go into the build and capture process (when creating the reference image).

Check this article:

MMS 2010 – Sample Sysprep Files for Windows XP SP3, April
http://www.deployvista.com/Blog/JohanArwidmark/tabid/78/EntryID/130/language/en-US/Default.aspx

/ Johan

jeroenv - January 14, 2011

After a long search I found out that for Windows XP you also need the task sequense variable StorageDriverGroup001.

(I do a full source file setup)

Regards,
Jeroen

arwidmark - January 14, 2011

That’s correct, but you shouldn’t really do full source file setup. That’s only intended for building the reference image.

jeroenv - January 14, 2011

why not? isn’t it better to do a fresh install everytime?

arwidmark - January 15, 2011

Fresh install yes, scripted unattend no, it’s just a waste of resources, adn time… You should deploy the image, its way faster and much easier to deal with storage controllers among other things . Also easier to add in apps or updates if needed.

Microsoft is doing everything image based these days, so should you,…

Hal - July 29, 2011

Question, I was following senario 2# and when I imported the drivers to the Windows 7 folder (under Out-of-Box) drivers. The drivers populated both the Windows 7 and the Windows XP folder. Can you explain why this happend?

arwidmark - August 5, 2011

The import feature only adds the drivers to the folder you right-click and select import on. Sometimes the workbench can be slow to refresh though.

/ Johan

mickmeister - October 7, 2011

Here is a VBScript that will display the correct model name to use:
strComputer = “.”

On Error Resume Next

Const wbemFlagReturnImmediately = &h10
Const wbemFlagForwardOnly = &h20

‘WScript.Echo
‘WScript.Echo “==========================================”
‘WScript.Echo “Computer: ” & strComputer
‘WScript.Echo “==========================================”

Set objWMIService = GetObject(“winmgmts:\” & strComputer & “rootCIMV2”)
Set colItems = objWMIService.ExecQuery(“SELECT * FROM ” _
& “Win32_ComputerSystem”, “WQL”, wbemFlagReturnImmediately _
+ wbemFlagForwardOnly)

For Each objItem In colItems
‘WScript.Echo “Manufacturer: ” & objItem.Manufacturer
WScript.Echo “Model: ” & objItem.Model
Next

mickmeister - October 7, 2011

One other way to get all of the correct model names for this method through SMS 2003 is to use this query to display only the computer names of all systems in your company. This query obviously is for our dell systems, but it can be easily modified:

select distinct SMS_G_System_COMPUTER_SYSTEM.Model from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.Model like “Inspiron%” or SMS_G_System_COMPUTER_SYSTEM.Model like “Latitude%” or SMS_G_System_COMPUTER_SYSTEM.Model like “OptiPlex%” or SMS_G_System_COMPUTER_SYSTEM.Model like “Precision%” order by SMS_G_System_COMPUTER_SYSTEM.Model

arwidmark - January 31, 2012

Nope, the structure on disk is just for the single instance storage. The logical view in the workbench does not mimic the store, and is only used for management and driver assignement/injection.

/ Johan

Michael Packard - January 31, 2012

Okay, it just dawned on me how this all fits together. Thanks!

On a side note, any chance of removing my email (user name) from the prior post and replacing it with just my name as reference? There wasn’t a way I could find to change that so I just re-registered.

arwidmark - January 31, 2012

Not without hacking the database so I just removed your post, and added your question here:

Question from: michael.packard

******

Hi, Johan. Great guide here.

I am, however, slightly confused and need some clarification in regards to Scenario #3 – Total Control.

Using one of the models that I work with as an example:

When you create the virtual directory structure in the Deployment Workbench, you get the ‘virtural’ structure of:
.out-of-box drivers
|- HP EliteBook 8440p
|- Network
|- Video

On the actual disk, however, I have the following:

C:deploymentshareout-of-box drivers
|- Net
|- Display

If I understand the task sequence & driver injection properly, shouldn’t I have a directory structure like this:

C:deploymentshareout-of-box drivers
|- HP EliteBook 8440p
|- Net
|- Display

The %model% directory (hp elitebook 8440p, in this case) would be manually created and the Net & Display directories moved into it.

Eric - March 28, 2012

Hi Johan, I followed exactly your 3 methods with always the same result
in the ztidrivers.log I alsway have this :
No driver copying needs to be performed during the Lite Touch postinstall phase.

I missing something but I don’t know what, I made 2 test, one with a Lenovo T520, model 424229u and the second with a Lenovo M91P model 4524A2U, the 2 tests had the same result as discribed.

I also tried this in the CS.ini

[Settings]
Priority=Default, ByModel

[ByModel]
Subsection=MOdel-%make%-%model%

[Model-Lenovo-4524A2U]
DriverSelectionProfile=Nothing
DriverGroup001=Win7_x86%make%%model%

same result, I really don’t know what I’m doing wrong or what I forgot

arwidmark - March 28, 2012

I normally set the DriverGroup and Selectionprofile in the task sequence, but If you want to do it all in cs.ini it should like this:

[Settings]
Priority=Default
Properties=DriverInjectionMode

[Default]
DriverInjectionMode=ALL
DriverSelectionProfile=Nothing
DriverGroup001=Win7_x86%Make%%Model%

/ Johan

Eric - April 3, 2012

Thanks Johan
Now the drivers are copied into c:drivers, but the drivers are still not installed, the devicepath in the registry is %systemroot%inf, I thought that is suposed to be something like c:drivers

At the end of the ztidrivers.log, it’s written this
Vista identified, skipping upsate of devices path,

I suppose that it’s normal because I have Windows 7
and there are no error in the ztidrivers.log

arwidmark - April 3, 2012

If the driver is copied but not inject, you can check dism.log and setupact.log to see if it was staged to the store correctly.

If it did was staged in the store, you can check setupapi.dev.log to see why it didn’t install.

/ Johan

Eric - April 13, 2012

Hi again Johan
Before writing you, I swear that I did a lot of research, found a couple a thread on social technet, but I did not find the answer to my problem yet
ok like I said earlier, the drivers are copied to c:drivers folder but they are not staged into the driverstore, I can’t find why, I don’t have the dism.log file in the computer, I checked the setupact.log from the panther folder but I did not find why the drivers are not staged into the driverstore
here the setupact.log https://skydrive.live.com/redir.aspx?cid=cfb8d2bbc3c1f5bd&resid=CFB8D2BBC3C1F5BD!155&parid=CFB8D2BBC3C1F5BD!140
can you please, if you want, check it and tell what i’m doing wrong

thanks a lot

arwidmark - April 13, 2012

I can see its injecting NIC drivers for the Intel Card. zip together the mdt logfiles and upload them as well.

Do you by any chance have a drivers folder in your reference image?

/ Johan

Eric - April 13, 2012

Thanks Johan for taking the time
I knew about the drivers folder in my reference image
I checked it, an there’s no drivers folder in my reference image
here all my log files, I puted everythings

https://skydrive.live.com/redir.aspx?cid=cfb8d2bbc3c1f5bd&resid=CFB8D2BBC3C1F5BD!156&parid=CFB8D2BBC3C1F5BD!140

Thanks!

arwidmark - April 13, 2012

The only drivers that are copied locally is Intel NIC and Intel Wireless (see the ZTIDrivers.log file) they are also injected into the store per the setupact.log. Which driver are you missing?

Eric - April 14, 2012

Sorry I should have precised, these are the only two drivers that I added in the oob driver, at the end of the installation (lite touch) both drivers are not installed, at the end of the bdd.log this is written
“No physical adapters present, cannot deploy over wireless”
the end of the lite touch crash, recover from domain etc…

If I look to windowssystem32driverstorerepository I don’t see the my 2 drivers

arwidmark - April 14, 2012

OK, it seems that you have imported Windows XP network drivers in addition to the Windows 7 network drivers… You should only import drivers from the PRO1000Win32NDIS62 folder (not the NDIS5x and NDIS61) folders. Delete the drivers, and redo the import, but this time only from the NDIS62 folder.

/ Johan

duber3 - April 16, 2012

Well, I did exactly what said and still the same result
At the end of the litetouch, the lan drivers are not installed and the LT stop there

I don’t know what to think, like I said earlier, the drivers are not present in the system32driverstorefilerepository folder

arwidmark - April 16, 2012

Does the driver you injected work if you install it manually on the machine?

Please upload the new log files (MDT logs, setupact.log and setupapi.dev.log)

/ Johan

Eric - April 17, 2012

Thanks Johan
I really appriciate your help
Ok, at the end of the LT, the drivers are not installed but copied to c:drivers, if I install the drivers manually, pointing to c:drivers, the lan and wifi drivers are installed perfectly
another observation(maybe a clue for you), If I follow your third technic (total control) no drivers are copied and this is written in the ZTIDrivers.log”No driver copying needs to be performed during the Lite Touch postinstall phase”

for now I use the CS.ini like you told me earlier for the drivers

here the new log and I puted some extra maybe it can help

https://skydrive.live.com/redir.aspx?cid=cfb8d2bbc3c1f5bd&resid=CFB8D2BBC3C1F5BD!158&parid=CFB8D2BBC3C1F5BD!140

Again…thank you very much for your help

Razerwing - April 17, 2012

I have not seen this covered anywhere, so I will ask it hear. I have a folder of Windows 7 x86 > Dell Inc. > Generic Optiplex , and this covers 740, 745, 755, GX620, and GX520 models. We have all 5 models deployed. Should I create a seperate folder for each and copy all the drivers into them, or is there an easier way?

Along the same line, can I have it setup to look for %Make%%Model% and if it does not exist use a selection profile of x86 or x64?

Thank you for your time.

arwidmark - April 18, 2012

If you set the DriverGroup001 value to Windows 7 x86Dell Inc.Generic Optiplex it will add all drivers in that folder

You cannot use %Model% since it doesnt match the folder path, on you do not need to create selection profiles.

/ Johan

Eric - April 18, 2012

Hi Johan
did you have the time for checking my logs?

thanks

arwidmark - April 19, 2012

DriverGroup001 works fine as long as you get the folder names exactly right… in your example the folder name in out-of-box drivers should be Windows7x86LENOVO424229U

As for the logs I need the dism.log and cbs.log file from the machine as well… I can see the driver is copied, but setupapi.dev.log doesn’t find it in the driverstore, so its most likely that dism failed for some reason.

/ Johan

arwidmark - April 19, 2012

Can you please try using the default Windows 7 image from the DVD/ISO, and not your captured image?

/ Johan

Eric - April 19, 2012

In the last log I uploaded, the cbs.log is present in the Panther folder
as for the dism.log, I can’t find it on the computer, I readed almost everything on log that I uploaded, here what I found,
the ztidrivers start at 08:10,50 and finished at 08:10,59
in the cbs_unattend.log this is written at 08:10,27 (before the drivers were copied) 2012-04-17 08:10:27, Error DISM Driver Manager: PID=500 Failed to find driver packages at ‘drivers’

anyway I will try with the default windows image, as for my drivers folders
I pay attendtion when creating them and there is no errors in the name

again thank for your help, I really appreciate

Eric - April 19, 2012

Finally, I was able to make it, the problem is in my task sequence
I tryed with a default TS and it worked, I don’t know where the problem is in my TS, I will check parameter per parameter
at least I know that it’s working

thanks for your help Johan

Eric - April 19, 2012

OK I found my error, in my TS, I added in WindowsPE pass an delete and create partition, I thought that it was needed, my bad

Matt Powers - May 21, 2012

I am implementing Total Control driver management, but I’m curious what happens if you are deploying to a machine that does not have a folder created for it in the out of box drivers? We sometimes have older Dell machines that don’t have .cab driver packs created for them, and so I was planning to default back to the combo pack that Dell supplies when trying to deploy an OS to a computer that doesn’t have a corresponding folder in the out of box driver section. So, what I was thinking is that I would do something like this:

IF %model% folder exists, then inject those drivers
ELSE inject combo pack drivers

Is this possible to set up using conditions in the inject driver or set driverGroup tasks in the sequence?

I thought about just seting two inject driver tasks, one with %model% and another with the combo pack, but then that seems like reverting back to Chaos again, because every computer would then get both the combo pack and the %model% drivers and PnP would have to decide which to install…

Thanks in advance for any help you can give.

arwidmark - May 22, 2012

If you use a vbscript to set the drivergroup property you can use Else.

/ Johan

Comments are closed