Driver Pack Mapping and Pre-Cache v2

I blogged awhile back about how we were pre-caching drivers... and it worked... until it didn't.

Bug: after updating driver source and bumping content, we had issues.  So we re-worked it and modified the idea to use, as Mike calls it, "The Magic Policy".  This is ALL Mike's idea, no credit of my own, he's just really slow to blog things...

First, for reference, look at the old blog HERE

How it works:

Package Change: Add Program
Name: Pre-cache | Command: cmd.exe /c  | Run: Hidden | Whether or not user logged on | Run w/ Admin Rights

Overview of Driver Packages in Console.

So during the TS:

Several steps are required...


In the SMSTS Log

If you followed that yummy Task Sequence logging goodness.. you saw that the variable was created to point at the Package Content, then having the Program called, so it grabs Version 9 of the content.

When you check the CCMCache after the TS is complete.  You see all of the Upgrade Content is now in the Cache after the Pre-Cache TS ran, including the Associated Driver Pack and the version 9 of the Driver Pack.


I hope this provided enough additional information to get your Pre-Caching of Drivers working.

Future downloads of the WaaS Task Sequence will include this update... so look for ones from after 2019/09/15.


12 thoughts on “Driver Pack Mapping and Pre-Cache v2”

  1. Good stuff Gary, really love your Truth tab up there hehe.
    Would i be correct to assume i need to start from part one of your Driver Pack Mapping and Pre-Cache then just fill in the new stuff? I got a burp back from the step Downloading Driver package. LOL

    • Yeah, you'll want to look over the original post, then made the modifications. I'll be posting updated Task Sequences in a few weeks which will have all of these things done, you can then use that for reference.

  2. Does the same problem exist in WinPE?

    Should we be able to use the SMSTSPreserveContent content variable with this method? I suspect there may be an issue where the content in cache is not being flagged as different and not updating in my testing. When I updated a package after pre-caching, the content was still not getting downloaded in cache (although the TS was downloading it to the TS Directory temporarily), smsts said that the content was already in the cache...

  3. Hi Gary,

    Thanks again for all of the information on your blog, and for the resources you have provided. It has been a tremendous help to us in building out a WaaS strategy. Regarding this pre-cache driver process: with CM 1910, it seems this might no longer be necessary.

    If i am reading the Microsoft Documentation correctly, it appears that an OS Upgrade task sequence with "precache" enable is preprocessed on the client, and will respect WMI conditional logic for driver packages, if said driver packages have been updated with the Manufacture and Model metadata. Is this your take also ?

    Link to the MS doc:

    Also, as others have noted, love the Truth Tab.

    • Hey Mark,

      I have not tried using Driver Packages, we use legacy packages for all of our deployments. Since the built in Pre-Cache abilities only apply to the the Driver Packages and not legacy standard packages, to us this feature they added was useless.

  4. Hey! Sorry to bring up old stuff...and this seems to be working, except when I already have a version of the package in the cache.

    So, for example. I have a machine that pre-cached version 1 of the driver package last week. Moved the content to ccmcache, now version 1 is in the ccmcache. This weekend I updated the driver package to version 2. No pre-cache runs again, downloads version 2, but when it comes to moving the content to ccmcache, smsts says that the content already exists...

    Persisting content: xxxxxxx.2 from C:\_SMSTaskSequence\Packages\xxxxxx.
    Content already exists in CCM cache.

    Are you having this experience? Did you have to find a way to work around it? If I delete the version 1 content from the cache (using Client Center for Configuration Manager) then run it again it will properly cache the content...otherwise it just re-downloads the files every single time.


    • We had a conversation offline, but incase others read this and are curious, this was a bug in CM that was resolved in CM2006. Make sure the Server & Clients are updated.

  5. Hey Gary

    Thankyou for everything you do for the community. I appreciate it.

    I have a question about this blog, In the past, I had issues getting the OSDDownloadContent.exe method to work over the CMG and this method does not work either. Is this supposed to work over the Cloud Management Gateway? Can you please clarify?

    From your inplace upgrade tasksequence, I see you have PowerShell script that downloads drivers from HP and DELL, However i am wondering if the this method of Install package using Dynamic variable supposed to work from CMG?



Leave a Reply to Sudheer Bangera Cancel reply

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