First published on TechNet on Apr 29, 2010
In the first part of this series, I talked about the three (well, four with Johan’s) approaches for managing drivers with ConfigMgr 2007. There’s actually another method that I didn’t mention so far (one that we briefly mentioned at the end of the MMS session):
-
“Treat them all as software”
-
In this scenario, you’ll basically not use the driver injection capabilities in ConfigMgr at all. Instead, you’ll install all the drivers using “Install Software” steps after the new OS is up and running. This assumes the images being deployed already contain all the needed network or mass storage drivers. (You could choose a hybrid scenario to handle these, more on that below.)
-
Pros:
-
Many drivers require software packages anyway (especially more complicated ones like wireless broadband cards, Bluetooth adapters, etc.), so this way the driver and the application get installed at the same time.
-
You don’t need to figure out how to extract the drivers, just how to install the package silently.
-
Cons:
-
You have to figure out how to run the driver installer silently. If you can’t figure this out, you need to repackage the driver (something that is something of an art form).
-
Some OSes (e.g. Windows XP) may prompt because of the missing drivers before the actual installation occurs.
-
If you put each driver into a separate package, you’ll end up with lots and lots of packages (see the part 1 posting for what challenges lots of packages presents).
-
If you combine the driver software into a single package, you’ll need to wrap all the installers so that a single script or batch file installs them all.
Honestly, I didn’t think anyone did this for all of their drivers, although I did expect to see this done for a few limited drivers (such as the more complicated ones I mentioned before). But I have found a couple of customers who do exactly this: every driver is installed as an application. Still, I expect that to be rare in the “real world”.
So that leads us to the topic of “hybrid scenarios” – you can mix and match these scenarios to address all of your driver needs, something I would strongly encourage. Imagine a task sequence that uses something like this:
-
“Apply driver package” for all model-specific drivers.
-
“Auto apply driver” for all miscellaneous drivers (e.g. printer drivers, smart card drivers, other USB drivers – things that will be found on random machines in the environment).
-
“Install Software” for drivers that are more easily installed with their software once the new OS is up and running.
See Chris Nacker’s blog posting at
http://myitforum.com/cs2/blogs/cnackers/archive/2010/04/09/configuration-manager-2007-r2-sp2-dr...
for a real-world example of how you might set up something like this.
In the session I also showed a simple script that created driver packages pointing to existing folders in the driver store, to quickly set up “Johan’s Control Freak Method”. That script was basically the same script as attached to the previous blog posting, with all the logic for importing drivers into the driver store stripped out, since that logic isn’t used in Johan’s scenario. That script, named CreateJohanDriverPackages.ps1 (which still depends on the SCCM.psm1 module), is attached to this blog posting.
Johan has also added a new blog posting detailing the MDT 2010 Lite Touch scenarios, which you can find at
http://www.deployvista.com/Blog/JohanArwidmark/tabid/78/EntryID/132/language/en-US/Default.aspx...
.
A few other random driver-related items that may be of interest:
CreateJohanDriverPackages.zip
