Driver Pack Mapping and Pre-Cache

Update 2019/09/14 - This has been Updated.
The way outlined in this post "works", but it doesn't allow the Package Version of the content to be saved to the CCM Cache,  If you look up the version, it will say "Version 0".  While this "works", if you update your driver pack and bump the version of the content, you run into a an issue.  We've resolved this by adding  program to each package, then "run" the program during pre-cache.  This enables the additional policy information to add a version to the driver pack in the cache...


Ok, this hasn’t changed since WaaS 1.0, but I don’t think I ever actually explained it.  So basically it’s just variables… one of my favorite things… along with Raindrops on roses and whiskers on kittens.

Basically we have two modules.  One that sets the Driver Packs, and one that downloads them.


So now that you’ve seen that image, it’s all crystal clear right?

First off, this is Mike’s baby, he came up with this.  For going a lot deeper than I am here, check out Mikes two Blog Posts: Configuration Manager Dynamic Drivers & BIOS Management with Total Control PART 1 & PART 2

Please NOTE, whenever I say “Driver Package” I am referring to a Legacy Package that consists of Drivers… not the Driver Package

So basically a quick overview.  Using Dynamic Variables, we match the Model to the CM Package ID of the Legacy Package that contains the Driver Pack for the model.

So IF ( Make = Dell & Model = Latitude 5290) THEN
W10X64DriverPackage = PackageID of Latitude 5290 “Driver” Package


So now that we’ve mapped the variable W10X64DriverPackage to the Package for the model of machine it’s running on… we need to download it… if you actually read Part 1 & 2 from Mike’s blog, you’d know where I am going with this…

So how do we download that?  All I have is a Variable… what good does that do me?  Here’s how we do it..

We tell OSDDownloadDownloadPackages to grab the Package from the W10X64DriverPackage variable.

So now that we set the Variables we need, (Not see the special conditions if it is running in WinPE, because we use this same method for both OSD & IPU… modular), we call the EXE binary that does the downloading, which calls those variables.

So then when it downloads the Driver Package Content, it creates a new variable called DRIVERS01, which contains the location of the Package in the CCMCache.


Then we just clear out the Variables, because we like to clean up after ourselves, it’s just being a good steward.

So then in the actual IPU Task Sequence.
We run the same modules, so it would download the Drivers again.. however when it calls the download, it finds that the contents are already in the CCMCache from the last time it ran those steps (Pre-Cache Task Sequence).


So then we run the Upgrade Step with the Staged Driver Package using the %DRIVERS01% Variable.  See, simple way of dynamically downloading and applying a driver package during IPU.

Please let me know if you have any questions or if I need to fill in any gaps.



14 thoughts on “Driver Pack Mapping and Pre-Cache”

  1. Can this same process work with Driver Packages instead of Standard ones, or are the two types handled differently by the client?

    • You can't use traditional Driver Packages in IPU. It has to be Legacy Packages that contain the Driver Contents. This is why many are dumping the use of "Driver Packages" and switching their drivers to using Legacy Packages for both OSD & IPU. Edit - was informed I am wrong. I've never tested that method, so I can't speak more to it, but feel free to give it a try and report back.

      • Driver packages do work the same way. I'm using driver packages with basically the same logic and process. I'm setting OSDDownloadDownloadPackages to the package ID of the driver package based on Make and Model. And after specifying the rest of the OSDDownload variables I'm running OSDDownloadContent.exe.

        • Interesting. We've never tried using CM Driver Packages. Does it actually apply the drivers in package properly?

          • As far as I can see it is working fine. The content is downloaded during the TS. When checking on the client during the TS, I see the directory structure as in the driver package. I also checked SMSTS.log if the parameter to the drivers is used. It looks all fine to me and I cannot see why the drivers should not apply correctly.

  2. So IF ( Make = Dell & Model = Latitude 5290) THEN
    W10X64DriverPackage = PackageID of Latitude 5290 “Driver” Package

    Where do I get this PackageID? I've read through Mike Terrill PART1 & PART 2 but still don't get how to obtain this PackageID from.

    Thanks in advance.

    • @Hoang Nguyen, look at his 2nd screenshot up top. The package ID for the driver packs is all the way on the right of that window.

    • Sorry for the delay, you have to make an empty package in CM first, so that you have the Package ID. Once you have the ID, you can have the script fill out all of the information. I should have taken a screen capture before hand, but basically I'd make a new package, fill out the Name Field and that was it. Left everything else blank, and let it create the package. Then took the ID and populated it into the script.

    • The reason we decided to do it this way was to avoid using a web service. We're basically building the mapping database logic in the TS itself.

  3. Is there a link to how to setup the drivers like legacy packages? Does that also deal with the NON PNP drives in one step? I'm going to be very hard pressed to convince them to switch over to using legacy drivers here.

  4. Hi Gary,

    Noticed for the HP systems, you used Product Codes variables instead of Make/Model Rules like you did for Dell. Any reason you deviated? Is there an easier way to get all the HP model Product Codes for all their Models instead of having to run the HP Tools app on every one to get the product code? A pre-gathered list would be awesome. 🙂

    • We found HP model names to be inconsistent. You can run powershell command to get the Prod (Get-CimInstance -ClassName Win32_BaseBoard).Product
      You can collect that with Hardware Inventory as well and create a report (which is what we have done).

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.