Auto Apply Drivers
Receive notification right in your inbox whenever new content like this is released & sign up for our email list!
We’ll send you the latest updates, how-to’s, and solutions to empower you at every endpoint.
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.
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.
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