Auto Apply Drivers

Task Sequence Steps – Auto Apply Drivers

This post is part of our Task Sequence – Beyond the Docs series.

This step will take a group of imported drivers, then apply them to your machine during OSD. I see this step phasing out, as most people are moving to a more dynamic way of doing drivers, and leveraging standard packages. Personally, we don’t have any drivers imported into our ConfigMgr system, EXCEPT drivers that need to be added into our WinPE boot images. But that is a topic for another time, and this page is dedicated to explaining how this step works, not if it is the best solution for your OSD.

MS Docs

https://docs.microsoft.com/en-us/mem/configmgr/osd/understand/task-sequence-steps#BKMK_AutoApplyDrivers

PowerShell

• Get-CMTSStepAutoApplyDriver
• New-CMTSStepAutoApplyDriver
• Remove-CMTSStepAutoApplyDriver
• Set-CMTSStepAutoApplyDriver

Variables

• OSDAutoApplyDriverBestMatch
• OSDAutoApplyDriverCategoryList
• SMSTSDriverRequestConnectTimeOut
• SMSTSDriverRequestReceiveTimeOut
• SMSTSDriverRequestResolveTimeOut
• SMSTSDriverRequestSendTimeOut

Step Image

Not too many options here, but a few. These are the defaults, and for the example I’ve left them alone. You can limit to a specific category, and perhaps you could use this as a way to apply drivers based on some criteria, like how I have categories setup by Model. Perhaps you’ve downloaded several drivers and built your own “Dell” or “HP” Category with the drivers to cover all of the models you have for Dell or HP and you want this step to apply them. Personally, I wouldn’t do that, but you could.

Demo 1 – Defaults – Best Match

The Step starts by running osddriverclient.exe with a few parameters leveraging variables created by the step options.
The steps runs a “gather” to determine hardware and asks CM for a comparison.

A list is generated then it moves on to downloading and adding drivers to the Windows Driver Store to be available when the machine reboots into OOBE and the Windows Setup determines the drivers it needs.

The step determines that there are several hardware ids that don’t have a match in CM. It then moves on to installing the drivers it did find a match for. I’m going to give an example here for one of the hardware items (Audio), rest look pretty much the same.

For Each Hardware ID, The TS Reaches out, pulls down the driver, runs dism to inject it into the Windows Driver Store. This part of the log can get quite long.

After it gets through all of the hardware and installs the drivers, it’s done.

Demo 2 – All Compatible

So basically everything looks the same, other than that command. The process takes a bit longer and additional drivers are downloaded and shoved into the Windows Driver Store to be made available to the Windows Setup Engine to apply during OOBE.

You can see the extra drivers that had been added:

Those are folders inside the c:windowssystem32DriverStoreFileRepository folder.

Driver.XML

The Driver.XML & DISM.log are created the temp location C:_SMSTaskSequencePkgMgrTemp for each driver. It’s created and deleted very quickly, so it’s hard to grab a copy during OSD for Demo. The XML file looks like this every time, other than path.

So that’s how this step works. It grabs the drivers it thinks would work well for the hardware and adds them to the Windows Driver Store to be available after the machine reboots and runs setup.

More Task Sequence Steps – Beyond the Docs

Find all of our Task Sequence – Beyond the Docs series posts here.

About Recast Software

1 in 3 organizations using Microsoft Configuration Manager rely on Right Click Tools to surface vulnerabilities and remediate quicker than ever before.
Download Free Tools
Request Pricing