deployvista.com > Home - MDT 2010 Lite Touch Driver Management

Location: Blogs Johan Arwidmark
Posted by: johan	4/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

Permalink \| Trackback

Comments (21)

Re: MDT 2010 Lite Touch Driver Management

By SX00237 on 5/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 = \\DeployServer01\Deploy_Win7\Drivers\Win7_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 ?

Re: MDT 2010 Lite Touch Driver Management	By johan on 5/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....

Re: MDT 2010 Lite Touch Driver Management

By stephanbadenhorst on 6/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?

Re: MDT 2010 Lite Touch Driver Management	By eschloss on 6/18/2010
when using scenario 3, can I create subfolders under the model and still have the DriverGroup001 variable work?

Re: MDT 2010 Lite Touch Driver Management

By jonconwayuk on 7/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.

Re: MDT 2010 Lite Touch Driver Management

By P.w.h on 7/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 ?

Re: MDT 2010 Lite Touch Driver Management	By probles on 10/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?

Re: MDT 2010 Lite Touch Driver Management

By johan on 10/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

Re: MDT 2010 Lite Touch Driver Management	By jeroenv on 1/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 WinXP\Dell Inc.\Optiplex 755 it works fine. Any idea's on where to look? Regards, Jeroen

Re: MDT 2010 Lite Touch Driver Management

By johan on 1/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

Re: MDT 2010 Lite Touch Driver Management	By jeroenv on 1/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

Re: MDT 2010 Lite Touch Driver Management	By johan on 1/14/2011
That's correct, but you shouldn't really do full source file setup. That's only intended for building the reference image.

Re: MDT 2010 Lite Touch Driver Management	By jeroenv on 1/14/2011
why not? isn't it better to do a fresh install everytime?

Re: MDT 2010 Lite Touch Driver Management	By johan on 1/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,...

Re: MDT 2010 Lite Touch Driver Management	By Hal_2001 on 7/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?

Re: MDT 2010 Lite Touch Driver Management	By johan on 8/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

Re: MDT 2010 Lite Touch Driver Management

By mickmeister on 10/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 & "\root\CIMV2")
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

Re: MDT 2010 Lite Touch Driver Management

By mickmeister on 10/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

Re: MDT 2010 Lite Touch Driver Management	By johan on 1/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

Re: MDT 2010 Lite Touch Driver Management	By michael.packard on 1/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.

Re: MDT 2010 Lite Touch Driver Management

By johan on 1/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:\deploymentshare\out-of-box drivers
|- Net
|- Display

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

C:\deploymentshare\out-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.