Apply native Driver packages dynamically using Driver Manager

Another great tool and post by my colleague Johan Schrewelius!

A while ago we had a customer whose Task Sequence suddenly exceeded the maximum allowed size, mainly because of a vast number of “Apply Driver Package” steps. To remediate the issue, we looked at several different solutions to apply driver packages dynamically.

It turned out that the solutions best suiting our needs all had the disadvantage of not supporting deployments configured to “Access content directly from a distribution point”, something that was part of the requirements.

Another requirement was to support native “Driver Packages” as opposite of standard packages with drivers applied with dism.exe.

All and all we realized we had to develop a solution of our own. This would without a doubt had taken much longer weren’t it for the solutions already published on the internet, many of them very good.

“Onevinn Driver Manager” does not download drivers from vendors nor does it create packages, there are a lot of such tools on the web already. Its purpose is to apply Driver Packages dynamically.

Special thanks must be directed to Mike Terrill (@miketerril) for, at MMS 2017, sharing his findings regarding package downloading and the various TS-Variables involved.

Our solution depends on a web service, OnevinnWS, that can be downloaded from Technet Gallery:

https://gallery.technet.microsoft.com/Web-Service-for-OS-93b6ecb8

The Driver Management solution itself can be found next to it on:

https://gallery.technet.microsoft.com/Driver-Manager-for-SCCM-ae5643e3

Prerequisites

• Before you can use the Driver Manager you need to install the Onevinn Webservice, which has been updated with a method to provide driver package information to the running Task Sequence. During installation, make a note of the “Authorized account” and password, you will need them later.
• Make sure you have included DotNet as an optional component in you boot-image(s). This component is added automatically when adding PowerShell, we suggest adding both.

Driver Manager – Configuration Manager Console Extension.

Once you have downloaded and extracted “Onevinn Driver Manager.zip” from Technet Gallery you will have two folders:

The first folder, “Manager”, contains a single msi that should be installed on primary site server, jump station (preferred) or management system with the Configuration Manager Console previously installed.

Note: Pay no attention to the build number; it will almost certainly have changed by now

The installation is pretty straight forward, just follow these steps:

1. Copy the “Driver Manager 1.0.xxxxx.x.msi” to your primary site server, or other computer that have the Configuration Manager console installed.
2. Double Click the file.
3. Follow the instructions (Next, Next, Finnish).
4. Open the CM console and check that you now have a new menu-item on the “Driver Packages” node, the Onevinn Driver Manager.

That’s all, no further configuration needed at this point. We will get back to the actual usage later…..

DriverInstallerClient.exe – The Install Engine

The second folder, “TS EXE”, contains two files to run from a package in TS:

Create a new SCCM “Package” with the files:

DriverInstallerClient.exe

DriverInstallerClient.exe.config

Do not create any programs.

Suggested name: “Onevinn – DriverInstallClient”

Before you distribute the new package, some configuration is required:

1. Open DriverInstallerClient.exe.config in Notepad.exe
2. Fill in the “red” parts.

“siteserver.domain.com” is where the webservice, OnevinnWS, is installed.

The account is of course the “Authorized account” (from the installation of the webservice).

Note: Be careful not to accidently save the file with a txt-extension.

Now Distribute the new package.

DriverInstallerClient.exe – The Step

Edit your Task Sequence (or a copy) and replace all “Apply Driver Package” steps with one (1) “Run Command Line” step:

Command: DriverInstallerClient.exe

DriverInstallerClient.exe must run in Window PE after the Operating system has been applied.

The DriverInstallClient will read and write numerous TS-Variables, it will also invoke two native CM utilities, osddownloadcontent.exe and osddriverclient.exe, to locate and install the correct driver package. Naturally it gets the Driver PackageId from the Webservice. During development, we used a couple of scripts but a single exe seems more robust, apart from being much cooler ?

Using DriverManager

The purpose of the DriverManager is to map computer models and operating system to a given driver package.

Right click a Driver package to start the Driver Manager:

Note: Driver Manager can also be started from the top banner and even the Start menu.

The Driver Manager will start with the focused package pre-selected in the top box.

Chose which Vendor and computer model the package is intended for and mark (checkbox) for which operating system:

Once you press “Map” the Manager will bind the selected model and operating system to the package:

Press “Save” and your done……

As you can see two checkboxes are available in the operating systems grid. These should normally not be checked but can come in handy in some troublesome scenarios, when drivers fail to install.

As from Configuration Manager 1706 we have a new option; to install drivers with the Dism Recurse flag. If you’re running a previous version you can still check “Recurse” but the DriverInstallClient will suppress it.

It’s not recommended but Configuration Manager also supports forced installation of unsigned drivers – so does Onevinn DriverManager.

These “Flags” can only be set while “mapping”, in the event you need to change them – first you will have to “unmap” the computer/os from the package.

New computer model

If you can’t find your computer in the Vendor/Model boxes it’s probably new or at least not yet inventoried. You can then add it using the “New” button:

Certain manufacturers divert from standard and don’t store the model name where expected. We have decided not to handle that at this time, as it would require additional inventory (Win32_ComputerSystemProduct) as well as more logic.

To get correct Vendor and Model from a new machine use strictly:

wmic csproduct get vendor

wmic csproduct get name

Retire (Unmap) a Driver Package

To disconnect a Model/OS from a Driver Package simply check it and press “Unmap” followed by “Save”:

Where is the Model/OS/Packege mapping stored

To make the solution as stand-alone as possible, except for the webservice that is absolutely necessary, we decided to store the mapping information directly on the Driver Package itself.

The mapping information is store as a JSON in the Comment field:

Consequently, one loses the possibility to make comments on the Package. However, the data is humanly readable and it’s nice to know for what computer and OS the package is used. A small price to pay.

How it looks and works

When we reach the DriverInstallerClient in TS it will send information about the computer and operating system to OnevinnWS, which will return the appropriate Driver PackageID for the Model/OS combination.

The DriverInstallerClient will the download the Drivers. This procedure is skipped if the deployment is configured to Access content directly on a DP.

Finally, DriverInstallerClient installs the drivers.

As shown above, one (1) single step in TS is all we need.

Summary

Onevinn Driver Manager is not the only solution for dynamic installation of drivers. You might find another, better suited for your requirements, it has some advantages though.

• Very little configuration, all in an easy to use UI.
• It handles Native Driver Packages, if you have a substantial number of such already in your environment, they can be reused without additional testing.
• It supports deployment configured to “Access content directly from a distribution point”.
• One Step in Task Sequence.

We are happy to share this solution and look forward to your comments and feedback.