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!
- 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.
13 thoughts on “WaaS IPU – OSUninstall Module”
Is there a way to get the slide deck if we didn't get to visit MMS?
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.
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).
Yes, we reset the machine password during IPU, so if you revert after an upgrade, you don't loose your domain trust.
See this post.https://garytown.com/get-machine-ad-last-password-change-date-powershell
You are awesome. Thank you!
what would you recommend for Windows 7 upgrades? I've been playing around with this a bit, and tweaking here and there, but figured you likely had a windows 7 to 10 safe version?
Such amazing work, I am new as a SCCM admin and am still within my first year. Tons to learn. Is the TS available for download? Would love to dive in and see how you handled the newly added users, customer feedback, and registry entries for the information.
Yes, Recast Blog has great content: https://www.recastsoftware.com/blog
Check out the Monthly New letter posts "Recast Endpoint Management Recaps, provides tons of great info.
With 2004 the DISM OSUninstall command seems to hang. Have you seen this? The command does actually trigger the rollback after reboot, but it requires dism to be manually killed, which of course returns back a failure to the task sequence engine.
Any insight would be appreciated; there doesn't seem to be anyone else talking about this in the blogosphere.
I have only tested on 1909, we have no plans to run 2004, so I haven't even tested in my lab.
I'll see if I can replicate your issue, but give me some time as I haven't started adding 2004 to my lab yet.
See same issue with 2009 as well. Have to manually reboot to kill DISM OSUninstall command.
DISM /Online /Initiate-OSUninstall [/NoRestart|/Quiet]
By default, you will be prompted to restart the PC after running this command. You can choose to suppress the prompt by either specifying the /Quiet option, which allows the restart the happen automatically, or specifying the /NoRestart option, which will require the PC to be restarted manually.
Note: The /NoRestart and /Quiet options are new in Windows 10 Version 2004. In earlier versions of Windows 10, seccessful execution of this command does not produce any output, and the PC must be restarted manually. Running the command again after it has already succeeded will result in ERROR_NOT_FOUND (1168), but the uninstall will continue to proceed once the PC restarts.