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