[SCCM 1910] Software Update to 20H2 Not Applying

[Manny-Tech]

Hi,

 

Using SCCM SU to deploy the 20H2 update from 1909. I have the update set to install as soon as the deadline passes whether it's in the maintenance window or not, however not to reboot. My maintenance windows run from 3:30pm to 6am the following morning; the behaviour I'm seeing is that the update is installing, I log into a device and it tells me a system restart is needed, I restart but it returns to 1909 and not 20H2. See screenshot.

 

 

I can see from the updatedeployment log that it completes and sets a reboot flag but not forced. I'm unsure where to start after this point of why it's failing. Hopefully someone may have come across this problem before and solve a conundrum.

[chris11256]

Not sure if it helps, but we're running it as a task sequence instead if thats something you want to try. All it needs is the extracted ISO file. It's the 'Upgrade an operating system from an upgrade package' option and then point it at the iso you extracted plus any extra steps you want, but thats mostly it.

 

This is how I've been running the Windows 10 upgrades and it usually works everytime(some exceptions where it fails then wants manually starting in software centre).

Edited February 4, 2021 by chris11256

[computer_expert]

There's a few logs that the upgrade process creates on the client: https://support.microsoft.com/en-us/topic/log-files-that-are-created-when-you-upgrade-to-a-new-version-of-windows-9ec8aa31-0cc1-a0b2-2d98-e9c6714349b9

 

I suspect it will be one or more of the following - An outdated driver, antivirus/security software, lack of free disk space or a safeguard hold.

Edited February 4, 2021 by computer_expert

[Manny-Tech]

I'm still struggling and battling with this. Not sure if anyone is good at interpreting setupact and setuperr.log files. Please see attached though:

 

setuperr.txt

[computer_expert]

Error looks to be about this stage here:

 

Error      [0x080389] MIG    Failure while calling IDiscovery->Gather for Plugin={ServerPath="Microsoft-Windows-AppX-Deployment-Server\AppxUpgradeMigrationPlugin.dll", CLSID={AE27C1A6-25F2-45FD-9A28-081B81F29E0A}, ThreadingModel=Apartment}. Error: 0x800705B4
Error 0x000005B4 while executing critical action Action,CMXEPlugin,C:\$WINDOWS.~BT\Sources\ReplacementManifests,Microsoft-Windows-AppX-Deployment-Server\AppxUpgradeMigrationPlugin.dll,{AE27C1A6-25F2-45FD-9A28-081B81F29E0A},Apartment. Migration will abort[gle=0x000000cb]

 

Can you try binning the C:\$WINDOWS.~BT folder on a test client. I think it's a hidden folder too

 

Also clear the SCCM client cache (in the control panel applet) and try upgrading again

Edited February 16, 2021 by computer_expert

[Manny-Tech]

I'll give them a go. That's the bit I focussed on with the abort message. I've Google'd the life out of it though without success. I did wonder if it was because we strip certain Windows 10 apps out of our task sequence. If I install a fresh copy of 1909 and deploy 20H2 it goes out successfully. So it's either something related to user profiles and migrating or peculiar apps.

[computer_expert]

I was going to ask did you remove apps as some will break windows in weird ways if removed. I've had good success using this as a reference: https://www.vacuumbreather.com/index.php/blog/item/87-windows-10-1903-built-in-apps-what-to-keep

[Manny-Tech]

Right, I think I'm getting somewhere. It's definitely something related to the Windows Store cache - I stumbled across this post... https://social.technet.microsoft.com/Forums/en-US/9e12ac9e-8d06-4f06-98c3-ba90c6da3b9a/trying-to-upgrade-insider-preview-from-17711-to-newer-builds-stops-at-11-reboot?forum=WindowsInsiderPreview

 

It appears to now allow me to upgrade. The problem I have now is how do I script to remove SIDs in that registry location? In an ideal world, it'd be a script that can check against SIDs in the profile location that are still there and remove any that don't exist.

[psydii]

SCCM should be on 2006 with ADK 2004 to fully support 20H2.

 

https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/configs/support-for-windows-10#bkmk_20h2

[Manny-Tech]

I think I have managed to resolve it, just testing now.

 

Looking at the logs it clearly aborts based on appx migration. Following plenty of searching around, it looks like you can delete the Store cache for users from the following location: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore and remove relevant SIDs. These do get recreated upon login. I'm finding I have hundreds of SIDs in this location.

 

I have managed to create the below script to remove anything beginning with S-1-5-21

 

Get-ChildItem -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore" | Where {$_.Name -like "*S-1-5-21*"} | Remove-Item -Recurse

 

However, I'd still like to be able to reference the available profiles still on the machine and retain those in the AppxAllUserStore. It's a stop gap that seems to achieve what I need though.

[syntax53]

I think I have managed to resolve it, just testing now.

 

Looking at the logs it clearly aborts based on appx migration. Following plenty of searching around, it looks like you can delete the Store cache for users from the following location: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore and remove relevant SIDs. These do get recreated upon login. I'm finding I have hundreds of SIDs in this location.

 

I have managed to create the below script to remove anything beginning with S-1-5-21

 

Get-ChildItem -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore" | Where {$_.Name -like "*S-1-5-21*"} | Remove-Item -Recurse

 

However, I'd still like to be able to reference the available profiles still on the machine and retain those in the AppxAllUserStore. It's a stop gap that seems to achieve what I need though.

 

Your post helped us fix this issue in our organization. Thanks.

[bezzoh]

Just wanted to say thanks. This post just helped me with nearly 800x 1909 clients failing to upgrade to 21H2. Absolutely spot on with the cause of the upgrade failure. Thanks for this info!