Partager via

ConfigMgr 2007 Driver Management: The Novel, part 2

  • Article

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

\\SERVER\DriverStore\XPx86\LatitudeD610\…

\\SERVER\DriverStore\XPx86\LatitudeD630\…

\\SERVER\DriverStore\Win7x86\LatitudeE6410\…

\\SERVER\DriverStore\Win7x64\HPxw8400\…

etc.

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.

ImportAllDrivers.zip

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    May 11, 2011
    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?

  • Anonymous
    May 11, 2014
    The comment has been removed

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

  • Anonymous
    May 13, 2014
    The comment has been removed