MSEndpointMgr

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 native AdminService 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 SKU values missing from packages
  • Added – HP SoftPaq package creation
  • Added – Windows 10 2004 support
  • Added – 7Zip support
  • Added – XML Logic Package support
  • Updated UI look and performance
  • 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

AdminService or ConfigMgr WebService

Since the release of ConfigMgr 1906, the SMS Provider includes API interoperability access over HTTPS, called the Administration Service, AdminService for short. This functionality allow for native access to resource in ConfigMgr using scripted solutions such as Modern Driver Management, without the requirement of custom web services such as the ConfigMgr WebService.

NOTE: Starting with Invoke-CMApplyDriverPackage.ps1 version 4.x and later, the AdminService is the supported method of interface between the script and ConfigMgr.

Using the AdminService requires a service account for Modern Driver Management to able to call the REST API. This service account should be provided least required permissions, meaning Read-Only Analyst in ConfigMgr. Refer to the implementation instructions below on how to setup the service account and enable the AdminService.

With the switch to the AdminService, being able to use the Modern Driver Management solution over the Cloud Management Gateway is currently not supported, however the Invoke-CMApplyDriverPackage.ps1 script from version 4.x and later has been has been prepared to support this, the dynamic method utilized by the solution isn’t currently supported by Microsoft. There are ongoing efforts from MSEndpointMgr.com towards Microsoft with the aim to enable the scenario in a future release.

For more information about the AdminService, read through the official documentation:

https://docs.microsoft.com/en-us/mem/configmgr/develop/adminservice/overview

NOTE: Using this method has been deprecated with the release of Invoke-CMApplyDriverPackage.ps1 script version 4.x and will not be supported going in future releases. Do not use this method, instead read the documentation for the AdminService part.

Only install the ConfigMgr WebService when using version 3.x or earlier of the Invoke-CMApplyDriverPackage.ps1 script, or when the AdminService cannot be used.

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.


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 upgrade and driver update maintenance. This script contains the main logic to automatically query for the appropriate driver package created using the Driver Automation Tool matching the current device model being deployed. A prerequisite for the Apply Driver Package script is a step of type ‘Set Dynamic Variables’ named e.g. Set MDM Variables that contains authentication values required for accessing driver package data through the AdminService.

NOTE: It’s recommended to use version 4.x or later of this script together with the AdminService. Version 3.x and earlier has been deprecated and will not be updated in the future with new functionality.

  • Fixed an issue where the ‘Confirm-SystemSKU’ function would cause the script to crash if the SystemSKU data was improperly conformed, e.g. with spaces as a delimiter or with duplicate entries
  • Fixed an issue where an improper variable name was used instead of $DriverPackageCompressedFile
  • IMPORTANT: From this version and onwards, usage of the ConfigMgr WebService has been deprecated. This version will only work with the built-in AdminService in ConfigMgr.
  • Removed the DeploymentType parameter and replaced each deployment type with it’s own switch parameter, e.g. -BareMetal, -DriverUpdate etc. 
  • Additional new parameters have been added, including the requirements of pre-defined Task Sequence variables that the script requires. 
  • For more information, please refer to the embedded examples of how to use this script or refer to the official documentation at https://www.msendpointmgr.com/modern-driver-management.

Implementation instructions

Follow the implementation instructions outlined within these tabs to successfully setup Modern Driver Management in your environment. These instructions are based on the latest version of the various components involved in the solution.

  • Step 1 – Driver Automation Tool and Driver Package creation
    • This step describes how to use the Driver Automation Tool for creating necessary driver packages for Modern Driver Management
  • Step 2 – AdminService requirements and service account setup
    • This step describes the requirements for setting up the AdminService built-in to ConfigMgr and the necessary service account required for authentication against the AdminService
  • Step 3 – Cloud Management Gateway support (optional)
    • This step describes an optional functionality available in Modern Driver Management for the OSUpgrade, DriverUpdate and PreCache scenarios. however BareMetal and XMLPackage scenario it not currently supported
  • Step 4 – Configure your task sequence
    • This step describes how Modern Driver Management should be configured inside existing task sequences
  • Step 5 – Additional functionality and troubleshooting
    • This step describes additional functionality like Driver Update Maintenance, manually validate driver package matching outside of a task sequence and contains a bit of troubleshooting information

If you have any questions about the process, or any feedback that could improve the solution, please reach out to us using GitHub, more specifically on this repository:

https://github.com/MSEndpointMgr/ModernDriverManagement

Step 1 – Driver Automation Tool and Driver Package creation

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.

Step 2 – AdminService requirements and setup

Modern Driver Management solution used to require the community developed ConfigMgr WebService, however is from now integrated with native functionality available in ConfigMgr, the Administration Service (AdminService for short).

Setting up the AdminService doesn’t require much work, and it has been well documented by Microsoft in regards to the prerequisites:

https://docs.microsoft.com/en-us/mem/configmgr/develop/adminservice/overview#prerequisites

Following with the documentation on how to fully set it up:

https://docs.microsoft.com/en-us/mem/configmgr/develop/adminservice/set-up

In short, if you’re running ConfigMgr 2002 or later, it’s likely that your environment is already configured properly since the AdminService is automatically bound with the Site’s self-signed certificate. If your security guidelines does not allow for using self-signed certificates, simply follow Microsoft’s documentation to bind a PKI-certificate instead in IIS on the server where the SMS Provider is hosted.

Service account for authenticating against AdminService

The AdminService is a REST API endpoint for accessing data from within your environment. To proper access this data, for instance driver package information created by the Driver Automation Tool, an authentication is required and for this Modern Driver Management requires a service account. It’s important to point out that this service account should be given the absolute minimum access required to ConfigMgr, which for Modern Driver Management is the built-in Read-Only Analyst RBA role.

We trust that you’re familiar enough with setting up a service account in Active Directory, so that process is not covered here. But in order to successfully be read driver package information from a running task sequence in ConfigMgr, the service account needs to be provided access to ConfigMgr under:

Administration – Security – Administrative Users, more specifically like shown below:

Move on to step 3 once the AdminService requirements and the service account have been successfully configured.

Step 3 – Setup support for Cloud Management Gateway (optional)

Modern Driver Management support several scenarios for managing drivers, such as BareMetal, OSUpgrade, DriverUpdate, XMLPackage and PreCache. Some of these deployment scenarios now works with the Cloud Management Gateway, more specifically the following:

  • OSUpgrade
  • DriverUpdate
  • PreCache

The configuration described in this step, is only optional though. If you don’t require support for clients being able to update drivers or inject new drivers during in-place upgrade of Windows 10 by communicating over the Cloud Management Gateway when outside of the corporate network, simply move a long to step 4 and do not configure anything below.

Cloud Management Gateway support requirements

Before you start following the steps below, make sure your environment is fulfills the following requirements:

  • Azure Service – Cloud Management have been setup (tenant onboarding)
  • Cloud Management Gateway successfully deployed
  • Driver Package contents distributed to content-enabled Cloud Management Gateway

Additionally, during the tenant onboarding a ‘ServerApp’ (let’s refer to it as ConfigMgr-ServerApp) app registration (also known as a Service Principle) was created in your Azure AD tenant, either manually or through the wizard in ConfigMgr. The Cloud Management Gateway is configured to use this app registration, so in order to successfully authenticate and communicate through the Cloud Management Gateway, we need to impersonate the ‘ServerApp’.

In the ConfigMgr console under Administration – Cloud Services – Azure Active Directory Tenants, you’ll find all app registrations in use by ConfigMgr. In the picture below, the ConfigMgr-ServerApp is the ‘ServerApp’ that exists in this environment:

You can verify which ‘ServerApp’ the Cloud Management Gateway is using by opening the properties window and checking the value for Azure AD app name.

Make a note of this ‘ServerApp’ name, in this case it’s called ConfigMgr-ServerApp.

Create Azure AD app registration

Instead of adjusting or make changes to any existing app registration in your environment, we suggest that you create a new with the sole purpose of being used for Modern Driver Management. With this app registration, we can successfully retrieve an authentication token from Azure AD required for client devices that are outside of the corporate network and communicates with a Cloud Management Gateway.

In order to complete this part of the setup, Application Administrator or Global Admin permissions are required.

Login to portal.azure.com and browse for Azure Active Directory. Locate and click the App registrations blade.

Click on New registration.

Provide a name, e.g. ConfigMgr-AdminService or similar that follows your naming standard. Specify the supported account types, where we suggest that you configure the app registration to only support accounts in the given tenant, not multiple. Last, select Public client/native (mobile & desktop) and click Register.

With the new ConfigMgr-AdminService app registration successfully registered, click on Authentication.

Click on Add a platform.

Select Mobile and desktop applications in the popup to the right.

Select the ‘https://login.microsoftonline.com/common/oauth2/nativeclient’ Redirect URI and leave the Custom redirect URIs field empty. Click Configure and the bottom of the popup window.

In the Authentication blade at the bottom, select Yes for Default client type under Advanced settings.

Click Save at the top for the configuration changes made in the Authentication blade. Below screenshot shows how your configuration should look in this blade at this point.

Click on the API Permissions tab and then Add a permission.

Click on APIs my organization uses, search for the name of your ‘ServerApp’ located earlier and click on it.

Click on user_impersonation and then Add permissions.

Click on Grant admin consent for <tenant name> and then Yes in the popup that appears.

Once granted, the API permissions should now resemble similar to the following:

Click on Overview and copy the Application (client ID) GUID and store it for later usage in step 4.

This concludes the app registration configuration, continue to the next section in this step.

Retrieve external AdminService endpoint address

The AdminService is available through the Cloud Management Gateway externally using a specific endpoint address. It’s specific for every environment, and required for Modern Driver Management to function properly.

Open SQL Server Management Studio create a new Query, using the following T-SQL command:

USE CM_<SITECODE>
select ExternalEndpointName, ExternalUrl from vProxy_Routings
where ExternalEndpointName = 'AdminService'

On the first row, replace <SITECODE> with the actual site code of the Primary Site server. Running the query will return the AdminService external endpoint URL:

Copy the data from ExternalUrl as shown above and store it for later, it’ll be used in step 4. The external AdminService endpoint address URL should be in the following format:

https://<CMG_service_name>.<domain_name>.<top_domain>/CCM_Proxy_ServerAuth/<Random_digits>/AdminService

Validate service account has synchronized

The service account that was created in step 2 of these instructions, requires to be synchronized. This means the following:

  • Service account is synchronized to Azure AD with Azure AD Connect
  • Service account is discovered by ConfigMgr using the Azure Active Directory User Discovery method

Validate that the service account has successfully been synchronized to Azure AD by checking for the account in the Azure portal under Azure Active Directory and then Users:

Also, validate that the service account have successfully been discovered by ConfigMgr from within the console under Assets and Compliance – Users:

At this point you should have stored the following details, which are required for the next step:

  • Application (client ID) of the created app registration
  • AdminService external endpoint address

Move on to step 4 when everything have been configured and validated.

Step 4 – Configure your task sequence

Adding the required task sequence configuration for Modern Driver Management is the final piece in these implementation instructions.

Download and packaging

Download the script called Invoke-CMApplyDriverPackage.ps1 from the resource location ‘Apply Driver Package script’ referenced above these instructions. We recommend that the script is packaged as a regular Package in ConfigMgr, even though it’s now possible to run PowerShell scripts directly within a task sequence by import the code only, as we’ve heard reports that it’s a bit unstable with larger scripts (Invoke-CMApplyDriverPackage.ps1 script is a fairly large script).

Create a Package in ConfigMgr similar to this:

Ensure the Package is referencing a source path for where the script is stored.

Distribute this package the desired Distribution Points.

Deployment types and scenarios

The Invoke-CMApplyDriverPackage.ps1 script can be used in various ways, called Deployment Types within Modern Driver Management and it’s important you configure the correct type depending on the required scenario. Below, you’ll find an overview of the different deployment types that’s currently supported:

  • BareMetal
    • This deployment type should be used for traditional operating system deployment where an image is put onto a new client device. In this scenario, a driver package is attempted to be matched against the client device currently being deployed, download driver package content and inject the drivers for installation later during the deployment phase.
  • OSUpgrade
    • This deployment type should be used when a task sequence is used to upgrade an existing Windows 10 client device to a new build version, e.g. when upgrading from Windows 10 version 1909 to 2004. In this scenario, a driver package is attempted to be matched against the client device hardware information, driver package content is downloaded to a local path that’s forwarded to the Windows 10 setup engine to process the drivers during the in-place upgrade phase.
  • DriverUpdate
    • This deployment type should be used when maintaining driver updates is required. It’s designed to run inside of a task sequence and it will attempt to match a driver package against the client device hardware information, download the driver package content and attempt to install the drivers contained within the package using pnputil.exe.
  • PreCache
    • This deployment type should be used when driver package content is desired to be pre-downloaded (pre-cached) on the client device, using a task sequence to stage other content before a Windows 10 in-place upgrade.

Setup required task sequence variables

Apart from previous versions of the Invoke-CMApplyDriverPackage.ps1 script, only a single Run PowerShell Script step was required. From version 4.x and onwards, additional configuration is required. A set of task sequence variables must now be created and for Modern Driver Management to function properly.

Minimum required task sequence variables

These variables are required for any deployment type and must exist in the task sequence. Create a Set Dynamic Variables step and configure the following variables:

  • MDMUserName
    • Should contain the service account user principal name, e.g. [email protected]. Ensure the data entered for this variable is configured as hidden, meaning that the ‘Do not display this value’ checkbox is selected
  • MDMPassword
    • Should contain the password for the service account, ensure that the data entered for this variable is configured as hidden, meaning that the ‘Do not display this value’ checkbox is selected

The Set Dynamic Variables task sequence step should look similar to this:

Additional task sequence variables for Cloud Management Gateway support (optional)

Only configure the following task sequence variables if you want to enable Cloud Management Gateway support and have successfully followed the instructions under step 3.

Within the same Set Dynamic Variables task sequence step where the minimum required variables have been added, add the additional variables:

  • MDMExternalEndpoint
    • Should contain the AdminService external endpoint address retrieved in step 3, e.g. something similar to: https://YourCMGService.domain.com/CCM_Proxy_ServerAuth/12345678/AdminService
  • MDMTenantName
    • Should contains the Azure AD tenant name, similar to:
      tenantname.onmicrosoft.com
  • MDMClientID
    • Should contain the Application (client ID) of the app registration created in step 3
  • MDMApplicationIDURI
    • This variable is only required when the ‘ServerApp’ app registration has a non-default value for the Application ID URI other than https://ConfigMgrService. Specify e.g. https://ConfigMgrServiceCustom

The Set Dynamic Variables task sequence step should look similar to this:

Setup desired deployment types

For the BareMetal deployment type, make sure that the Invoke-CMApplyDriverPackage.ps1 script is executed during the WinPE phase of the deployment inbetween the Apply Network Settings and Setup Windows and Configuration Manager steps. Modern Driver Management task sequence variables are required for this deployment type.

Required script parameters:

  • BareMetal
    • Switch parameter to specify the deployment type being used, requires no parameter input
  • Endpoint
    • Specify the fully qualified domain name of the Site server where the SMS Provider site system role is running, in most environment it’s running on the Primary Site server
  • TargetOSName
    • Introduced with version 4.2.0 of the Invoke-ApplyDriverPackage.ps1 script and is used to define whether Windows 10 or 11 (or later versions) is being deployed
  • TargetOSVersion
    • Specify the Windows 10 version number, e.g. 1909 or 2004 of the Operating System Image package defined in the task sequence

Optional parameters:

See the comments part of the Invoke-CMApplyDriverPackage.ps1 script for more details on these parameters mentioned below.

  • Filter
  • TargetOSArchitecture
  • OperationalMode
  • UseDriverFallback
  • DriverInstallMode
  • OSVersionFallback

Example:

Invoke-CMApplyDriverPackage.ps1 -BareMetal -Endpoint "CM01.domain.com" -TargetOSName "Windows 10" -TargetOSVersion "2004"

For the OSUpgrade deployment type, make sure that the Invoke-CMApplyDriverPackage.ps1 script is executed anywhere before the Upgrade Operating System step. Modern Driver Management task sequence variables are required for this deployment type.

Required script parameters:

  • OSUpgrade
    • Switch parameter to specify the deployment type being used, requires no parameter input
  • Endpoint
    • Specify the fully qualified domain name of the Site server where the SMS Provider site system role is running, in most environment it’s running on the Primary Site server
  • TargetOSName
    • Introduced with version 4.2.0 of the Invoke-ApplyDriverPackage.ps1 script and is used to define whether Windows 10 or 11 (or later versions) is being upgraded to
  • TargetOSVersion
    • Specify the Windows 10 version number, e.g. 1909 or 2004 of the Operating System Upgrade package defined in the task sequence

Optional parameters:

See the comments part of the Invoke-CMApplyDriverPackage.ps1 script for more details on these parameters mentioned below.

  • Filter
  • TargetOSArchitecture
  • OperationalMode
  • UseDriverFallback
  • DriverInstallMode
  • OSVersionFallback

Example:

Invoke-CMApplyDriverPackage.ps1 -OSUpgrade -Endpoint "CM01.domain.com" -TargetOSName "Windows 10" -TargetOSVersion "2004"

For the DriverUpdate deployment type, the Invoke-CMApplyDriverPackage.ps1 script is still required to executed within a task sequence. Modern Driver Management task sequence variables are required for this deployment type. TargetOSVersion parameter is not required as the script will automatically detect the operating system details it requires.

Required script parameters:

  • DriverUpdate
    • Switch parameter to specify the deployment type being used, requires no parameter input
  • Endpoint
    • Specify the fully qualified domain name of the Site server where the SMS Provider site system role is running, in most environment it’s running on the Primary Site server
  • TargetOSName
    • Introduced with version 4.2.0 of the Invoke-ApplyDriverPackage.ps1 script and is used to define whether Windows 10 or 11 (or later versions) is running on the device that’s targeted for driver updates

Optional parameters:

See the comments part of the Invoke-CMApplyDriverPackage.ps1 script for more details on these parameters mentioned below.

  • Filter
  • OperationalMode
  • UseDriverFallback
  • DriverInstallMode
  • OSVersionFallback

Example:

Invoke-CMApplyDriverPackage.ps1 -DriverUpdate -Endpoint "CM01.domain.com" -TargetOSName "Windows 10"

For the PreCache deployment type, the Invoke-CMApplyDriverPackage.ps1 script is executed within a pre-staging (pre-caching) type of task sequence used to ensure content required by an In-Place Upgrade task sequence are already locally available on the client device. Modern Driver Management task sequence variables are required for this deployment type.

Required script parameters:

  • PreCache
    • Switch parameter to specify the deployment type being used, requires no parameter input
  • Endpoint
    • Specify the fully qualified domain name of the Site server where the SMS Provider site system role is running, in most environment it’s running on the Primary Site server
  • TargetOSName
    • Introduced with version 4.2.0 of the Invoke-ApplyDriverPackage.ps1 script and is used to define whether Windows 10 or 11 (or later versions) is to be used for matching driver packages that will be cached
  • TargetOSVersion
    • Specify the Windows 10 version number, e.g. 1909 or 2004 of the expected Windows 10 version that should be applied in a later stage

Optional parameters:

See the comments part of the Invoke-CMApplyDriverPackage.ps1 script for more details on these parameters mentioned below.

  • Filter
  • TargetOSArchitecture
  • OperationalMode
  • UseDriverFallback
  • DriverInstallMode
  • OSVersionFallback

Example:

Invoke-CMApplyDriverPackage.ps1 -PreCache -Endpoint "CM01.domain.com" -TargetOSName "Windows 10" -TargetOSVersion "2004"

Soon to be released.


Additional functionality and troubleshooting

Validate a driver package for a specific model

New in version 3.x and 4.x 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 deployment type supplying the required parameters for driver package validation shown in the examples below.

Example (for version 3.x)

Run in a debug mode for testing purposes and override the automatically detected computer details (could be executed basically anywhere):

.\Invoke-CMApplyDriverPackage.ps1 -URI "http://CM01.domain.com/ConfigMgrWebService/ConfigMgr.asmx" -SecretKey "12345" -Filter "Drivers" -DebugMode -TSPackageID "P0100123" -Manufacturer "Dell" -ComputerModel "Precision 5520" -SystemSKU "07BF"

Example 1 (for version 4.x)

Run in a debug mode for testing purposes, locally on the computer model being tested:

.\Invoke-CMApplyDriverPackage.ps1 -DebugMode -Endpoint "CM01.domain.com" -UserName "[email protected]" -Password "svc-password" -TargetOSVersion 1909

Example 2 (for version 4.x)

Run in a debug mode for testing purposes and override the automatically detected computer details (could be executed basically anywhere):

.\Invoke-CMApplyDriverPackage.ps1 -DebugMode -Endpoint "CM01.domain.com" -UserName "[email protected]" -Password "svc-password" -TargetOSVersion 1909 -Manufacturer "Dell" -ComputerModel "Precision 5520" -SystemSKU "07BF"

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.

Example:

Invoke-CMApplyDriverPackage.ps1 -URI "http://CM01.domain.com/ConfigMgrWebService/ConfigMgr.asmx" -SecretKey "12345" -Filter "Drivers" -UseDriverFallback

Troubleshooting

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. Version 4.x of the Invoke-CMApplyDriverPackage.ps1 script does no longer exit with various exit codes if an error occurred. If an error occurred during processing, it will bail out with exit code 1 and log extensively what went wrong, some times with explanations on how to fix the issue.

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

Issues ยท MSEndpointMgr/ModernDriverManagement (github.com)

Keep in mind though, this is a free community solution provided by MSEndpointMgr.com, our response time may vary for various reasons, but we try to help out and answer any questions as soon as possible.

(0)

Categories

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