Partager via


MDT 2010 New Feature #19: Improved Driver Management

I’ve been distracted while we worked on fixing the remaining bugs in MDT 2010, which was finally released today.  Now it’s time to get back to the discussion on new features in MDT 2010.  Next up on the list: improved driver management.

This is really a combination of two features we had already discussed:

with some capabilities added in that we haven’t already discussed.  First, there are new options available in a Lite Touch task sequence’s “Inject drivers” step:

image

Now there are two options when injecting drivers:

  • Inject only matching drivers from the selection profile.  This is the same behavior as MDT 2008, injecting all drivers that matched one of the PnP IDs on the computer.
  • Inject all drivers from the selection profile.  This is new (and roughly corresponds to the similar behavior that is available with a ConfigMgr “Apply Driver Package” step).  Instead of only injecting matching drivers, this injects all the drivers in the selection profile.

You might choose the first option, you might choose the second – it just depends on how you want to do it.  You might also choose to do both: you could create multiple “Inject driver” steps and specify different options and different selection profiles on both.  For example, you might have one “always apply” selection profile with all the printer drivers that you support (whether currently attached or not) and an “only matching” selection profile for everything else.  You could also set up multiple steps and place conditions on them, using different selection profiles and injection options based on the conditions (e.g. make and model).

Of course, if you want the process to be more dynamic, you can override the settings on the fly.  I would foresee this being a very common scenario, where you either specify a different selection profile on the fly, or maybe instead specify a list of folders that should be used.  To do this, you need to understand the available task sequence variables that can be configured through CustomSettings.ini:

  • DriverSelectionProfile.  This can be used to override the selection profile configured in the “Inject drivers” step, e.g. changing the default selection profile to “Lenovo T61p Drivers”.
  • DriverGroup.  This is a carry-over from MDT 2008, although now you can specify a folder path in order to select subfolders.  For example, if you created a “Toshiba” folder with a “Tecra M400” folder under it, you could specify “DriverGroup001=Toshiba\Tecra M400” or even “DriverGroup001=%Make%\%Model%”.
  • DriverPaths.  This is a carry-over from BDD 2007 (and before) provided for compatibility only.  It allows you to specify UNC paths containing the drivers to be injected, e.g. “DriverPaths001=\\Server\Share$\Toshiba\Tecra M400” or “DriverPaths001=\\Server\Share$\%Make%\%Model%”.  Because this requires carefully controlling the physical storage of the drivers instead of the logical grouping through folders in the Deployment Workbench, this is frowned upon.  Support for this may be removed in a future release.

It’s important to understand that these parameters have an “additive” effect.  For example, if you specify a selection profile of “Everything” (all folders) and then specify “DriverGroup001=Toshiba\Tecra M400” the net result will be everything.  But if you specified a selection profile of “Nothing” (no folders) and “DriverGroup001=Toshiba\Tecra M400” then the result would be just the one folder you specified.  (DriverPaths values would be additive as well, but those aren’t recommended.)

So you have options.  You can create multiple selection profiles and choose which one to use dynamically, something that gets messy if you just want one folder per selection profile (e.g. per model) since every new folder would require a new selection profile.  Or you can choose the “Nothing” selection profile and then specify one or more folders via “DriverGroup”.  I believe that will be the most common approach, as you can then do things like:

DriverSelectionProfile=Nothing
DriverGroup001=%Make%
DriverGroup002=%Make%\%Model%
DriverGroup003=Peripherals

If you’ve already experimented with this and have some best practices to share, comments about challenges while implementing this, or just general questions, feel free to e-mail me at mniehaus@microsoft.com.