ConfigMgr 2007 Driver Management: The Novel, part 2

In the previous posting at, 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 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:

  • For each OS and platform folder:

    • Create or retrieve the platform-specific driver package (if you don’t want model-specific packages)

    • For each model folder in the current folder:

      • Create or retrieve the model-specific driver package (if you do want model-specific packages.)

      • Create or retrieve a category name that matches the OS, platform and model (e.g. “XPx86-LatitudeD610”).

      • For each driver folder in the model folder:

        • Import the driver.  If an error is generated because of a duplicate driver, find the duplicate driver and process it instead.

        • Add the category to the selected driver.

        • Add the driver to the driver package.

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.

Comments (6)

  1. Anonymous says:

    No, you would need to strip the "release.dat" file from the extracted CAB file contents before importing the drivers into ConfigMgr.

  2. davidpyu says:

    Does this script include logic to look for release.dat file that defeats the duplicate detection so that it does not import these drivers that are really duplicates. You mentioned in the first post that this logic was added to MDT 2010, but is it added to this script?

  3. Anonymous says:

    As we were going through our TechEd North America deployment pre-conference today, we showed a lot of

  4. Anonymous says:

    Pingback from Material de apoyo usado en la preconferencia de TechED NA 2014 (deployment??s) + links de interes – Freelance-IT Ags, Mex.

  5. Anonymous says:

    Pingback from Michael Niehaus Notes from TechEd North America | What have I learnt today?

  6. aw says:

    hai, I just want to tell you that I am just very new to blogs and seriously loved this website. More than likely I’m planning to bookmark your blog post .
    You amazingly come with really good posts. Thanks a lot for sharing your blog Microsoft.