This pertains to CM 1902 and older, and when upgrading from Windows 10 1709. It might still pertain to future releases, as I've made Microsoft Aware, and they have confirmed the issues created during a rollback and os uninstall. So hopefully in the future, much of this will no longer be needed, other than our fancy form and information gathering...
Alright, OS Uninstall, This is a bit comprehensive. There are so many moving parts to this..
Before I get to far into this, required reading:
Blog Post: Automated Client Recovery from Rollback or OS Uninstall
Blog Post: Windows 10 RollBack... I mean OSUninstall
OS Uninstall is the process of going back to a previous build after a successful upgrade. it’s basically identical to a Rollback, except it was purposely caused by the user. So to restore services after an OS Uninstall, we basically use the same methods as we use to recover from a roll back. So the scheduled tasks are a near mirror image of the Roll back tasks.
In the OSUninstall Post TS, we clean up everything we created in the “PRE” TS and also change the default OS Uninstall Windows from 10 days to 15 days. (you know, when it removes the windows.old folder along with the ability to “go back”)
Here are the 4 scheduled tasks created in the OSUninstall “PRE” Module. The difference between our process for rollback and OSUninstall is that we don’t bother to pre-stage the recovery scripts for OSUninstall.
OSUninstallCleanUp (Triggered By a Script, which is why there are no triggers).
It actually gets triggered by the script that this cleans up. This Scheduled task cleans up the OSUninstall Scripts Folder, then deletes itself. Nifty Eh:?
Ok, I’m not going to explain all this, I feel the images are pretty self-explanatory.
So Gary, if you’re not pre-staging any of those scripts before the upgrade.. how does this all work? Well, that’s the beauty of OS Uninstall, it’s user triggered… by us (Software Center) using at Task Sequence.
So during the TS that runs the OS Uninstall, we populate what we need back into the past… so even through we’re running the Task Sequence in the New Build (1809 for example), we can copy data into the old build (1709 for example).. how… windows.old
Aww, windows.old your window into the past. This is some pretty good reading eh? Bet you didn’t see that coming.. unless you’ve seen my presentations.
So before I do much more writing, I’m just going to steal a bunch from Mike & my presentation at MMS
So what happens if you run OS Uninstall from the built in Settings Menu and you didn’t plan ahead? Bad things!
Problem Summary:
- 100% Manual Process
- Requires Admin Rights
- Catch-22: Admin account already needs a profile on the system or it will block the rollback
- Form information captured in registry is limited
- Can be confusing to end users (We’ll install the next preview build when it’s available)
- Does not invoke SetupRollback.cmd like the Windows 10 Setup documentation states
- Breaks the CM Client
- Client is in provisioning mode (resolved in 1901 TP)
- Services are set to disabled
- Goes back in time to the OS Upgrade step in the TS (i.e. thinks an upgrade is still running)
What did we come up with?
- In-place Upgrade Task Sequence modifications (modules)
- Scheduled Tasks
- OS Uninstall Task Sequence
- PowerShell scripts
- Custom WPF form backed by PowerShell
- Collection and OS Uninstall Deployment targeting
- OS Uninstall User Experience
- Hardware Inventory Extensions
Registry Keys for reporting… look where we put them (while in the new build IE 1809)… windows.old (offline registry)
Then after the OS Uninstall and you’re in the old build (1709)
… So what does it look like for the user?
Watch the Video on YouTube: https://youtu.be/hM_CsKUiZVQ
What does the Content look like… there is a lot of pieces to this..
Yeah, that’s a lot of scripts and scheduled tasks… well go big or go home. If you’ve imported the OS Uninstall Task Sequence, I’ve noted what most of the steps are for, so I’m not going to list every step here.. but basically a quick overview.
Rename the current DISM log file, so when we trigger the OS Uninstall Process, it has a clean log, which is easy to parse if things go bad.
We then trigger the User Form, which collects information and writes to registry and log files.
From here it writes several nuggets to the registry which is used by the scripts later, it also then copies the scripts into windows.old\programdata\OSUninstall that it needs, and the scheduled tasks we created during the IPU TS would be able to use.
It then runs the dism command to go back. We have auto remediation setup for the most common failure reason, new accounts created on the machine since the upgrade. If new accounts have been found, another script parses the DISM log, grabs those accounts, presents the information to the user, and the user can then delete those accounts or cancel. If user deletes, it reties and successfully reverts… this is in the demo video on the youtubes.
OK… I think that’s enough to explain it for now…. as always, PLEASE look through the scripts, while I appreciate your willingness to blindly import my TS & scripts, please open them and read through them, and look at the descriptions in the TS. If anything doesn’t make sense, let me know, and I’ll expound a bit more.
for now… happy UN-IPU.
PS… if you went to MMS, I highly recommend downloading the PP slide deck from our WaaS Session and looking it over.
GARYTOWN.COM