You are here:   Research
Register   |  Login
The quickest way to find articles is to use the below search option.

However, if you go to the end of this page, you also find the Blog archive (calendar format) that allows for browsing of older articles.

Search:

MDT 2013 Lite Touch Driver Management

Oct 11

Written by:
10/11/2013 12:59 PM  RssIcon

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.

62 comment(s) so far...


Gravatar

Re: MDT 2013 Lite Touch Driver Management

Doing a beta test of MDT 2013 on Windows 2008 R2 with hyper V. Im having an issue with My Hyper VM getting an IP address when booting the new MDT disk (WINPE 5) any idea if winPE 5 does not have drivers for this version of hyper V (did not need to load any for WinPe 4)

By peteo on   10/28/2013 9:52 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Currently in my organization we are only deploying Windows 7 to Dell models so total chaos is being used to pick from all drivers. I do have a question though. If I want to get more granular control and use DriverGroups for the known models our IT department purchases this works fine, but there are some non-IT personnel who are able to image computers using LiteTouch and it may not be a Dell or other vendor I have driver support for explicitly. Is there a way to say use DriverGroups for these known models, but if not known use the old method of injecting all applicable drivers?

By hendrixs on   12/31/2013 10:55 AM
Gravatar

Database Driven : MDT 2013 Lite Touch Driver Management

Hello,
I'm working with MDT 2013 but Database Driven, now my question is can you put this setting in Details of Computer (with MACaddress). I thought that this might me the settings
Drivergroup (Specifies the name of the driver group from which drivers should be injected) - Windows 7 x64\%Make%\%Model%
DriverSelectionProfile (Profile name used during driver installation.) - Nothing

Am my missing something.

Also I like to find out all the settings of Database driven deployment and there explanation..

Thanks in advance

By zophar on   1/6/2014 4:13 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Hi Hendrixs,

You can use the total control for the models you have the most of, and then a "Generic" model that you use for everything else.

/ Johan

By Arwidmark on   1/6/2014 7:22 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Hi Zophar,

I would not store DriverGroup info on a per machine basis, even though you technically can. Use Make/Model instead.

/ Johan

By Arwidmark on   1/6/2014 11:17 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Hi Peteo,

I have only tested WinPE 5.0 in Windows Server 2008 R2 SP1 (not without SP1), but in Windows Server 2008 R2 SP1 it works just fine.

I don't see however, why it should not work in the RTM version of Windows Server 2008 R2.

/ Johan

By Arwidmark on   1/6/2014 11:19 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Thanks Arwidmark! Great tutorial! In regards to the Total Control method, I would like to discuss the management of updating drivers. The problem I am trying to solve is knowing when the last time myself or someone from the IT department actually updated the driver folder with the latest drivers. To solve this problem i have been using subfolders under the %Model% folder to indicate the 'Driver CAB pack' imported. Using this method just looking at the subfolders will tell me if I have already imported the 'latest' drivers. However because I am using the 'import all drivers' option, I am wondering if this is causing me to load 'old' drivers along with the 'new' drivers? Maybe the OS is smart enough to pick the 'newest' driver if two are the same? I would like to know your process for updating these driver folders? In thinking about this I have devised three methods. Method 1, using subfolders. Method 2, import and notate. Method 3, delete, import, and notate. Below is each method in detail. I am interested in your thoughts on the matter.


Updating Drivers Method 1 - Subfolders

1. Copy Driver CAB file to \\mdtserver\\Source
2. Unzip the Driver CAB file then delete the CAB file
3. Delete the x86 folder inside the new Driver CAB folder (assuming this is a x64 deployment only)
4. Import the Driver CAB files in the MDT Deployment Workbench:
-Choose the respective Deployment Share (e.g., Client)
-Expand Out-of-Box Drivers and browse to the correct folder respective to the Operating System and Model (e.g., W7x64\OptiPlex 990)
-Create a New Folder under the Model folder naming it the same name as Driver CAB folder (e.g., W7x64\OptiPlex 990\990-win7-A07-38JJC)
-Right click on the new folder and choose Import Drivers
-Browse to D:\Source, find the appropriate Driver CAB folder, make sure 'Import drivers even if they are duplicates' IS NOT checked (duplicates drivers are copied to save space), press Next, Next, and Finish
5. Right click on the Deployment Share and choose Update Deployment Share, select the options Optimize and Compress, click Next, Next, and Finish.


Updating Drivers Method 2 - Import and Notate

1. Copy Driver CAB file to \\mdtserver\Source
2. Unzip the Driver CAB file then delete the CAB file
3. Delete the x86 folder inside the new Driver CAB folder (assuming this is a x64 deployment only)
4. Import the Driver CAB files in the MDT Deployment Workbench:
-Choose the respective Deployment Share (e.g., Client)
-Expand Out-of-Box Drivers and browse to the correct folder respective to the Operating System and Model (e.g., W7x64\OptiPlex 990)
-Right click on the folder with the respective Model name (e.g., OptiPlex 990) and choose Import Drivers
-Browse to D:\Source, find the appropriate Driver CAB folder, make sure 'Import drivers even if they are duplicates' IS NOT checked (duplicates drivers are copied to save space), press Next, Next, and Finish
5. Right click on the Deployment Share and choose Update Deployment Share, select the options Optimize and Compress, click Next, Next, and Finish.
6. Notate the name of the Driver CAB file imported including the date it was imported, and the date the Driver CAB file was released.


Updating Drivers Method 3 - Dete, Import, and Notate

1. Copy Driver CAB file to \\mdtserver\Source
2. Unzip the Driver CAB file then delete the CAB file
3. Delete the x86 folder inside the new Driver CAB folder (assuming this is a x64 deployment only)
4. Import the Driver CAB files in the MDT Deployment Workbench:
-Choose the respective Deployment Share (e.g., Client)
-Expand Out-of-Box Drivers and browse to the correct folder respective to the Operating System and Model (e.g., W7x64\OptiPlex 990)
-Highlight all drivers in the folder with the respective Model name (e.g., OptiPlex 990) and delete every driver
-Right click on the folder with the respective Model name (e.g., OptiPlex 990) and choose Import Drivers
-Browse to D:\Source, find the appropriate Driver CAB folder, make sure Import drivers even if they are duplicates IS NOT checked (duplicates drivers are copied to save space), press Next, Next, and Finish
5. Right click on the Deployment Share and choose Update Deployment Share, select the options Optimize and Compress, click Next, Next, and Finish.
6. Notate the name of the Driver CAB file imported including the date it was imported, and the date the Driver CAB file was released.

By strict on   1/8/2014 1:34 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

thinking more about this, what i did was combine method 1 and 3. i posted this discussion here if you want to remove the rather long comment above. =) still interested in your thoughts! social.technet.microsoft.com/Forums/en-US/be2defa0-b398-4d58-a189-2201320bf9cf/outofbox-drivers-update-managment-procedure?forum=mdt

By strict on   1/8/2014 2:51 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Hi Strict,

I normally only update drivers when there is something that needs to be fixed, and never the entire cab-file content. For example, there has been a few issues with the Intel wireless driver, so I simply deleted the old version for the affected models, and then imported the new one.

For machines already deployed I use the vendor application (when possible), to force a silent update of the driver. If the vendor doesn't have a package I can use, I use DPInst.exe to create a package of my own.

/ Johan

By Arwidmark on   1/12/2014 7:00 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

We have been using SCCM for XP to Win 7 migrations with great success and using MDT 2013 task sequences via removable USB stick media for bare-metal deployments. PXE is a problem for us so we can't go there with SCCM. Here's our challenge:

1. We were an all-Dell shop and the "total chaos" method worked fine.
2. We switched to the "total control" method at your advice, which also worked just fine.
3. Now we are a mixed Dell and Lenovo shop.

Here's where our problem starts:
1. With Dell, a Latitude E6400 ALWAYS showed up in WMI as "Latitude E6400" regardless of minor production variations.
2. With Lenovo (as you undoubtedly know), a T430 shows up in WMI as "2349xxx", where the xxx can have up to 15 or 20 variations depending on who knows what.
3. The "SetDriverGroup" variable of "Windows 7 x64\%make%\%model%" has worked perfectly for us...BUT now we get slight variations in the Lenovo model name as known to WMI...may depend on what day it left the factory or whatever.
4. We could make a separate driver group for each and every known variation, but that means importing essentially the exact same drivers multiple times.
5. With SCCM the "AutoApplyDrivers" along with a "LIKE" command works great as we have "driver packages", which you don't in MDT.
6. I suppose we could make a separate selection profile for each model, but we can't put multiple selection profiles on a single removable media build.

So...the big question is: can we use a variable or "like" command of some sort to account for these subtle but annoying differences in Lenovo model numbers? I'm sure I'm not the first person to come across this Lenovo quirk.

Thanks in advance and I look forward to seeing you at my fourth consecutive TechEd in Houston in June!

By jeffe17505 on   1/27/2014 1:38 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

1. I normally combine the various revisions of a single model into one package-

2. For Lenovo I use a different WMI query, that matches there models better: SELECT * FROM Win32_ComputerSystemProduct WHERE Version LIKE '%T420%'

You might also want to look into the modelalias scrit by deployment guys, that puts the logic into a user exit script instead. Quite elegant.

3. See 2.

4. No need, try to combine into a single model package, often that's not too difficult.

5. I usually don't use Autoapplydrivers, only apply driver packages, but I know a few customers combining them, and being happy with the result.

6. In MDT Lite Touch, selection profiles are intended as generic selections, and drivergroup for more granular filtering.

See you in Houston :)

/ Johan

By Arwidmark on   1/27/2014 2:24 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Thanks for your swift reply. My main concern is MDT 2013 LiteTouch via USB Removable Media. We have to send the USB sticks to our vendor for imaging before shipping. I was looking for the easiest way via MDT LiteTouch via removable media to account for the variations in Lenovo models. the "SetDriverGroup" method doesn't work well for Lenovo using %make%\%model%. Are you saying you could use %make%\%version% instead?

By jeffe17505 on   1/27/2014 2:45 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Thanks for your swift reply. My main concern is MDT 2013 LiteTouch via USB Removable Media. We have to send the USB sticks to our vendor for imaging before shipping. I was looking for the easiest way via MDT LiteTouch via removable media to account for the variations in Lenovo models. the "SetDriverGroup" method doesn't work well for Lenovo using %make%\%model%. Are you saying you could use %make%\%version% instead?

By jeffe17505 on   1/27/2014 2:50 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Nope, %Version% won't work, but the modelaliasexit.vbs script will.

/ Johan

By Arwidmark on   1/27/2014 2:53 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Thanks for your swift reply. My main concern is MDT 2013 LiteTouch via USB Removable Media. We have to send the USB sticks to our vendor for imaging before shipping. I was looking for the easiest way via MDT LiteTouch via removable media to account for the variations in Lenovo models. the "SetDriverGroup" method doesn't work well for Lenovo using %make%\%model%. Are you saying you could use %make%\%version% instead?

By jeffe17505 on   1/27/2014 3:07 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Sorry for the double post.

By jeffe17505 on   1/27/2014 3:10 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

I have tried the modelaliasexit.vbs script using examples and syntax from other blogs and posts. After reviewing the ZTIGather logs I see it is parsing the script correctly when I use the "version" option of the script...In other words a ThinkPad X240 is correctly identified as a "ThinkPad X240" and the log shows MODELALIAS = ThinkPad X240. I have a ThinkPad X240 folder in my drivers tree but I'm still not getting any drivers injected. Is this something you can help me with here, or do I need to check elsewhere? I have posted a question to Mikael Nystrom's article on the subject but no reply yet.

Do I need to change the variable in DriverGroup001 to "Win 7 x64\%make%\%modelalias% now?

By jeffe17505 on   1/29/2014 9:00 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

If you are using the ModelAliasExit script you need to set DriverGroup001 to "Windows 8.1 x64\%Make%\%ModelAlias%" or whatever your logical folder structure is in the deployment workbench.

If you're using the book version (Deployment Fundamentals - Volume 4) of the ModelAliasExit.vbs script you also have the %MakeAlias% alias available, and then it would be DriverGroup001 = "Windows 8.1 x64\%MakeAlias%\%ModelAlias%"

/ Johan

By Arwidmark on   1/29/2014 10:52 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Thanks Johan. It occurred to me this morning after reviewing the logs that %modelalias% is taking the place of %model%. I changed the DriverGroup001 to OS\%make%\%modelalias% and it worked! I have an earlier version of Deployment Fundamentals. I will have to check out the script from the later version.

It's odd that none of the articles I have seen on that script mention changing the SetDriverGroup001 value.

Of course, if Lenovo would use "friendly" model names in their WMI properties instead of putting them in "version", all this would be unnecessary. Oh well.

Thanks again and see you in Houston!

By jeffe17505 on   1/29/2014 12:29 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Hi,

I use Scenario #3 – Total Control, which is great. The only issue I have is that I have 3 Deployment Shares on one server I currently duplicate the driver structure in each manually.

Is it possible to Set-up the Driver Configuration for one Deployment Share and when changed it automatically updates multiple deployment shares at the same time?

Thanks,

Jason.

By JasonNicolson on   2/12/2014 2:19 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Hi,

I use Scenario #3 – Total Control, which is great. The only issue I have is that I have 3 Deployment Shares on one server I currently duplicate the driver structure in each manually.

Is it possible to Set-up the Driver Configuration for one Deployment Share and when changed it automatically updates multiple deployment shares at the same time?

Thanks,

Jason.

By JasonNicolson on   2/12/2014 2:52 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Just copy the DriverGroups.xml and Drivers.xml plus the content of Deploy\Out-of-Box Drivers from you master deployment share, to the other deployment shares.

/ Johan

By Arwidmark on   2/12/2014 4:46 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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 I can't just point all Venue 11's to the same drivers.

By DanVega on   3/7/2014 9:07 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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.

By DanVega on   3/12/2014 11:07 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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.

By klarion on   3/17/2014 7:10 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

DanVega, You can either combine the drivers into the same folder, adds a little extra time to testing, but not much. Or, you can modify the modelaliasexit script.

Klarion, you can create a custom wizard pane that sets those values, we have an example in deployment fundamentals volume 4.

/ Johan

By Arwidmark on   3/19/2014 3:07 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Johan,

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

By klarion on   3/19/2014 8:58 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Johan,

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

By klarion on   3/19/2014 9:07 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

The "Customizing the Windows Deployment Wizard" section begins on page 288.

/ Johan

By Arwidmark on   3/19/2014 9:12 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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 7 x64 to HP machines.

My ideal setup would be a production environment that always works. It's tested and no changes are made until it's been determined that nothing that already works will break when changes are made. Then a testing environment where potential changes could be verified, then pushed or replicated to production. I'm fairly new to the deployment game, so I'm trying to figure if linked deployment shares or something else will do what I'm envisioning.

My end goal is to avoid breaking anything in production as I can't afford the downtime while I sort out bringing new models into the fold.

Thanks for this site (and the deployment fundamentals books) and for any insight available from anyone out there.

- Chris

By absentspace on   3/21/2014 10:51 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

For me the per model approach (total control) has worked the best, and that method also make sure that just because you add or update drivers for another model, you don't break anything else.

/ Johan

By Arwidmark on   3/30/2014 11:24 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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. But because of this, it would copy all drivers creating duplicate drivers into MDT and when the task sequence would inject drivers it would inject multiple of the same driver because it would rename the driver in some instances up to 30 times which greatly increased the time to deploy an image. The team I am apart of doesn’t like using MDT because of this. They are used to using imagex to capture an image and setting up an image on WDS which puts us over 20 something images that they are trying to manage. They are slow to stop using it because as of now, using WDS in this way is faster than imaging with MDT. I hope to resolve this by up my first MDT Server using Server 2012 and MDT 2012 update 1 and setting it up correctly.

We have several different models of dell desktops (optiplex gx520, 745, 755, 760 and 780) and laptops (D530, E5500, E5510, E5400 etc.) which are all Dell. The dell cab site has most of these models grouped together due to the models using most of the same drivers and being older machines. However,we are starting to get some newer machines (XPS13 and OptiPlex 7010).

My question is, can I setup total control for some of my models and then have a query for the others? A folder just named Latitude or OptiPlex and put all my drivers in there and then create a: WMI query SELECT * FROM Win32_Computer System WHERE Model Like ‘%Latitude D530%’ and point them to those specific folder and place multiple queries in the same inject driver sequence? Also can I create multiple DriverGroups? Like DriverGroup001 = Windows 8 x64 and Drivergroup002 = Window 7 x64 in the same deployment share? Also do I need to state that in the customsettings.ini?
DriverGroup001=Window 7 x32\MakeAlias%\%ModelAlias%
DriverGroup002=Window 7 x64\MakeAlias%\%ModelAlias%
DriverGroup003=Window 8 x32\MakeAlias%\%ModelAlias%
DriverGroup004=Window 8 x64\MakeAlias%\%ModelAlias%

Or would it be better for the time being to just use added predictability due to the amount of different machine types?
Thanks!
Corey

By Babagunoosh on   4/2/2014 12:04 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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 says import even if there is already another copy in the database, you will use the same drivers. If your driver is newer, it will copy in and you will be ok.

I had that issue with Lenovo Thinkpads. The T430 network and video drivers were overwritten by the T440. Once I broke everything up (which actually took less time) I no longer had any issue.

My OOBE directory structure looks like this for my devices (wish I could attach pictures, abbreviated):
Out-of-Box Drivers
-Win7
-Lenovo
-ThinkPadT430
-ThinkPadT440
-Hewlett-Packard
-HP Compaq Pro 4300 SFF PC
-HP Compaq Elite 8300 SFF
-Server2008R2X64
-Hewlett-Packard
-HP ProLiant DL380p Gen8 Server
-WinPE x64

The names for each model come from checking the ZTIGather logs on each new machine. I get most of my updates from UpdateRetriever and the HP SPP downloader.

By aillian on   4/11/2014 10:56 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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

By aillian on   4/11/2014 10:58 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

If you want additional intelligence for model naming including Lenovo naming, check out the modelaliasexit.vbs script, originally written by the deployment guys. We also added an updated version to our Deployment Fundamentals Volume 4 book (shameless plug)

/ Johan

By Arwidmark on   4/12/2014 1:00 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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.

By klarion on   4/14/2014 8:36 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Hi Klarion,

First of all, there should be no need to ask for a drivergroup, but if you really want to add a custom pane (or modifying an existing) it takes a little bit of scripting... Here is a good post that is also valid for MDT 2013: blogs.technet.com/b/mniehaus/archive/2012/01/07/customizing-wizards-with-mdt-2012.aspx

You can also find some info in the Deployment Fundamentals - Volume 4 book.

/ Johan

By Arwidmark on   4/16/2014 2:23 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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.

By klarion on   4/16/2014 7:27 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

I have set up MDT for many customers using Lenovo, and when using the modelaliasexit script most Lenovo model problems goes away.

That script converts the Lenovo models into useful models, for example the "4178381" correctly translates into a "ThinkPad T420", and then I use the "ThinkPad T420" structure in the workbench.

/ Johan

By Arwidmark on   4/16/2014 7:37 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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.

By klarion on   4/16/2014 7:46 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Well, prompting won't make it easier for you in my opinion, better to fix the structure and use the modelaliasexit.vbsc script. Or to use additional WMI filter targeting drivergroup settings...

If you still want to pursue the wizard thing, the link I sent should help you.

/ Johan

By Arwidmark on   4/16/2014 8:58 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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!

By klarion on   4/16/2014 12:10 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

ETA for Vol 5 is about a month :)

/ Johan

By Arwidmark on   4/17/2014 1:29 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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 deployment share has x86 platform support unchecked does that prevent these x86 drivers from getting imported into the driver store? If not, is it safe to delete individual drivers that only have x86 platform support from out-of-box drivers? The last question has been bugging me for a long time, but I haven't been able to test the effects of doing so.

By hendrixs on   4/22/2014 12:46 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Normally you need both x86 and x64 since they are used also for refresh scenarios. As for bare metal deployment (except UEFI) an x86 boot image can deploy both x86 and x64 images, where as the x64 boot image can only deploy x64 images.

Shorthand, for bare metal deployments, if you only deploy x64, you only need an x64 image.

As for the dell cab files, you can do some house-cleaning before importing or after importing, it doesn't really matter even though I prefer to delete the x86 drivers (if possible) before importing.

/ Johan

By Arwidmark on   4/22/2014 1:59 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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

By DanVega on   4/24/2014 12:50 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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 information the driver package number - is this possible?

By iburnell on   5/22/2014 12:40 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

I haven't tried running the command line separately, it might work, but it would most likely be unsupported, and you might have to reference the packages in the task sequence anyway. I normally just add the driver packages to the task sequence with conditions.

/ Johan.

By Arwidmark on   5/22/2014 11:20 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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.

By davidlink on   6/5/2014 1:06 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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?

By RickB on   6/8/2014 2:34 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

In ConfigMgr 2012 you use driver packages (instead of drivegroup), but yes, each package can (and should) have a condition to apply for a specific model.

/ Johan

By Arwidmark on   6/9/2014 2:35 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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?

By RickB on   6/14/2014 10:07 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

For ConfigMgr you don't use the DriverGroup variable, you use conditions on each driver package that you add to the task sequence.

Check this video recording for details:

A Drivers Saga: Mastering Windows Deployment
channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WCA-B301

/ Johan

By Arwidmark on   6/16/2014 1:25 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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

By pitchdown on   6/20/2014 9:21 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Added:
the missing drivers are :

ven_8086@dev_0F31@SUBSYS_06031028
ACP\INTCF1A\1
ACPI\DLAC3002\3&36B2D927&0
ACPI\INT33FB\1

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?

By pitchdown on   6/20/2014 9:51 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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?

By RickB on   6/24/2014 4:27 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Pitchdown, try configure the inject drivers action to stage all drivers in the selection profile, and not the default pnp-id detection behaviour. Otherwise check dism.log and setupapi.dev.log.

/ Johan

By Arwidmark on   6/24/2014 4:33 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

RickB,

Check this video: Most is still valid...

Inside Panther: Troubleshooting the Windows Setup Engine
channel9.msdn.com/events/TechEd/NorthAmerica/2011/WCL401

/ Johan

By Arwidmark on   6/24/2014 4:35 PM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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 \OS\Platform\Model. 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, Default
Properties=MyCustomProperty

[Vostro 260s]
DriverGroup001=Windows 7\x86\%model%
DriverSelectionProfile=nothing


[HP ProBook 6455b]
DriverGroup002=Windows 7\x86\%model%
DriverSelectionProfile=nothing

The HP when deployed does not inject any drivers. I used the blog at blogs.technet.com/b/askcore/archive/2013/05/09/how-to-manage-out-of-box-drivers-with-the-use-of-model-specific-driver-groups-in-microsoft-deployment-toolkit-2012-update-1.aspx to get the setup and configuration steps. I'm stumped as to why my drivers won't install. Could you possibly provide some help?

By yhttech on   7/2/2014 7:31 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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.

By RickB on   7/6/2014 4:13 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

Nope, you cannot nest task sequences. However, if you have them open side-by-side, you can easily just copy and past actions between them.

/ Johan

By Arwidmark on   7/6/2014 8:24 AM
Gravatar

Re: MDT 2013 Lite Touch Driver Management

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 Preinstall\Inject Drivers section, how and where deployment process can use my variable DriverGroup001 ?
4 - Can i do the same configuration in the post installation section ? (or both ?)

I tried with a VM (x64) but it seems don't install driver. For my test, i just follow your process for Scenario#3 with OOBE "Windows 7 x64\VMware Virtual Plateform" and imported all the vmware drivers.
After installation i always have a non recognize device which i can update with drivers present in my OOBE "Windows 7 x64\VMware Virtual Plateform"

Thanks for your great works !


By Keke on   7/17/2014 2:17 AM