Scripting the Download and use of HP DriverPacks in MEMCM

Managing Driver Packs as Software in a MEMCM environment

A useful method for managing driver packs under Microsoft System Center Configuration Manager (CM) was described by in his blog: The goal is to help IT organizations, like his own, be better equipped to handle the seemingly endless task of maintaining Personal Computers in an enterprise during imaging and updating efforts

The technique described in the blog and accompanying script provides a method for insulating drivers (and driverpack) management from CM. By isolating the packaging of driver packs processing from CM’s driver database, it allows for a more efficient process for adding and removing devices from the environment.

The objective is to remove all Driver processing from a OS Deployment Task Sequence (TS) and instead add those driver injection steps that to a separate TS,  Driver Package Module. This TS is isolated and is the only one that needs to be modified for injecting drivers into a deployment task, and allows the deployment Task Sequence to just have the necessary steps to image the client device, without regard of the system being imaged. There is a second TS (Driver Injection Module) with 2 steps, a call to the Driver Package Module TS, and a 2nd step to run DISM on the client to inject the drivers on the client. Yes, these could be combined into a single TS, but I wanted to keep the original method intact, so both Task Sequences are used with the updated script as well

Once in place, all the OS Deployment TS needs to do is to invoke the Driver Injection Module Task Sequence at the end of the OS wim deployment group

The script in this blog can create both Task Sequences. You can see them below

( The source code for the script is available from GitHub: )

Task Sequences used  by Script

Based on Gary’s script, the technique was extended to automate more of the steps required to manage the driverpacks in CM. NOTE that in order to automate the creation and setup of the 2 Task Sequences, MEMCM version 1906 or later is required. MEMCM1906 introduces new cmdlets that we use for our purpose. Specifically, the New-CMTSStepRunTaskSequence cmdlet.

The script is also updated with a Gui interface completely developed in PowerShell.

In the scripts, all activities performed are shown within the GUI and also written to a log file.

Updating the Initialization file

The script requires a few modifications to point to the user’s environment. To make it easier to maintain, the CM_Driverpack_ini_2.0.Ps1 file contains all the items that can/should be modified. This file is added during runtime by the main script. An example is listed next

Variables that can be modified and used by the Downloader script are:

  • $OSVER - Default OS version the tool will work on
  • $OSVALID - What versions of the Windows 10 are ‘allowed’ to be reported on
  • $HPModelsTable - list of HP products in the environment, including ProductID and full name
  • $CMSiteProvider - this is pulled by the installation so there is no need to modify
  • $FileServerName - the MEMCM File Server, also obtained from the MEMCM installation
  • $DownloadSoftpaqDir - the path that will hold downloaded HP Softpaqs
  • $ExtractPackageShareDir - the share that the MEMCM agent will use pull in the source drivers
  • $LogFile - where the log file will reside for the script - default is the location of the script

Here is a test file content:

File: CM_Driverpack_ini.ps1

    Modify the entries to suite local requirements

$OS = "Win10"
$OSVER = "1903"                              # WITH VER 2.22, this is the default
$OSVALID = @("1809", "1903", "1909")

$HPModelsTable = @(
	@{ ProdCode = '8438'; Model = "HP EliteBook x360 1030 G3" }
	@{ ProdCode = '83B3'; Model = "HP ELITEBOOK 830 G5" }
	@{ ProdCode = '844F'; Model = "HP ZBook Studio x360 G5" }
	@{ ProdCode = '83B2'; Model = "HP ELITEBOOK 840 G5" }
	@{ ProdCode = '8549'; Model = "HP ELITEBOOK 840 G6" }
	@{ ProdCode = '8470'; Model = "HP ELITEBOOK X360 1040 G5" }

# this line assumes the script is running on a system with MEMCM installed, so its PS modules are loaded
$CMSiteProvider = Get-PSDrive -PSProvider CMSite          # assume CM PS modules loaded at this time
$FileServerName = $CMSiteProvider.Root               

$DownloadSoftpaqDir = "\\$($FileServerName)\share\softpaqs"
$ExtractPackageShareDir = "\\$($FileServerName)\share\packages\HP-"

$LogFile = "$PSScriptRoot\HPDriverPackDownload.log"       # Default to location where script runs from

The ProdCode in the HPModelsTable is the computer’s SysID, or Product ID. HP marks every model with a 4-digit hex code and the code is never changed for that model, and can be relied on. The Product ID can be obtained in a variety of ways:

  • Each driver Softpaq has a text file similarly named .CVA, which acts like a .INI file. It is created and updated as the Softpaq (BIOS, driver, software, etc.) is QA’d and tested. The CVA file holds the ProductID for each model supported by the Softpaq. So, a Softpaq sp99111.exe will also have an accompanying file named, sp99111.cva

  • With the WMIC app: 

    • wmic baseboard get product

  • In PS, with a WMI call: 

    • get-wmiobject win32_baseboard).Product

  • or with the HP Client Management Script Library: 

    • get-hpbiossetting 'System Board ID').value

    • Get-HPDeviceProductID. 

The CMSL is required for use of the script and can be obtained at the HP’s Manageability website:

Creating the Task Sequences

After making the appropriate modification to the ini.ps1 file, the Task Sequences can be created by selecting ‘Setup CM Task Sequences’ from the menu and pressing GO… The script will check if the TSs are already in place, and if not, will recreate them. 

The "Driver Package Module" will contain a group but be empty otherwise. Drivers download steps will be added when selecting the Download option in the menu. Each Download Package step added will consist of a package pointing to the driverpack source and information where to copy the contents to on the client. Each of these steps is created with the correct WMI selection for the system being imaged.

The "Driver Injection Module" is developed complete by the script and does not need to be modified again. It contains 2 steps. The first step calls out the previous TS, and the second step runs DISM on the client to inject drivers from the folder copied by the Package Download

The 2 Task Sequences (as created by the script) are shown below:

The DISM command used in the second step:

CM_Driverpack_Downloader script

As previously mentioned, this script is an expanded version of the original from GARYTOWN.COM. I moved much of the code into functions that can be more easily edited and updated. In the Update_SoftpaqFolders function I added an XML file version check to confirm if the current driver pack folder is the same as the version available from HP as a Softpaq download

For those users who prefer the use of customized Driver Packs such as those created by HP Image Assistant, the script function Update_SoftpaqFolders could be modified to handle this use case, instead of checking for a new version of the DriverPack Softpaq from HP. HP Image Assistant can be used to create Driver Packs for supported HP Business systems and supported Windows versions and is available on HP’s manageability website, at

When the script executes, ir displays the contents of the ini.ps1 file on the GUI, including CM’s path, the default OS version (1903 in the screenshot below), and the list of HP system names and product IDs the user is interested in.

In the HP Models table, the following fields will be filled in by Report or Download:

Available: what HP Softpaqs are available for the model and OS being looked at

CM Ver: If already in MEMCM, what version of the DriverPack is listed in the Software Package

OS Ver: what version of the OS is in the MEMCM Software Package

CM Package: The ID of the Software Package

Step: a checkmark if the Software Package is already in the Task Sequence, ready to use

The script does some basic checking to make sure CM is available and the download and share paths exist. If any of these tests fails, no other command will succeed


When Report is chosen, for every model in the list with a checkmark selection, the script uses an HP CMSL command to find a DriverPack that matches the Windows 10 OS version. If one is found, it will show a) if the Softpaq is already downloaded and available, b) if the expanded drivers are in the correct folder in the share path, and c) if MEMCM has a Software Package associated with the driverpack. It also checks for a step in the Driver Package Module Task Sequence

If the CM Software Package points to a source in the share of a different OS version, a red version #  will indicate the discrepancy. Meaning, there is a newer/different version available from HP than what is configured in CM

By the same token, if a previous download update the Software Package in CM for one version, and we are checking for a different version, the ‘OS Ver’ cell will be brown, indicating such discrepancy

Both are shown below, including the fact that the current Task Sequence only has 2 of the Software Package steps ready to use for imaging in the Driver Package Module TS:


Selecting Download will do all the checks done by Report, but will also download any newer Driverpack Softpaqs available for each model and OS version, if necessary. The script will also update the Software Packages as needed and add a step for each Software Package if not already in the Task Sequence.

DriverPack softpaqs are several hundred MBs and the script assumes that if it is downloading a Softpaq, it will complete. More checks are probably needed, but currently, after a Softpaq is downloaded, it is executed for unpacking to a TEMP folder, and the contents are then moved to the CM share it is assigned to. If the Softpaq download fails, the file will be executed and then fail with a PS error message. The recourse is to delete it, and try again.

The Windows OS version to Report on/Download for, is defaulted from the ini.ps1 initialization file. It is, however, editable, and you can switch from, say 1903, to 1909 without restarting the script. If, the, 1909 becomes the new standard, you can make that change in the ini file for future uses.



Author : dan.felman

is there an interest in having driver packages, once added to SCCM, be moved to 'folders' according to the OS version? for example, if a driverpack package points to a Windows 10-1909 version, would it make sense to move the SCCM PackageID under a 1909 folder? by default, creating a Software application package is added in the 'Packages' root folder

In version 2.30 ( available at ), the script enables a new feature to move/post driverpack packages in SCCM/SECM to folders named after the Windows 10 OS version it belongs to