In the previous posting at http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx, I mentioned that it should be possible to script the importing of drivers into the ConfigMgr driver store to help implement the “Added Predictability” (driver categories) and “Complete Control” scenarios by solving the duplicate driver import challenge using PowerShell. So that’s the whole purpose of this posting.
Regardless of whether you want to use driver categories or driver packages, the same logic can be used to import drivers into the ConfigMgr driver store. This assumes that you have your physical driver store arranged appropriately, using Johan’s blog at http://www.deployvista.com/Home/tabid/36/EntryID/82/language/en-US/Default.aspx as an example of how to do that. The attached scripts really take it further than just a recommendation: it’s a requirement for the script to work. The script assumes that you will have a structure that looks something like this:
You can extract the script file from the Zip file attachment on this blog entry. You can place the ImportAllDrivers.ps1 script wherever you like, but the SCCM.psm1 module must be placed where PowerShell can find it; see the comments at the top of that script for more details.
The ImportAllDrivers.ps1 PowerShell script needs to be modified to specify the UNC path of the physical driver store (it must be a UNC) and the UNC path where the driver packages should be placed (package source folders that should be created). You also can specify whether to create driver packages by OS platform (e.g. “XPx86”) or by OS platform and model (e.g. “XPx86-LatitudeD610”). If you want to use “Apply Driver Package” you’ll want packages per model.
So in the script, edit these three lines as appropriate:
$driverStore = "\\mdt-r2-sccm\DriverStore"
$modelPackage = $false
$packageSource = \\mdt-r2-sccm\Packages
The flow of the script is then like this:
Assuming everything works properly, when this script is complete you can then add the necessary steps to the task sequences (either “Auto Apply Drivers” steps with one specific category selected in each and conditions on each, or “Apply Driver Package” steps with a different package on each and conditions on each), distribute the new driver packages to the needed distribution points, and you’re set to go.
As I mentioned in the session, this script can be run multiple times and should be able to pick up any new folders or drivers added. But it doesn’t contain any logic to remove extra folders or drivers – that’s still going to be a separate effort.
Also, don’t expect the script to run quickly – the process of hashing all the drivers and then copying them into the driver packages takes quite a while. In my test VM which has drivers for about 20 different models of machines (which haven’t been cleaned up much at all) the script runs for hours. If you think about it, you would typically never process that many drivers at one time – you would do this incrementally, probably one model at a time. So the script is not really running that slow – it’s just doing lots of work.
That actually points out another effort that this script doesn’t help with: Cleaning up the physical store. For example, when I downloaded some “Windows 7 x86” drivers from the vendor’s web site, I also got x64 drivers that I might not have needed or already have downloaded separately. I also got Windows XP and Windows Vista drivers that I might not need. And then there’s all the other garbage (Windows Installer 2.x installers, videos, documentation, Linux drivers, MS-DOS drivers, etc.) that can also be pruned from the directory tree. The end result of the downloads and extractions was 14GB of driver files (not including another 6GB from the actual self-extracting installers, but I threw those away), even though only about 10-20% of that is really needed. Maybe someday someone will write a script or tool to help with the management of the physical store too. That’s a much more complicated task though.