Heads-Up! Multiple reports of the April 2017 Rollup Packages causing Windows Server 2016 or Windows 10 to fail to boot with “INACCESSIBLE_BOOT_DEVICE”. I’ve seen it on one of my own Win2016 servers running under VMWare ESXi 6.
https://www.reddit.com/r/vmware/comments/65ws15/windows_kb4015217_breaks_vm_boot/
I’m still waiting on “Working on updates” now, but I was at least able to get past the initial boot failure by booting in to Windows PE and using DISM to uninstall the packages, as described at https://www.tecklyfe.com/windows-kb4015217-windows-server-2016-windows-10-vmware-inaccessible-boot-disk/
Boot into Windows 2016 (or Windows 10) ISO.
Go to Repair
Go to Tools to get a command prompt.
Confirm the drive letter for the Windows image. Usually D: –> dir d:
Run the following to view the installed packages which will also show a date of install.
Dism /Image:D:\ /Get-Packages
Find the package(s) that were just installed by date. Run the following command on each package:
example: dism.exe /image:d:\ /remove-package /packagename:Package_for_KB4014329~31bf3856ad364e35~amd64~~10.0.1.0
Reboot.
My server had a different packagename (based on Package_for_Rollup~31bf3856ad364e35~amd64~~ with a version number), but the output of “/Get-Packages” shows installation date so it should be pretty easy to deduce which package is at fault.
edit: I’m back to the desktop now, successful rollback
gulp this may be self-inflicted. I’m still testing now, but applying the Delta update, rebooting, then applying the Cumulative update, then rebooting, the system worked fine. Now I’m testing installing the Delta followed by the Cumulative, without a reboot in between.
Then I came across this blog post : Monthly Delta update ISV support without WSUS | Microsoft Learn
Prevent deployment of Delta and Cumulative updates in the same month
Since Delta update and Cumulative update are available at the same time, it’s important to understand what happens if you deploy both updates in the same month.
If you approve and deploy the same version of the Delta and Cumulative update, you will not only generate additional network traffic since both will be downloaded to the PC, but you may not be able to reboot your computer to Windows after restart.
If both Delta and Cumulative updates are inadvertently installed and your computer is no longer booting, you can recover with the following steps:
Boot into WinRE command prompt
(followed by instructions on removing the package via DISM, which is exactly what I had already done to recover)
It’s probably worthwhile to add logic to the Delta and Cumulative fixlets, to make each of them non-relevant if we’re in a pending restart for the other one?
Head’s up to everyone: May’s patches have the same issue. Do not include both the delta CU and full CU fixlets in the same baseline!
Hi @Talloaf,
Update: Yes you are right, the additional relevance logic did not do their job initially (due to a human error). They are now corrected in site Patches for Windows, version 2752. Thanks so much for the notice and please let us know if the corrected version is still causing issue.
To prevent this issue from happening, additional relevance logic has been added to the CU and DU Fixlet pair, so that on one device only one of CU/DU would be applicable.
Thank you so much! I fought this issue in both March and April. I spent a lot of time in March fixing the problem on computers all over the state, and then I spent a lot of time figuring out what combination of events caused this to happen in April. I’m very glad to see that IBM has fixed the relevance so that only one of the two patches will apply. This will save me having to use multiple actions.
Hopefully this will be done in future months as well.
Thanks for the feedback! Yes this will be done for future DU/CU pairs too.