WARNING... WORK IN PROGRESS... This has been in my drafts for a couple months, I'm pretty busy so I don't know when I'll get to polish it, so for now, just publishing it with intent to go back and update it. Since I wrote this, there has been several changes already, due to advances in CM, finding bugs, etc. Anyway, because this is really never going to be 100% done, just going to click publish now, so you can start playing with it...
PS.. Mike Terrill is working on a very detailed blog post that will hopefully answer many of your questions as well, but he is waiting for making his more polished, he takes more pride in his blog posts than I do. 🙂
Download the Task Sequences and Content ---> HERE <--- I will try to keep that updated as I update my Lab's TS
Ok, so about a couple weeks ago, I posted the Pre-Cache Compat Scan Task Sequence, in Part 1, now it’s time to go over the IPU. It’s taken a couple weeks as I keep updating, refining, and finally came to the realization, I could keep tweaking this forever and never get around to posting. So, I figured, I should just post this, even if it’s not 100% complete. Just this should be pretty helpful to many.
Recommendations. Use Reg2Mof - While I write much of the data to WMI, throughout the TS, I update registry keys with useful information (WaaS_Stage as example), which I’m not writing to WMI until the end of the TS. At work, we do not use any of the WMI options like I do in my lab, we only write this information to the Registry, then use Reg2Mof to pull these keys in. After we make changes to the Registry during the TS, we trigger a Hardware Inventory, that way reports are updated fairly quickly. Also several useful values are written using the PreFlight Script (by @Keithga1) which are not written to WMI, so you’d miss all that great data… long story short, if you want to add all this useful data into your CM’s Database for Metrics / Reporting, use Reg2Mof. (Example of Registry keys being updated then hardware inventory being triggered)
So here is the TS (work in progress). I’ve flattened most of it into 1 TS, instead of having several Sub-TS’s mostly for simplicity of blogging and exporting.
There is just so many steps to go into, so I’m not going to go into all of them. I’ll give brief overviews of sections, and more detail on what I’d consider important. If you download and Import the TS into your lab, I’ve tried to document most of the steps themselves in the comments sections.
TS Prep: Sets variables used later on, then a folder for Running the majority of the TS, but only if it’s not already on SMSTS_Build (1803 in this example) – we did create a way to bypass this if we wanted the upgrade to run again on a machine already on the current build using a collection variable (SMSTS_Build_Bypass).
If the OS is already on the upgraded version, it skips to the end and sets the Registry to Success for the reports, then updates inventory.
Next we run the PreFlight, ideally we wanted to run this outside of the Task Sequence, as these are not true task sequences failures. These are things that we want to check to prevent the TS from running, as we have a good idea it will prevent the TS from running successfully. Hopefully Keith blogs the PreFlight Script, as I can’t do it justice. It is in the export that I’ve uploaded and you can take or leave what you want. We run the PreFlight in two different modes, if someone is logged on, it created self-closing popup dialog boxes for the user to interact with, so they can plug in their device, or connect to vpn. If no one is logged on, it just records the information to the registry and continues without creating a popup box
If PreFlight Fails, it drops out of it’s Group, skips the Main TS Group, and sets the Return Code to be used in the “PHail if not 1803” step.
If the PreFlight Steps fails in a “good” way, where it writes information to the registry, it will grab that and use for the return code. If PreFlight fails in a bad way, and doesn’t write any useful info to the registry, it will set ReturnErrorCode to "143".
After PreFlight, we move into the Main TS, where we set some additional variables, change power settings, update the lockscreen image and legal text and download the drivers again, but not really download, they should already be there from the CompatScan / PreCache TS. However, we need to run the steps again so that it creates the DRIVER01 variable used for the TS to know where the drivers are in the Cache, and which OS Upgrade Step to use (Drivers or no drivers). It should run these steps very quickly, as it will see that the content is already there.
In my lab example, I also set the user’s desktop background to something custom during the upgrade using BGInfo, it’s probably a bit much, but I added it in to this because, well, just because. I’ve also added the Deny Logon Section, but disabled it.
I also have a few “failsafe” steps to help remove the machine from Provisioning mode if a rollback should occur. I have a step that creates a Scheduled task, that runs when someone logs in, that will create a run-once key to remove a computer from provisioning mode. This way, if a machine rolls back, and is in provisioning mode, when a user logs in, it will trigger the scheduled task to create the one once key, so the next time they log on, it will actually remove it from provisioning mode. Why not just remove it on the next user logon? Well, what if someone ignores the warning and logs on during the upgrade? I really don’t want it to get pulled out of provisioning mode then, but at that point, it would create the run once key for when someone logs in after the upgrade.
Alright, so all of that is leading up to the actual upgrade OS steps.
First adding Variables, one to grab the time before we start the upgrade, and one to add additional parameters for the upgrade.
We then have two groups, one for Upgrades with without Drivers, and one with Drivers. This is where the DRIVERS01 variable comes into play.
No Drivers Group:
We then finish off with grabbing the time again and setting a variable to the finished time. Then setting a return code to use at the end of the TS, based on the Setup Engine.
After the Setup is done, we move on to the Post-Processing section, Here we call another TS to apply all of the customizations again.
Then onto some cleanup, make sure all of the lock screens, and other scheduled tasks we used are gone, since at this point, if the ts made it this far, we wouldn’t need those safe guards.
Then we grab more info, and and write it to the registry and WMI (SetOSDInfo PS Step).
It will then go through, check if the current OS is the desired OS, if not, Copy Logs to Server, and fail the Task Sequence using the ReturnErrorCode that we’ve set along the way.
Otherwise it continues to the end running the 4 last steps that are redundant at this point, but were there as explained earlier if the machine was already upgraded.
So, I didn’t go into a ton of Detail, and hope the TS itself will provide that detail. If you’ve imported the TS, and some things still don’t make sense, let me know and I’ll go into more detail here. But for the sake of time, and to get this posted… this is what you get.
So when it’s all done, and successfully upgrade, if you’ve followed our Process (PreCache / CompatScan TS, PreFlight, IPU), your registry will look like this:
You then inventory that, and make pretty reports.
Originally Posted on GARYTOWN.COM
33 thoughts on “WaaS–Post 2–In Place Upgrade TS”
Thanks for sharing all the hard work! I'm hoping you can help me with an odd issue. The ConfigMgr Task Sequence Agent service is ending up Disabled after a successful IPU. On other 'healthy' computers it's set to Manual. Should I just account for this with a TS step to set it back to Manual or is it a symptom of something else failing?
I really appreciate you posting this and WaaS Part 1. It's been a great accelerator to get us going. So many great things here.
Thank you for the great article.
I can run the first task sequence "TS - PreCache Upgrade Content 1803" without any problem and I see the image cached in C:\windows\CCMCACHE. So now I want to run my upgrade task sequence (not using the one provided by garytown) which I added the "Set Var SMSTSPersistContent = True" and "Set Var SMSTSPreserveContent = True" to my task sequence. But when my upgrade task sequence runs it is downloading the same image again but to the location C:\_SMSTaskSequence and not using the normal SCCM CCMCACHE folder. Does this pre-cache method only work if I use the "TS - Win 10 x64 InPlace Upgrade 1803" task sequence provided? Is there something special in the 2nd task sequence that tells it the content is already cached?
Thank you for your help and any information you can provide.
As long as you have the deployment set to "Download all content before starting that TS", it should work fine. The upgrade TS should then confirm all of the contents have already been downloaded to the cache (or download them again if they have been cleared or if the content has been updated), and start the TS using your pre-cached content. I'll create another Upgrade TS that is very generic to confirm, but you should not be required to use my upgrade TS to leverage pre-caching content.
Thank you for the reply! I have tried again just using the exact same TS downloaded from here and just changed it to my windows 10 image to upgrade with. And for some reason when running the second TS it is re-downloading everything to the location C:\_SMSTaskSequence\Packages. I can see the windows 10 image files in that location and in my CCMCACHE folder. Nothing changed between the 2 TS's and I ran them one after the other. Is there any other recommendation for what might be happening here? What is telling the TS to download to the SMSTaskSequence folder? I appreciate any feedback or anyone that has successfully done this if they have any suggestions as well. Thank you!
Frustrating isn't it. I don't know why Microsoft doesn't allow us to just set the _smstasksequence to use the SCCM Cache instead.
I saw your task sequences referenced in an ignite video and got excited to see how we might be able to use this 2 Task Sequence framework for selective Pre-Caching for an OS Wipe and Load deployment scenario.
Will this only work as part of an In Place Upgrade? I'm assuming this relies on the ability to to specify staged content, which is only available when upgrade Operating System is used.
For Wipe and Reload, since you're formatting the drive, you'd wipe out any content on the drive, so pre-caching a wipe and load wouldn't really work. This idea of two TS's, one that pre-caches and runs a compat-scan, then one the runs the upgrade was designed for upgrading from 7 or 8 to 10, or keeping windows 10 updated, not for a wipe and load.
It depends on your wipe and load task sequence. If it is sent to an existing machine and it is a non-BIOS to UEFI type task sequence, then there typically is not any format and partition that occurs. The TS engine moves stuff that needs to be saved into the protected _SMSTaskSequence directory and then cleans the file system outside of this directory. So you could indeed cache the contents down ahead of time as long as they were being moved into the protected directory. Restoring the contents to the new OS and new CM client is a little more tricky but it could be done. Alternatively, I would use BranchCache as you can backup and restore the BranchCache and then it can also be available for other peers on the network or even bare metal/new computer devices.
Just completed an upgrade from 1607 t0 1709 using the pre-cache TS followed by the Upgrade TS. The upgrade worked great, however, in software center the Upgrade TS is stuck at "installing". I've looked through smsts.log and haven't seen anything obvious. Any ideas?
Check this Post: https://garytown.com/scripts-node-task-sequence-info-remediation, I found that resetting services in specific order typically pulls it out of that hung state.
Thanks for this!
I've been trying to get this to work on a Win 7 client when the task sequence runs it fails the preflight with an error 0x200000005 Verify OS Version.
Is this meant to only work on Win 10 clients?
Yes, the script is written looking for specific requirements. You can edit the script to include Windows 7, or remove that requirement completely. I hope to redo the Pre-Flight process, just haven't gotten there yet. Was thinking of just making them TS steps.
Hi! You use the variable DRIVERS01 to save the path to the downloaded drivers. Then you could set the variable OSDUpgradeStagedContent to %DRIVERS01% if variable DRIVERS01 exists. So only one Upgrade OS-group is necessary.
Thanks for the Idea!
Hi! For the "Check Upgrade Key (Kill Switch)" you use EXIT 1111. Does 1111 mean any special or just to fail?
Means nothing special. Just needed an exit code that stood out.
Great Stuff. Thanks a lot! Testing it right now. I am wondering where the rollback steps are if some step inside the TS fails after the OS install has succesfully ran. The reason I am asking this is because of the lockscreen and legal notice step. In the beginning of the TS we change the lockscreen to something that alerts the user not to logon to the system and it's accompanied by a legal notice. This all works fine. The TS succesfully completes and the legal notice and lockscreen are reset to the default again.
If we want to try a new version of the TS on the same system we revert the OS with system restore. The system goes back to the last restore point which in this case was created during the upgrade TS. After the restore we are greeted with the customized lockscreen telling the user not to logon due to an upgrade in progress and we get the customized legal notice referring to the upgrade in progress.
My guess is this is because the restore point is created after the TS steps where we customize the lockscreen and the legal notice, but what happens if the OS install fails and a rollback occurs? Do the lockscreen and legal notice reset to the default or are we stuck with the customized lockscreen after rollback? Also... I wonder where the rollback occurs inside the TS and what steps are done in the rollback.
Maybe us reverting the OS to a previous version is something that doesn't usually occur in the field (we just do it to speed up testing with real hardware), but maybe after a regular rollback the lockscreen and legal notice are not adjusted. It's not all bad because the user will probably notice something has gone wrong during the upgrade but we prefer to have it reverted to what it was before the upgrade started.
I'd like to get your thoughts on this scenario. Much appreciated!
Awsome Stuff! Been testing it in our dev machines in our environment, working great.
Created some PowerBI Reporting dashboard today to analyze data, and found out that 1 out of 3 machines were randomly not reporting the timings that are written away to Registry / WMI during the setcomboinfo.ps1. some errors that it can't convert the "datetime" stuff (string to a datetime variable).
Been checking the logs, but didn't find (yet) what would be the issue.
when testing it manually it did seem to work, which is really odd.
anyway, a workaround that we have implemented at the moment is during the TS Steps where you create the variables with the "get-date" command, we added the -format parameter.
Did some testing on the machines where it was failing and it seemed to be resolved.
Thanks again for this great stuff!
Hey, great stuff here! So, I'm running into an interesting issue. After the step that upgrades the OS completes, the TS just sits there. If I hard reboot it, the TS will pick up where it left off. The smsts says the upgrade completed successfully. I've been banging my head against the wall for week over this, even did the servicing of the upgrade package so it doesn't go out to the web to get dynamic update files. I replaced the devinv.dll file with the version 10.0.17060.1030 that was linked that the CTGlobal folks referred to. Don't know where to go from here. Any ideas?
Gary, after applying the OS you set the variable SMSWin10UpgradePhail if it upgrade fails with the comment that it's does the rollback steps. But the variable is never referenced again anywhere further in the TS. Did I miss something?
You didn't... I'm in the middle of rebuilding much of the Upgrade TS, and those steps will be removed. Error handling will be completely revamped. Just been busy and haven't gotten to it... but expect a MAJOR change and new downloads around MMS time.
Thanks for posting this. I run into issue when running the step Create Scheduled Task LockScreenCleanUp, I got an error due to the xml file. Could you help?
What is the error? You have the step reference the package with the content which has the XML file in it?
This is the error code:
Process completed with exit code 1
Command line schtasks.exe /ru "SYSTEM" /Create /XML"WallPapersLockScreens\LockScreenCleanUp.xml" /TN "LockScreenCleanUp" /F returned 1
Failed to run the action: Create Scheduled Task LockScreenCleanUp.
Incorrect function. (Error: 00000001; Source: Windows)
It works like a charm. However I cant pinpoint why some of my upgrades take 5hours, and others 40 Min. SOmetimes it seem to get be in the upgrade step forever. Do you guys encounter this, and how to prevent/remediate this situation? ANy advice is more than welcome 🙂
If you've confirmed it is the actual upgrade step, and it's the Windows 10 setup engine that is taking forever, I'd start by looking at the setup log for Windows 10 in the panther folder. That log has everything, and you should be able to track down some useful info there. On machine that took longer than expected here, it was typically one of these reasons. Under Powered, lower free disk space, lots of files. It was far and few between that we saw this though.
We are using your task sequences for our in place upgrade. All is well apart from reverting the lock screen back to our corporate lock screen. We have a policy that forces a specific lock screen and users cannot change it. When the use logs on all is fine, locks the machine, all is fine, but when locking the machine again the lock screen changes to to the window 10 default lock screen. When rebooting the corp lock screen comes back, but the default lock screen comes back after the 2nd lock.
Can't say I've heard of that. I'd confirm that the lock screen image file is deleted after the successful upgrade. If you continue to have issues, I'd disable using it for now. Make sure that the script that revert back to the default lock screen image are using your lock screen. The scripts point to the Windows Default, if you're using a different location, that might be why.
I have successfully used a simplified version of your Pre-Cache Task Sequence to get an OS uplift cached onto a test device. The Deployment for this Pre-Cache Task Sequence was set to Required as running it does not affect the user.
I am now trying do Deploy a simplified version of your In Place Upgrade Task Sequence. I want this Deployment to be made Available so that the users can install at a time which is good for them. It is not deploying for some reason so trying to go through some basic questions.
Is it possible to run the IPU Task Sequence as Available ? Am I correct to assume that Pre-Cache does not need to be set on the IPU Task Sequence Deployment as the content is already on the test device in the ccmcache, or does it need to be ticked to ensure it checks the ccmcache for the content already being there ? Should I select "Download all content locally before starting task sequence" or the other option to download content as it is needed ?
As available, Yes
Is it already pre-cached, Yes. You would not need to set pre-download, but you can.
You should set it to download all before starting however, to ensure if the machine is missing something, or content versions change, that it downloads everything again before it starts, so if it can't reconnect to the DP after a restart, it already has what it needs
I'm checking to see if you could help me with the following scenario:
Use the same Task Sequence to:
1. Pre-Cache the upgrade OS Package on the client machine
2. Once the package is downloaded, have the task sequence dynamically install the upgrade without any user intervention.
So, for the installation part of the sequence, would I need a PowerShell script to lunch the install and how.
Or is there a way to do it in the Task Sequence without running a PowerShell Script?
Hey Zirigo, I'm not really following what you're requesting. You want to merge two processes into 1? If you want to start the upgrade once the download is complete, just skip the pre-cache task sequence and use the upgrade task sequence.