WaaS IPU – OSUninstall Module

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..
image

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.

image

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:?
image

image
image
image
image
image
imageOk, 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

image

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..
image

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.

image

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

6 thoughts on “WaaS IPU – OSUninstall Module”

    • No, only attendees of the conference have the slide deck available. Mike and I did do a similar presentation for 2pint software. They have the web cast available.

  1. Hi Gary, me again. 🙂

    So before we have done any inplace upgrades using your fantastic methods here, we had an instance where one of our 1709 machines (mysteriously) reached out to Microsoft and upgraded itself to 1803. These are domain-joined systems, and we use LAPS for password management.

    Anywho, by the time we found out about the system, several days had past, but not a full 10 days, and one of our techs decided they were going to roll back the system manually from control panel on the system. The system successfully 'rolled' back, however immediately after, attempting to login to the system failed with the "lost trust relationship" error.

    The assumption here was that between the time the system successfully upgraded and the time the rollback was attempted, the computer account password in AD changed. The rollback apparently either reset the password, or rolled it back to the previous password, and now there was a mismatch between the system and the AD computer account, preventing login.

    Does your process of rollback prevent this scenario from happening in anyway? Or is this always going to be a possibility (since our computer account password reset policy is apparently fairly frequent...I don't know what it's set it off hand...that's server team secret).

Leave a Comment

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