Windows as a Service: Sharing my PreCache and In-Place Upgrade Task Sequences, part 1

Introduction

This is an extremely hot topic and I do know that we have some awesome OSD experts out there sharing their content already (Gary Blok, Mike Terrill etc.).  Now, their content is way superior to mine and probably satisfy a lot of needs already, but I think that content around WaaS in particular is interesting and especially when sharing how one does Windows Servicing in details.

So, this is me doing just that – sharing my precaching and in-place upgrade task sequences – in details. This will be a lengthy post, so grab a good cup of coffee 🙂

Also, this is based on a mid-size company in Denmark and we don’t manage thousands and thousands of devices. WaaS is a small part of my daily job and I’m the only one doing it, so the time and effort put into this is reflecting the size of the company and the resources available, but is still done with an eye on the detail. With that being said, some of the stuff I do here is done with inspiration from how some of the mentioned people does it (credit where due during the posts). If you find yourself in similar position or just need some more inspiration – then this will be for you 🙂

Part 2: https://www.imab.dk/windows-as-a-service-sharing-my-precache-and-in-place-upgrade-task-sequences-part-2/

PreCaching Task Sequence

PreCaching is a must in my opinion. The Windows 10 upgrade already takes a considerable amount of time to complete and even more so if all the content needs to be downloaded once the user initiates the upgrade. Making sure the content is present in the CM cache before making the actual In-Place Uprade Task Sequence available is key. I also run Readiness and Compatibility Scan during the PreCache TS, also to make sure that the actual upgrade will run with higher chances of success.

Enough with the talking, here’s the details step-by-step:

Cleanup CM Cache

This step is probably a tad controversial (The CCM cache usually takes care of itself). I run a CM cache on 20480MB translating into 20GB. The content of my IPU is around 13GB and I have seen a few times that the CM cache was lacking sufficient free space or at least that what’s the CAS.log told me. I really really want the PreCaching to be done and preferably in the first run, so I’m doing some custom cleanup using a custom Powershell script as the very first step. The script only deletes content older than x days and excludes certain packageIDs and thus doesn’t touch any of the content provided by its own task sequence (that’d be silly)

Free Up Space

First off, this is copied directly from Gary Blok’s Task Sequence over at garytown.com and is pretty straight forward: Delete files in Windows\Temp and temp in each user profile with a condition to only run if there is less than 20GB available free space on the hard drive.

For your convenience, I’m adding screenshots of the content when it makes sense to. I will however make the entire Task Sequence available for download in the end of the post.

Cleanup C:\Windows\Temp

Powershell one-liner to cleanup %windir%\Temp.

Cleanup User Temp folder

And another Powershell one-liner to loop through each user profile and delete more content.

Set SMSTSReadiness False

Initially setting the SMSTSReadiness variable to False. This is later used to indicate whether the actual Readiness Check was run successfully.

Check Readiness Upgrade

This step is pretty self explanatory. I want to make sure there’s at least 20GB of free space on the hard drive. If this step fails to run, the task sequence will continue (‘Continue on error’ on the entire group. I want to continue precaching content), but will also run the steps in the Readiness Failed group.

Readiness Success

This entire group runs, if the SMSTSLastActionSucceeded renders True which translates into running if the Prepare for Upgrade group ran successfully.

Set SMSTSReadiness True

This time setting SMSTSReadiness to True, because if this step runs, that means the Readiness ran successfully.

Set ReadinessStatus Success

This steps is tattooing the registry with a status of success for the Readiness Check. This is later inventoried with hardware inventory and used with collections – I’ll go into details on this part later on.

ReadinessStatus with a value of 0 indicates a success.

Readiness Failed

This entire group runs if the SMSTSReadiness variable is False, which means that the Readiness Success group didn’t run (obviously) which again means that the Readiness Check failed. In that case, we want to do some additional steps.

Set ReadinessStatus Failed

Again, tattooing the registry with a ReadinessStatus of 1 which equals to failed. This is also picked up by hardware inventory and used with collections.

Copy Logs

This group will make sure to copy out the smsts.log to a network location for when the Readiness Check failed.

The steps will also create a sub folder with the name of the computer failing the Readiness Check and another sub folder indicating which step that failed. In this case ReadinessFailed. I rename the smsts.log to -precache to indicate what task sequence that was run (the readiness check is also being run in the actual in-place upgrade task sequence).

PreCache

This entire group also has ‘Continue on error’ set. I want the task sequence to continue regardless of errors, and instead provide me with the info on successes and failures through the tattooing and inventory.

Also, this group begins with setting the SMSTSPreCached variable to False.

PreCache Success

This group runs if the previous action also ran, which translates to every single step in the previous group, making sure that everything is precached. If the packageID already exists in the CM cache, the content is kept in the cache and not re-downloaded.

Set SMSTSPreCached True

Setting the SMSTSPreCached variable to True. Again, this is because the actual precaching was done successfully and thus we change the value from False to True for later use.

Set PreCacheStatus Success

Another registry-tattooing setting the PreCacheStatus registry key to 0, which indicates a success. This is still being picked up by hardware inventory.

PreCache Failed

This is completely identical to the Readiness Failed step. This group runs if the SMSTSPreCache variable is still set to False, which means something wasn’t precached successfully and additional steps is required.

Set PreCache Status Failed

Again, something during the PreCache failed thus tattooing the registry with PreCacheStatus with a value of 1.

Copy Logs

Continuing copying out logs to a network share if something in the PreCache step failed.

And again doing so to a custom sub folder to a folder for the computer failing.

OS Compat Scan

Plain and simple. This is running the Windows setup with the compat scan only switch. The group is running with ‘continue on error’ letting the task sequence to continue with the subsequent steps if the compat scan is failing.

OS Compat Scan Success

This group will run if the actual compatibility scan is coming out OK. That translates into a hex-value which again translates into a decimal value of 3247440400. More on upgrade error codes here: https://docs.microsoft.com/en-us/windows/deployment/upgrade/upgrade-error-codes

Set OS CompatScanStatus Success

Tattooing the registry with a registry key CompatScanStatus with a value of 0 which will indicate a success when picked up by hardware inventory.

Hardware Inventory

Running hardware inventory picking up all the previous steps successes or failures. This time running post the OS compat scan success, which in this scenario is the final step.

Doing the exact same thing for the failure part, which also will be the last step to run regardless of any of the previous successes or failures. This way I always end the TS with running hardware inventory.

Why using a package to do this, you may ask? Simply because SendSchedule has more client actions to it and the proper way to do it imo: https://docs.microsoft.com/en-us/sccm/core/support/send-schedule-tool

OS Compat Scan Failed

This step will run if the OS compatibility scan is NOT OK. In this case using not equals with the SMSTSOSUpgradeActionReturnCode variable.

Set OSCompatScanStatus Failed

And finally tattooing the registry yet again with CompatScanStatus with a value of 1 indicating a failure.

Copy Logs

Similar to the previous Copy Logs steps, now also adding the setup logs. These are obviously interesting for more insights on the compatibility scan part and why it failed.

The step will create another sub folder called CompatScanFailed where to both the setup logs and smsts.log will be copied.

Collections and hardware inventory

With all that info being tattooed into the registry it’s now time to make use of it. The idea here is, that before a given computer is offered the actual In-Place Upgrade Task Sequence, you want to make sure that the computer has passed the Readiness Check, the Precaching AND the OS Compat Scan.

Luckily, all of that info is stored for us in the registry and when picked up by hardware inventory, we can use that in collections (Note: it’s not picked up by default, you will have to extend hardware inventory to do that. Here’s an very old post of mine, sparingly describing how: https://www.imab.dk/extending-hardware-inventory-in-sccm2012/)

Below is the exact collection membership criteria of my collection, which then only have members where ALL of the checks done during the PreCaching is successfully completed. Nice!

More inspiration

Here’s another set of collections for your inspiration which also easily will display if you have computers failing either of the important steps allowing you to quickly take the required actions, for example rerunning the task sequence, investigate logs etc.

An example is to have the PreCache Task Sequence to run on a recurrent schedule for some of the FAILED collections, assuming you then and in between schedules will fix the issues.

Deployment

Also, when deploying the PreCache Task Sequence, make sure you do so with following settings. You want this to run completely silent for the end-user.

  • Suppress task sequence notifications: Yes
  • Show task sequence progress: No

Clean-CMCache.ps1

The script used for cleaning the CCM cache has been requested. So here it is. Use as you see fit. Needless to say: Test, test and test first. There are some references to my company for the registry. You might want to modify that 🙂

Update 11 january 2019: A comment on Facebook inspired me to do a slight change to the Clean-CMCache script. Instead of plainly deleting content older than x days, I’m instead deleting content if it’s not a part of the PreCache or IPU TS (Any of the packageIDs used). See the updated script below.

 

Download

Download my entire PreCache Task Sequence here: imab.dk_PreCacheTS.zip (404 downloads)

Stay tuned for part 2, where I will walk you through my In-Place Upgrade Task sequence.

37 thoughts on “Windows as a Service: Sharing my PreCache and In-Place Upgrade Task Sequences, part 1”

  1. This is great, many thanks.

    However, I´m having issues with the Hardware Inventory step.. I got the SendSchedule.exe from my CCM installation folder and copied it to my share and created a package only containing the exe. Added the package to the steps in TS but when running the TS i get the following error:

    “Ohanterat undantag: System.IO.FileNotFoundException: Det g†r inte att l„sa in filen eller sammans„ttningen Microsoft.Diagnostics.Tracing.EventSource, Version=1.1.28.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a eller ett av dess beroenden. Det g†r inte att hitta filen.”

    Application log on the client is showing a few entries aswell but nothing that makes any sense to me.

      • Yes sir! SendSchedule {00000000-0000-0000-0000-000000000001}

        Running it from CMD with or without admin gives me the same error message. Tried diffrent clients with the same result.

        Application log:

        Tillämpningsprogram: SendSchedule.exe
        Framework-version: v4.0.30319
        Beskrivning: Processen avslutades på grund av ett ohanterat undantag.
        Undantagsinformation: System.IO.FileNotFoundException
        vid Microsoft.SendSchedule.Program.Main(System.String[])

        • Have you got the required .ddl and .xml file next to the actual .exe? 🙂 microsoft.diagnostics.tracing.eventsource.dll and sendschedulemessages.xml

  2. Thank you for the TS….can you please include the packages?
    Not the BIOS and wim files….but scripts should not take that much space…

    Thank you

  3. Great post Martin! I went to test it out in my lab, but wasn’t able to import the TS. It says “Cannot validate a dependency to Package KR100404.” I extracted the content, tried to revise the package ID and re-zip it, but then it’s not recognized at all.
    I noticed you mentioned the total size of your pre-cache was about 13 GB. I’m guessing it’s because it’s caching driver packs for all your models? I suggest looking at Gary Blok’s “Set Dynamic Variables” driver logic. From a single TS step, I was able to add every package ID for over 10 different devices, then have it cache only the applicable model. Total size with v1803 was about 8 GB.
    On average, how long does it take for your machines to complete the IPU? Mine are averaging 1-2 hours, would like to find ways to speed up the process. Updating the drivers adds more time, but it’s definitely worth doing.

    • Thanks Ian. The package KR100404 is just a bunch of script I use in the actual IPU as well, hence they are also precached. You should be able to import the TS ignoring any referenced packages. The packages I use are secondary to this, but yes, I precache BIOS and some applications which are being upgraded as well. The precaching of BIOS etc. is done conditionally and only for the relevant models. Thanks though for the reminder 🙂 I’m averaging 1-2 hours as well – mostly around 1 hour and the latter if it’s a slow device/SSD.

    • Hey and thank you. I do that because I want the precaching to begin regardless of the device failing the readiness. The readiness checks for 20GB available free disk space. Let’s say it only has 18GB free, I still want something to be precached and then deal with the lacking disk spaces afterwards (it usually means the user is having A LOT of pictures or other private stuff which I will tell them to remove asap – or I will remove it for them) 🙂

  4. Thanks for sharing! This is very helpful information.

    But I’m at a loss as to why the task sequence is downloading the OS and Packages in C:\_SMSTASKSEQUENCE\Packages and not in the CCMCache folder. The step specifically states Place in the following location: ‘Configuration Manager client cache’ but it uses the task sequence location instead.

    Any idea as to what I am doing wrong?

    • Hey, that’s only while the TS is running. The content will end up in the actual CCM cache when the TS finishes 🙂 See CAS.log. Something like this: CacheManager: Starting copy operation, source = ‘C:\_SMSTaskSequence\Packages\KR100557’ to cache location ‘C:\WINDOWS\ccmcache\1j’.

  5. I can’t seem figure out how to import the information for hardware inventory in our environment. I tried using the import output from RegKeyToMOF and I followed your guide and created the file manually.
    It always says the classes to be imported are not available, although the configuration.mof editing was successful. Any idea?

  6. Hi Martin, this is a brilliant tutorial and a great example of how to leverage all of the features that ConfigMgr offers us as Admins. I’ve managed to re-create it pretty much exactly as you have it for my Enterprise of 20,000 users. I’ve been using Servicing Plans quite successfully since v1703 but prefer the flexibility this approach brings. Even though the downtime for the user is greater.

    I have one question regarding your deployment 7 Collections. I can see how to populate numbers 2-7 but I’m not sure what criteria you are using to populate Collection number 1 to indicate the Compatibility Scan has started and what use this one actually has?

    • Hey Andy, really happy that you find this useful. The STARTED collection is simply where I deploy the PreCache TS to. The criteria here in my situation, is all Windows 10 devices which is not running the target OS already, which translates into all the device that I need to upgrade. Hope that makes sense – and yet agin thank you for taking your time to provide me feedback 🙂

  7. Hi Martin!!

    Great idea and great TS!! I’ve been testing it in my environment (SCCM 1810) and I’ve noticed something “weird”. The PreCache OS step works great and downloads the upgrade package to the ccmcache folder, but when the Upgrade OS step runs… it downloads the upgrade package again!!

    I’ve even tried running the PreCache TS multiple times on the same system and the PreCache step avoids re-downloading the content, but the Upgrade OS step always downloads the content over and over again!!

    Quick solution I found, on the PreCache OS step, save the path as a variable (OSCache in my case) and in the Upgrade OS step reference the source path as %OSCache01% instead of the upgrade package.

    • Hi Bernardo, first off thank you! Now, if contents gets re-downloaded, something in your deployment is not right. The actual IPU task sequence must be deployed with ‘Download all content locally before starting the task sequence’. If all the packages by then is in the cache, the CAS component will run through them and verify they are all there in relevant revision and then start the TS. Nothing should be re-downloaded.

        • I’m not sure – did you find the answer to your question? 🙂 nothing should be redownloaded if the deployment is set to download everything before running the TS. CAS.log will be helpful here 🙂

          • Hi Martin,

            simple mistake in my haste to get it all up and running as quickly as possible – I had also forgotten to check the “Download all content locally” on the TS Deployment. It’s all good now – thanks again 🙂

  8. Hi Martin,

    me again 🙂

    I’ve noticed a little oddity when re-running the Pre-Cache TS if there was an issue to resolve after the first run.
    All the content was successfully pre-loaded into the Configuration Manager client cache as per the option on the “download package content” step when it first ran.

    On the second run I can see from the logs that it didn’t re-download any of the packages again (OS, Language Packs, Support packages, Drivers etc) during the PreCache stage. However it does download the entire OS package again when running the Compatibility Scan step into the Task Sequence working directory ignoring the copy already in the ConfigMgr cache. As this is the biggest one it’s a bit of a pain.

    Any ideas?

Leave a Comment

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