Home ยป Modern Driver Management

Modern Driver Management

Modern Driver Management (not to be confused with Mobile Device Management) combines new methods for driver management by extending the native capabilities of ConfigMgr. What this solution does, simply put, is to automate the download of driver packages from public system manufacturer web sites, creating packages in ConfigMgr, content distribution, dynamic driver package selection during operating system deployment and finally installation of drivers contained in the automatically detected package. All this with only a few clicks in the Driver Automation Tool (which can be set to run on a schedule), the ConfigMgr WebService and two simple steps in your task sequence.

Below are the required components that you would need in your environment in order to leverage this automated solution for driver management.

Driver Automation Tool

The Driver Automation Tool is a PowerShell GUI which automates the process of downloading, extracting, importing and distributing driver and BIOS packages. At present support is provided for Dell, Lenovo, HP and Microsoft client systems.

  • Fixed Lenovo download link logic and added further output
  • Updated package creation for all packages just to include the SKU/BaseBoard values
  • Updated link within the tool to GitHub as Technet is being retired
  • Updated custom package creation to include Windows 10 1909

  • Updated Dell Flash64w download location in order to download latest available build
  • Fixed UI elements not disabling in the admin control
  • Fixed OS selection on initial load not disabling Dell if the previous OS selection was a
  • Windows 10 build specific selection
  • Updated Find Model button to find but not select, and addded Find + Select button
  • Fix: Lenovo driver packages not extracting / creating correctly. This was due to a change in switches with Lenovo’s packaging tool.
  • Fix: Native driver package imports
  • New Feature: Support for zip compression of standard driver packages. To be used with an upcoming update to the SCConfigMgr MDM apply script.
  • NOTE
    Over the past few days it has been reported that the tool was being picked up as a virus. I have recompiled the installer as an MSI and uploaded. MD5 hashes are included.
  • Queries XML content from Dell, Lenovo, HP and Microsoft
  • Provides Driver downloads for all five manufacturers
  • Provides BIOS downloads for Dell, Lenovo or HP systems
  • Create a BIOS update package
  • Download driver package file for each model
  • Extract the drivers contained within
  • Import the extracted drivers
  • Create a category based on the machine model
  • Create a Driver Package based on the machine make, model and version of the extracted drivers
  • Import the associated drivers into the newly created driver package.  Options allow for either a standard program package or driver package to suit your deployment method
  • Create a Fallback Driver package based on vendor and operating system version

ConfigMgr WebService

The ConfigMgr WebService has been designed to extend the functionality of Operating System Deployment with Configuration Manager Current Branch. In Modern Driver Management, the ConfigMgr WebService acts as the interface between an executed task sequence and driver packages in ConfigMgr created with Driver Automation Tool.

General improvements

  • Improved a bug in the internal GetMDTComputerName method to only retrieve objects where the OSDComputerName property is not null.
  • Fixed a bug for Modern Driver Management when using two or more Apply Operating System steps in a Task Sequence, where one of them reference an OS Image (.wim) with a single index and the others reference an OS Image (.wim) with multiple indexes, and if the step with the WIM file containing multiple indexes are the first in sequence, the GetCMOSImageForTaskSequence method fails to match the ImageIndex with the ImagePackageID.
  • Fixed a bug where GetCMPrimaryUserByDeviceResourceId returned both Active and Inactive relationships. Method now only returns the Active relationships.
  • Changed internal code from using the LDAP:// protocol pointing to the Global Catalog instead which should better support multiple domain scenarios.

Configuration Manager

  • AddCMComputerAssociationForAllUsers

Active Directory

  • GetADComputerAttributeValue
  • GetADUserAttributeValue

General improvements

  • Improved error handling through almost all methods in ConfigMgr WebService is now available. Errors are now logged to the ConfigMgr WebService event log.
  • Method GetCMPrimaryUserByDeviceName no longer returns inactive UDA relations.
  • Method GetCMApplicationByCategory now excludes retired Applications.
  • New methods to support an upcoming release of a solution called ConfigMgr OSD Monitor is included in this release.

Configuration Manager

  • AddCMOSDMonitorData
  • GetCMCollectionByName
  • GetCMDeviceNameByMACAddress
  • GetCMDeviceNameByResourceID
  • GetCMOSDMonitorDataByUniqueID
  • GetCMOSDMonitorDataByComputer

Active Directory

  • AddADUserToGroup

Configuration Manager

  • GetCMOSImageForTaskSequence
  • GetCMDeviceUUIDByName
  • GetCMTaskSequence
  • RemoveCMDeviceByUUID
  • RemoveCMDeviceByName
  • RemoveCMDeviceByResourceID

Microsoft Deployment Toolkit

  • GetMDTComputerByName
  • RemoveMDTComputerBySerialNumber

Active Directory

  • GetADComputerDescription
  • GetADOrganizationalUnits
  • GetADDomain
  • GetADGroupMemberByComputer

Apply Driver Package script

Modern Driver Management uses a custom built PowerShell script referred to as the Apply Driver Package script, that is invoked during operating system deployment or driver maintenance. This script automatically detects the manufacturer, SystemSKU, operating system version and architecture being deployed and matches that information against the system being deployed in order to determine the matching driver package that should be downloaded.

  • Changed the translation function for the OS architecture of the current running task sequence into using wildcard support instead of adding language specified values.
  • Small update to the Filter parameter’s default value, it’s now ‘Drivers’ instead of ‘Driver’. Also added ’64 bits’ and ’32 bits’ to the translation function for the OS architecture of the current running task sequence.
  • Fixed a spelling mistake in the Manufacturer parameter.
  • Added TargetOSVersion parameter to be allowed to used in DebugMode. 
  • Fixed an issue where DebugMode would not be allowed to run on virtual machines. 
  • Fixed an issue where ComputerDetectionMethod script variable would be set to ComputerModel from SystemSKU in case it couldn’t match on the first driver package, leading to HP driver packages would always fail since they barely never match on the ComputerModel (they include ‘Base Model’, ‘Notebook PC’ etc.)
  • A complete re-written version of the script. Includes a much improved logging functionality. Script is now divided into phases, which are represented in the ApplyDriverPackage.log that will provide a better troubleshooting experience. 
  • Added support for AZW and Fujitsu computer manufacturer by request from the community. 
  • Extended DebugMode to allow for overriding computer details, which allows the script to be tested against any model and it doesn’t require to be tested directly on the model itself.

Implementation instructions

Download and prepare driver packages

For the approach to Modern Driver Management we need to populate ConfigMgr with regular packages for client machines. If you are running Dell, HP or Lenovo hardware then you can use our Driver Automation Tool to do exactly that. Read the documentation embedded in the download package for Driver Automation Tool for more information on how the tool can be utilized. For the Modern Driver Management solution, follow these instructions:

  • Launch the Driver Automation Tool and connect to your ConfigMgr environment by entering the name of your Site server, the Site code and click Connect To ConfigMgr in the ConfigMgr Settings tab. Additionally, specify the Package Storage Path to a location that will be used for the Package Source of each driver package the tool will create.
  • In the Common Settings tab, specify a path to where the Driver Automation Tool will download the source files for the driver packages.
  • We now need to select the Deployment Platform as ConfigMgr – Standard Pkg, then pick Drivers as the Download Type and pick your OS and Architecture.
  • In the Manufacturer section, select the vendors you wish to display models for and then hit the Find Models button.
  • Select the models from the list you wish to download packages for and click Start Download | Extract | Import button to start the driver package creation process.

Once downloaded you should end up with something like this in your ConfigMgr console:

Remember to distribute the packages created by the Driver Automation Tool, unless you’ve specifically configured the tool to do that for you.

Move on to step 2 when all desired driver packages have been created.

Install ConfigMgr WebService

Modern Driver Management solution requires the ConfigMgr WebService to be installed in your environment, with the minimum of version 1.6.0. Detailed installation steps can be found in the documentation included in the ConfigMgr WebService package, downloadable from above.

The web service is a key function to this process as it will be used during the task sequence to query the available packages from ConfigMgr (using the GetCMPackage method among other). We recommend that you install the ConfigMgr WebService on your primary site server, if possible.

Move on to step 3 once the ConfigMgr WebService has been installed successfully.

Configure your task sequence

Adding the required step in your Task Sequence for Modern Driver Management could not be simpler. Download the script called Invoke-CMApplyDriverPackage.ps1 from the Script Resources above. This script will automatically detect the computer model and manufacturer, operating system image version and architecture in the executing task sequence, by calling the ConfigMgr WebService for driver packages (read legacy Packages, not Driver Packages) matching those values. In the case of multiple packages that match the criteria, the most current package will be selected based upon the SourceDate property of the package object. If there are no matches at all, the script will exit, causing the deployment to fail. When a package matching the criteria required, task sequence variables used by OSDDownloadContent.exe will be set and that executable will be invoked. This automatically downloads the matching package for the model being deployed, making it available locally ready for driver injection by using dism.exe. Once the package is available locally, and the downloaded completed successfully, dism.exe will be invoked and inject the drivers. This script simply takes care of everything, and is the brains behind the modern driver management solution.

In the event of this script should fail, see the Documentation tab under Script Resources for a list of return codes that could be used for troubleshooting. In terms of logging, the script is writing to a separate log file called ApplyDriverPackage.log located in the same directory as the smsts.log file at the time of operation.

Follow this simple process of using the Invoke-CMApplyDriverPackage.ps1 script inside your task sequence:

  • Package the Invoke-CMApplyDriverPackage.ps1 script and distribute it to your Distribution Points.
  • Add a Run PowerShell Script command somewhere after the Apply Operating System step (make sure it’s executed during WinPE and not in the Full OS), calling the Invoke-CMApplyDriverPackage.ps1 script with parameters for the following:
    • URI – URL of the ConfigMgrWeb service – example:
    • SecretKey – The secret key used to connect to the ConfigMgrWebService site
    • Filter – Enter the term: Drivers
    • DeploymentType – This parameter is optional, and when not specified will default to the BareMetal type. Valid types include:
      • BareMetal – This is the default option and intended for a WinPE environment, using DISM to import and apply the matched driver package. Logs are saved into the log folder within the _SMSTaskSequence\Logs folder.
      • OSUpgrade – Intended for use as part of an in-place upgrade and uses the PNPUtil command to import the matched driver package. Logs are saved into the WinDir\Temp folder.
      • DriverUpdate – This switch is intended for use in a Full OS (Windows is running) environment. The PNPUtil command is also used in this method and logs are saved into the %SystemRoot%\Temp folder.
      • PreCache – Intended to only pre-cache the driver packages into the ConfigMgr client cache for future reference during Windows 10 in-place upgrade scenarios.


Invoke-CMApplyDriverPackage.ps1 -URI "" -SecretKey "12345" -Filter

Driver Update Maintenance

The same process described above can be used to maintain drivers for existing devices via the use of the DriverUpdate value when specified with the DeploymentType switch in the Invoke-CMApplyDriverPackage.ps1 script. An example of this is contained within the script under the examples section.

Validate a driver package for a specific model

New in version 3.0.0 (and above) of the Invoke-CMApplyDriverPackage.ps1 script, there’s now a way to validate the matching logic of any given vendor and model for driver packages created with Driver Automation Tool. Run the script on any device or server in the DebugMode supplying the required parameters for driver package validation:

  • TSPackageID
  • Manufacturer
  • ComputerModel
  • SystemSKU


Invoke-CMApplyDriverPackage.ps1 -URI "" -SecretKey "12345" -Filter "Drivers" -DebugMode -TSPackageID "P0100123" -Manufacturer "Dell" -ComputerModel "Precision 5520" -SystemSKU "1234"

Driver Fallback Package

The driver fallback package does exactly what it says. In the event that no matching driver packages are found, you can have a manufacturer specific driver package with multiple generic drivers contained within. The package should be created using the Driver Automation Tool (6.4.7 and up) and all you need to do is drop your extracted drivers into the package source location, then add the UseDriverFallback switch in the Invoke-CMApplyDriverPackage.ps1 script parameters on run time.


Invoke-CMApplyDriverPackage.ps1 -URI "" -SecretKey "12345" -Filter "Drivers" -UseDriverFallback


For troubleshooting there is an extensive log management process that runs during the execution of the script. Refer to the ApplyDriverPackage.log file for troubleshooting driver package issues during a task sequence execution.

If you require assistance, may have found a bug or simply have feature suggestions, report it on our GitHub repository:


Categories use cookies to ensure that we give you the best experience on our website.