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… see additional post to explain the changes

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.

image

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
image

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

image

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.
image

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.
image

image

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

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).
image

image

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.

GARYTOWN.COM

29 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?

    Reply
    • 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.

      Reply
      • 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.

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

          Reply
          • 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.

    Reply
    • @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.

      Reply
    • 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.

      Reply
    • 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.

      Reply
  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.

    Reply
  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. 🙂

    Reply
    • 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).

      Reply
  5. It looks like you have a new step called “Set PackageName” that came with your 1909 TS – any chance you expound on it in more detail in this blog post?

    Reply
    • That step is a step in progress…. I’ve had it work sometimes… not consistent enough to blog.
      I should remove it from the export, but … just didn’t think about it.

      Reply
    • Kim’s method is in essence the same solution. Using a Database (XML File) and matching the model that is running. We just use TS Variable. We have typically 2 packages per model (Prod & PreProd/Test). Using our method, we have 2 “Variable Databases”, Prod / Pre-Prod. This allows us to do testing by calling the pre-prod “database” during deployment. Once you do your initial setup (Mapping PackageID to Models), it’s easy to maintain. Each New Model, you create your PackageIDs and add them to the variable “Database”.

      Basically, same thing, just different ways to create your “Database”. Kim’s is auto generated based on names of your packages, and we manually create it for complete control. If you have 1 driver package per model, you keep your package names consistent and include your model name, and if you generate new package id’s frequently, the script method to generate the XML file would be the way to go, but that description doesn’t fit us.

      Reply
      • Gary, thanks for the reply. You are 100% correct. I slightly modified Kim’s script to include some additional parameters that include a Pilot switch for testing drivers where test driver packages contain a keyword in the name or description.

        Reply
  6. Can this setup without using MDT database? It seems the W10X64DriverPackage has to be setup for each model in MDT is kind of cumbersome.

    Reply
    • This solution does NOT use MDT. I link to Mike’s solution on his blog which does, but the solution in this post has no connection to MDT.

      Reply
  7. We have used these steps successfully with our 1709 > 1809 IPU. On an IPU 1809 > 1909 on 1906 SCCM is causing issues with SMSTS.log

    The IPU runs, the upgrade occurs but the last events in SMSTS.log are the osddownloadcontent.exe tasks.

    If I disable that step in the TS, logging is fine and shows successful completion of the entire TS.

    Has anyone else seen this issue with 1809 > 1909 on 1906?

    Reply
  8. I’ve applied this method for HP devices with windows 10 1909 and found out it only download drivers for desktops. On workstation it detects as false and skip the download. Anyone run into this issue?

    Reply
    • Sure, if the offline media is online while it’s running.
      This method assumes you have connectivity to your DPs to pull down the required content for the model you’re running on.

      Reply

Leave a Comment

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