Driver Management: What you are doing

Thanks to Rod, Chris, Reed, and others who helped encourage people to check out the driver management survey blog posting I made last night, I was quickly able to get over a hundred replies.  Now that’s what I call “instant feedback”.  So here’s the interpreted results based on that sampling.

For those of you using MDT 2010 Deployment Workbench and Lite Touch deployments, the breakdown looks nice:

So 21% just import all the drivers and let the system figure it which ones to use on each computer (not too bad when the number of models is smaller).  27% import all drivers and then use selection profiles to control which drivers to use (typically per OS).  And the majority of you are taking it even further and leveraging driver folders (DriverGroups), effectively becoming “control freaks”.

While no one said they were using the “install drivers using applications” as their primary mechanism for handling drivers using Lite Touch, over 30% of those using Lite Touch said they were installing at least some drivers as applications once the OS was up and running – basically implementing hybrid scenarios.

For those of you using ConfigMgr 2007, the breakdown is a little different:

So 9% import all their drivers and let the “Auto Apply Drivers” step inject the best one. 24% use “Auto Apply Drivers” with categories to better control which drivers are used.  The majority then use “Apply Driver Package”, with 39% importing the drivers into the driver store (the way driver packages were intended to be used) and the remaining following Johan’s approach (not importing drivers, creating driver packages pointing to the physical store).

So a lot of you are importing all of your drivers into the ConfigMgr driver store, but to make that work a significant percentage of you are purposely defeating the ConfigMgr duplicate driver detection by creating a unique file that results in a different has for every driver:

When you drill into the responses a little deeper, several of those that answered “manually handling duplicates” said that they were primarily Dell shops and were using the Dell driver CAB files.  As I mentioned in the MMS session, these CAB files include a unique “release.dat” file so they defeat the duplicate detection process, so they are unknowingly in the other category.  As a result, the percentages are probably flipped around, with the majority of customers preventing ConfigMgr from detecting duplicates.

So that means almost 60% of ConfigMgr OSD users are somehow working around the driver management challenges in the product (28% following Johan’s advice, and about half of the 63% that are using driver categories and driver packages and defeating duplicate detection, so 28+63*0.50=59.5).  I believe the PowerShell scripts I posted can help reduce this number, at least for OSD users willing to reconsider their approach, or new users just setting up their OSD driver management strategy.

As with Lite Touch, about 30% of ConfigMgr OSD users said they were installing some drivers as applications (packages).  But again this wasn’t the prevalent mechanism being used, it was being done for selected drivers as part of a hybrid scenario.

There are a variety of tools and sites being used to help with the driver acquisition/extraction process.  Johan talked about some of these, like 7-Zip, WinRAR, Universal Extractor, the Windows Update Catalog, and the HP Softpaq Manager, during the MMS session we presented.  Others that were mentioned in survey responses included DriverMax, Driver Magician (and the Lite version), DriverGrabber, and the Lenovo Update Retriever.  But still the majority of you are still using the manual download-and-figure-out-how-to-extract-without-breaking-your-computer method (the mechanism I was struggling with before MMS).

There was a good deal of praise for the Dell driver CABs, and quite a few calls for other OEMs and vendors to start providing the same type of simple download.  But many commented that the OEMs and vendors are still providing too much “junk” in their driver downloads, bloating drivers stores unnecessarily.

Many of you express frustration with mass storage drivers (probably a sign of how many of you are still using Windows XP, as these problems pretty much go away with later OSes).  Some of you have run into issues running driver installers during a ConfigMgr task sequence (usually a result of the task sequence running in SYSTEM context with no user profile loaded – these probably are usually the sign of an InstallShield installer that wants to talk to a COM server, but that can’t be used as COM isn’t yet fully initialized while the task sequence is running). 

A few of you would like tools to help with driver lifecycle management – helping with the driver store management, delivering driver updates to machines previously deployed, using tools like SCUP to help with driver deployment, making more OEM drivers available automatically through WSUS, etc.

Of course there were plenty of suggestions for things Microsoft could do to help and a few rather frustrated people who just want the whole problem to go away.  But there is a larger group (still in the minority for sure) that says they’ve got this process mastered.  Let’s hope they all start blogging with all the details of how they’re doing it

Overall, this does pretty much confirm what Johan and I were saying in our session:  here are the scenarios that you can consider; here are the pros, cons, and challenges you are likely to encounter in each scenario; here are the tools that can help.  Granted, even with a hundred responses this isn’t a statistically valid survey, but it at least gives you some idea of what’s going on in the real world.

As always, if you have any specific feedback or comments, you can e-mail me at mniehaus@microsoft.com or submit comments on this (or any) blog posting.