Deployment Artist


The site is finally put to rest...

You find new content on the Deployment Research site, a site filled with articles and video-tutorials on how to deploy operating systems. If you are missing something on the new site, please let me know. You can find me on twitter on my @jarwidmark alias.

You can also search the old article archive below.

Regards / Johan Arwidmark

 Blog_List Minimize

 Blog_Archive Minimize

 New_Blog Minimize
You must be logged in and have permission to create or edit a blog.

 They call me a control-freak... a drivers tale... Minimize
Location: BlogsJohan Arwidmark    
Posted by: johan 10/11/2008

Let me start by clearly stating that I really like (most) of the changes the MDT development team did for Lite Touch driver handling in Update 1 of MDT 2008. But, do I think the default driver injection mechanism works for all scenarios?

Not Really... Luckily, Lite Touch offers several methods for dealing with drivers :)

Background - Lite Touch and Drivers
The default driver injection mechanism in Lite Touch works with pnpid detection. You simply import the drivers into the deployment workbench, during import the workbench parses all drivers and builds a list of all drivers and their pnpid's (stored in drivers.xml).

When you deploy a machine,a component detects the pnpid of the hardware you actually are deploying to, and then matches those id's against the repository on the server. Best matching driver wins and is downloaded to C:\Drivers (to be injected later on).

Pros with the default behaviour are
- Easy to import drivers
- Works with most hardware

Cons with the default behaviour are
- Works with most hardware still means failing on some (certain soundcards in particular)
- Hard to maintain (updating, and removing drivers)
- When dealing with multiple OS's and Architectures it gets even worse

I prefer to use another method for driver injection

I build a separate folder structure and then configure my Task Sequence to use that one instead (using DriverPaths variables)

Pros with method are
- Always works, for all operating systems, architectures and hardwares

Cons with method are
- Consumes more disk space on the server
- Takes a few more minutes to setup

Step-by-Step Procedure

This sample assumes your deployment point is D:\Deploy, shared as Deploy$. In this example we add support for the HP Compaq 8510w model.

  1. Create the following directory structure


  2. For each Task Sequence, add the DriverPaths1 variable. Below is a sample for the VISTA X64 Task Sequence:

    Before the driver injection action, Add a Task Sequence Variable action with the following settings

  3. Find out the model name (WMIC CSPRODUCT GET NAME), and create the folder: D:\Deploy\Drivers\VISTAX64\HP Compaq 8510w
  4. Copy the Vista x64 drivers for that model to the above folder (create subfolders like below, etc.)

    D:\Deploy\Drivers\VISTAX64\HP Compaq 8510w\Nic
    D:\Deploy\Drivers\VISTAX64\HP Compaq 8510w\Audio
    D:\Deploy\Drivers\VISTAX64\HP Compaq 8510w\Video

Oh, You wan't to know about the headline background?  Well, I got that back (in writing) from a MDT Developer when presenting this solution...

 Who the devloper was? I would never reveal any names, but it begins with a M... :)

Permalink |  Trackback

Comments (4)  
Re: They call me a control-freak... a drivers tale...    By kingskawn on 12/9/2008
How can the machine sees it modelname? (%model%). There's no variable that tells him?
As a reaction on "%DEPLOYROOT%\Drivers\VISTAX64\%Model%"

Re: They call me a control-freak... a drivers tale...    By ibrazier on 2/3/2009
How do you handle hardware models, an IBM ThinkPad T43 for instance, that have Win32_ComputerSystem.Model set to something unique to that particular device, like part of the serial number? The command you give "wmic csproduct get name" pulls Win32_ComputerSystemProduct.Name, which appears to be identical to Win32_ComputerSystem.Model (at least on all the machines I've checked). The problem with using this method for the IBM ThinkPad is that the hardware platform type, ThinkPad T43, is listed under Win32_ComputerSystemProduct.Version, not Win32_ComputerSystemProduct.Name like a Dell or HP and it isn't listed anywhere under Win32_ComputerSystem. Just curious if you've run across this, and, if so, how you addressed it.

Re: They call me a control-freak... a drivers tale...    By Janke on 3/12/2009
Hello, you once wrote on a microsoft community chat:

I am installing drivers by driverpaths and created truncated folders like HP
Compaq dc7100 SFF because of the various HP model numbers. I tried Ben
Hunter's model-alias blog, but can't get this to work, does this require SQL?
My DRIVERPATHS1=\\server\share\%model%, so when it does a WMI it takes a
look at the complete model name and can't resolve the correct path. Is there
a way to install drivers and applications (the way you have listed below)
with a truncated path through CS.ini, or is the only way to create each
different model like HP Compaq dc7100 SFF(#####). Thank you.

And then you wrote that you worked it out, but not how. Could you please explain how you did this ?

Re: They call me a control-freak... a drivers tale...    By David on 3/17/2009
We have deployed numerous models, mostly HP/Compaq and Dell, of computers here. Recently received 30 Compac DC5800 MicroTowers; uses the Intel 82566 DM-2 Gigabit network controller. Cannot get the PE boot disk to access the network. Even created a boot disk with NOTHING but the DC5800 network drivers and it still can't find the card. How do we start the deploymeny when the boot CD won't recognize the network? HELP!!

 Search_Blog Minimize

Copyright 2006-2012 (c)   Terms Of Use  Privacy Statement
DotNetNuke® is copyright 2002-2017 by DotNetNuke Corporation