Windows as a Service: PreCaching drivers before In-Place Upgrades with ConfigMgr Task Sequences


Since my previous WaaS posts, I have received a few inquiries about how to do drivers when precaching the content prior to running the actual In-Place upgrade. As of such, I figured it would make a great blog post covering the approach I’m currently using.

So this is me doing just that, as a small addition to what I have previously covered with my PreCache and In-Place Upgrade Task Sequences.

Note: I’m brewing on a complete WaaS section on here, sharing all and everything I do in details in regards to Windows Servicing. This will be available from this link once I get there:


First things first: With this approach I’m using regular packages, not to be confused with driver packages and therefore this obviously require that you have drivers kept this way.

Something similar to this: (Tip: These packages are created automatically with the Driver Automation Tool from the great guys over at

Where the source of those, can look similar to this:

PreCaching Task Sequence

I have previously gone into a lot of details covering my PreCaching Task Sequence. Find the detailed post here:

Seeing this is a slight addition to that, for now I’m only covering what’s related to the actual drivers.

PreCache Drivers

This is done with the Download Package Content step as shown below. The regular package containing the drivers for the model is added. I use a step for each model.

Using a WMI filter as a condition, to only download the relevant package for each model. Everything pretty standard I believe.

Taking a closer look on the step and where the content is being downloaded to, I use a Custom path┬áset to C:\ProgramData\CompanyName\1809DriversIPU. There are a few technical reasons for this, but for now I’m going to spare you for those details. ­čÖé

Post PreCaching

And post PreCaching you should find the content of the package containing the drivers in the custom path specified in the previous step:

In-Place Upgrade Task Sequence

Moving on to our In-Place Upgrade Task Sequence, also covered in good details in this post:

Here we are leveraging a task sequence variable called OSDUpgradeStagedContent which needs to be added prior to the actual upgrade of the OS. Similar to below illustration.

The important part is obviously also to set the correct value, which in this scenario is the custom path to where the drivers was downloaded.

Of similar importance, make sure to only run the step if there actually are drivers downloaded. As of such, create a condition on the step to only run if the same custom path exists.

Running the Upgrade

All of this deliciousness will tell the Windows setup to use the drivers in the custom path.

Taking a closer look on the SMSTS.log while the In-Place Upgrade is running yields the expected result:

Executing command line: “C:\WINDOWS\ccmcache\2g\SETUP.EXE” /ImageIndex 3 /auto Upgrade /quiet /noreboot /postoobe “C:\WINDOWS\SMSTSPostUpgrade\SetupComplete.cmd” /postrollback “C:\WINDOWS\SMSTSPostUpgrade\SetupRollback.cmd” /installdrivers “C:\ProgramData\KromannReumert\1809DriversIPU” /DynamicUpdate Disable


4 thoughts on “Windows as a Service: PreCaching drivers before In-Place Upgrades with ConfigMgr Task Sequences”

  1. First of all, thank you so much for creating and sharing this content.. It is truly appreciated!

    I’m having some trouble with the pre-caching of this content and am wondering what the appropriate deployment settings are for the Pre-Cache TS. It seems that every option I choose results in all driver packages being downloaded prior to the execution of the TS despite having the correct WMI queries in place.

    I guess the question is, are we deploying the pre-cache TS without any pre-cache options within SCCM (only selecting Download content locally when needed..), or if not, which options?

    Thanks in advance!


Leave a Comment

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