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.)
- 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.
- 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-driver-management.aspx 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:
- Roger Zander posted a blog post at http://myitforum.com/cs2/blogs/rzander/archive/2009/08/07/apply-xp-massstorage-drivers-from-sccm-osd-task-sequence.aspx that talks about how to handle Windows XP driver models using “Apply Driver Package” and PnP-related WMI queries. Johan mentioned this scenario during the session. (I suggested that this be used to handle exceptions: include all the mass storage drivers in your Windows XP image, and use this capability to handle new mass storage drivers that have to be supported before your next scheduled image update.)
- See http://scug.be/blogs/sccm/archive/2009/03/03/sccm-2007-best-practice-importing-drivers-part-2-importing-a-driver-into-the-sccm-database.aspx for Kenny Buntix’s tips on how to manually find the duplicate driver that’s already present in the ConfigMgr driver store. The basic process: add more columns to the default driver list display so that it’s easier to find drivers with the same INF name. (People often forget that the ConfigMgr console shows a subset of the columns by default; you can add these fairly easily.) There are actually four parts in his series, so don’t stop with just part 2 either.
- Another example of how to do WMI filters on driver injection steps can be found in Vitalie Ciobanu’s blog posting at http://systemmanagement.ro/blog/2009/05/22/install-drivers-by-computer-model-using-wmi-query/.
- The University of Minnesota has posted some details on the driver management process they use, based on Johan’s Control Freak Method, at http://www1.umn.edu/umnad/current/SCCMDriverManagement.pdf.
- I had a good discussion at MMS with Rob Olson about the DudeWork’s DeployExpert add-on for ConfigMgr 2007, which has an “Advanced Driver Management” feature. This feature tries to take care of many of the ConfigMgr driver management pains, including driver “harvesting”, management of the physical driver store, driver category and driver package assignment, etc. This should be an interesting ConfigMgr add-on to keep an eye on. Read more at http://www.dudeworks.net/Products/Deployexpert/tabid/293/Default.aspx.