Modern Driver Management
Modern Driver Management (not to be confused with MDM, 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.
Changes: Updates to the code that deals with BIOS downloads. Updates to the HP BIOS download parsing code due to XML formatting changes
Changes: Lenovo Update - Important: Package name will no longer include the SKU value in the package name.
Processing updates and minor tweaks.
Changes: Updated to use new GetCWVersion method for 1.5.0 and later of the ConfigMgr web service
Changes : Changed existing package method detection for standard and driver packages
Fixes: Typo Corrected
Added MDM/MBM diagnostics tab for testing connectivity to the ConfigMgr WebService
Fixes : Fixed issue with scheduled task button not running function
- 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
The ConfigMgr WebService has been designed to extend the functionality of Operating System Deployment with Configuration Manager Current Branch.
- Inconsistency in parameter positioning has been addressed. The secretKey parameter is now required as the first parameter for all methods.
- GetCMPrimaryUserByDevice has been renamed to GetCMPrimaryUserByDeviceName.
- AddCMComputerToCollection now requires a device collection ID instead of the device collection name.
- GetCMOSImageVersionForTaskSequence and GetCMOSImageArchitectureForTaskSequence now detects the proper information based upon the selected image index in the task sequence. This fixes a bug for when e.g. using a custom image that contains more than a single index or for Windows 10 version 1709 that changes the order of the indexes.
- RemoveADComputerFromGroup now supports groups that contains more than 1500 members.
Microsoft Deployment Toolkit
Microsoft Deployment Toolkit
Modern Driver Management uses a custom built PowerShell script that is invoked during operating system deployment. This script automatically detects the manufacturer, SystemSKU (used instead of model), 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.
Version 3.0.0 (2020-03-14)
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.
Step 1 - 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:
Note: Remember to distribute the packages created by the Driver Automation Tool, unless you've specifically configured the tool to do that for you. For manually creating the packages, use the Driver Automation Tool to create a single package and follow the naming convention and including the different property configurations.
Step 2 - 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).
Step 3 - 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:
- 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: https://CM01.domain.com/ConfigMgrWebService/ConfigMgr.asmx"
- SecretKey - The secret key used to connect to the ConfigMgrWebService site
- Filter - Enter the term Driver or Drivers
- DeploymentType - This parameter is optional, and when not specified will default to the BareMetal type. Valid types include:
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.
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.
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.
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 "http://CM01.domain.com/ConfigMgrWebService/ConfigMgr.asmx" -SecretKey "12345" -Filter "Drivers"
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.
Validating 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:
Invoke-CMApplyDriverPackage.ps1 -URI "http://CM01.domain.com/ConfigMgrWebService/ConfigMgr.asmx" -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 "http://CM01.domain.com/ConfigMgrWebService/ConfigMgr.asmx" -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: