I can tell just starting out on this topic that it’s going to be a long one. For those of you who attended the session that Johan and I presented at MMS 2010, we talked about various ways of managing drivers, with Johan focusing on MDT 2010 Deployment Workbench (Lite Touch) and me focusing on ConfigMgr 2007 (Zero Touch). We focused on the whole range of possibilities, ranging from “total chaos” through “complete control freak”, mapping those into the capabilities provided by the product.
Since I focused on the ConfigMgr side of things in the session, I’ll focus on the same thing here. Basically, here’s how it maps out:
As we mentioned in the session, you will probably pick one of these scenarios as the “primary” one for your organization, but these can also be combined into “hybrid” approaches.
Historically I’ve always suggested that people use one of the first three mechanisms, but because of the way ConfigMgr handles duplicate drivers the second (“Added Predictability” with categories) and third (“Complete Control” with driver packages) are challenging, especially if you want to set those up by hand. Various people have proposed solutions around that, including articles like these and various newsgroup postings over the years: http://wbracken.wordpress.com/2009/09/26/adding-duplicate-drivers-to-sccm-sp1/
In fact, this is the same solution that Dell has implemented in their driver CABs available for download from http://www.delltechcenter.com/page/Dell+Business+Client+Operating+System+Deployment+-+The+.CAB+Files: They put a “release.dat” file into each driver folder (with different content, to change the directory hash) so that ConfigMgr doesn’t see any of the drivers as duplicates. That certainly solves the problem, but does it by defeating ConfigMgr duplicate detection process altogether. As a result, the ConfigMgr driver store will also end up being much bigger. That “release.dat” file also defeated the duplicate detection in MDT 2010’s Deployment Workbench, so we added explicit logic to look for that file and ignore it when calculating hashes. That way we see the duplicates again (which keeps our driver store as small as possible too).
OK, so how do you implement the “Added Predictability” and “Complete Control” scenarios without either going to Johan’s approach or defeating the duplicate detection (or doing it manually, a process that’s really hard to do as finding the duplicate manually won’t be easy)? That’s where the PowerShell scripts came in. As I discovered early last year when researching this topic, ConfigMgr knows which driver is the duplicate (obviously) and will tell you which one it is when you make the request via the ConfigMgr WMI provider (not so obviously) – you just don’t see that information through the UI. But with a script, you should be able to do something like this:
So the next posting will focus on that part: Using PowerShell to import drivers while handling the duplicates along the way.
Enough “driver babble” for now.