If you had WSUS (or SCCM) running tonight with auto approval on you might have woken up this morning to virtual machines that can boot anymore.
Great, another update gone wrong. Time to restore from backup as that can be the fasted way to restore services when in a pickle and if you have a good solutions for that in place. For the others you can do what I did is below. Actually a couple of us MVPs were on this issue at a number of sites as our fist task this morning. But first the root cause.
Well read this link Express update delivery ISV support and you have all you need. Basically the delta and the full cumulative update of October (KB4041691 – https://support.microsoft.com/en-us/help/4041691) ended up in WSUS without you explicitly putting it there. That should not happen, normally the delta is not published for it to be downloaded and heaven forbid auto approved. You could also have manually approved everything without really knowing what and why. Not a great idea at all.
So your VM get’s offered both of them and that is BAD!
Normally you get into this pickle if you some how managed to install both of these yourself or via other tools (see the link above), which you shouldn’t do.
Now if you don’t have decent restore capabilities from backups or snapshots there is another way out by removing the updates.
Boot into the problematic VM and select troubleshoot
Select to open the command prompt and stay away from any other auto repair options.
Microsoft advises to get rid of the SessionsPending reg key. To do so load the software registry hive as follows:
reg load hklm\temp c:\windows\system32\config\software
Delete the SessionsPending registry key, if it exists by running:
reg delete “HKLM\temp\Microsoft\Windows\CurrentVersion\Component Based Servicing\SessionsPending” /v Exclusive
Unload the software registry hive:
reg unload HKLM\temp
Run dism /image:c:\ /get-packages to find the updates installed that caused the issue
The yellow one are the ones of interest and you can see the first one never even got an install time/
We now use DISM to remove these updates. Do first create the C:\Temp folder with MD temp if it doesn’t exist yet!
dism /image:c:\ /remove-package /packagename:myproblematicpackagetoremove /scratchdir:c:\temp
When done, close the command prompt, shut down the VM and then start it.
It will take a while but if will succeed and you’ll be greeted by a logon screen. Good luck!
Important: Do not try any other repair options or removing the updates with DISM might fail. We choose to remove all 3 updates from tonight to make sure. It might suffice to remove the delta one alone but we wanted to have an VM back as it was last night so more testing can be done before it is deployed again.
So, basically, don’t auto approve updates blindly, but test, validate & roll out in phases. Have great backup and TESTED restores. All by all we were only bitten in the lab, a couple of test/dev VMs and some of our infra VMs. Most of these are redundant and are patched stagger so our services were never badly effected. That gave us time to trouble shoot and investigate and warn our colleagues. As you can see here the issue was a delta update that made it into WSUS and was installed together with the full CU. Just manually downloading the CU and testing it would not have given you the heads up. About an issue. This is a reminder you need to test your real live situation and processes as realistically as possible. When you’re done with testing and cleaning up any fallout of this issue, make sure to patch your systems again!
Update: this also goes for Windows 10 Updates
Also see fellow MVP Mikael Nystrom blog post https://deploymentbunny.com/2017/10/11/the-october-2017-update-inaccessible-boot-device/
Update: we now also have the official MSFT response & fix for each and every scenario right here https://support.microsoft.com/en-us/help/4049094/windows-devices-may-fail-to-boot-after-installing-october-10-version-o