Clarification:
This article is probably going to confuse a few people. Yes, this topic was previously being covered by an article dating back to May that covered both this issue and the Enterprise Activation update issue. The point of that article was to both discuss the recent update experience and the recent support experience. Unfortunately, the Activation Issue is still to this day not officially fixed and has become a complete mess. As such, continuing to update the original article was making it extremely messy and confusing as to which issue was being discussed. As such, I am making new articles (like this one) to split the topics out.
Given this is an already solved issue by time of writing, I will largely not be re-writing sections of the article, so this may read oddly.
KB5034441 (January 9th, 2024) – “Windows Recovery Environment update for Windows 10” and Windows 365 (Cloud PCs).
To move out of the venting section and into the informational section, the first headache we have been dealing with for some time is the January Windows 10 update KB5034441. Many are aware that this caused general issues as the update affects the Windows Recovery Environment and failed on devices where the WinRE recovery partition was too small or didn’t exist. Microsoft put out articles detailing this along with steps to resize your WinRE such that it has enough space to process the update… But what if you don’t have a WinRE environment? Well, Microsoft documents in that same article that in this case, this update isn’t necessary… but that doesn’t mean it isn’t trying to apply and failing over and over and over and over and over and over – for the past FOUR months.
One of the products this is effecting is Windows 365 (AKA Clouds PCs, a Microsoft cloud solution for end-user compute) which doesn’t have a WinRE environment yet keeps trying to process the update. This update failing is basically turning into a dam causing other updates to be unable to process, preventing upgrades to Win11, and causing employees to constantly see notifications that they need to reboot as technically there is an update they are some 90 days beyond the required install threshold for. If you’re using something like Intune Autopatch or even Patch Rings, dodging a faulty KB is effectively impossible (short of pausing an entire ring) from a management end. This is one of those cases where you are lucky to be on MECM still sadly.
Microsoft support, who we have been engaged with since February 29th, has provided a workaround registry edit to get the stations to dodge this KB in the meantime. Unfortunately, I find it highly likely that this key will break at some point due to subsequent updates and could cause more harm than good if applied in the wrong scenario. So, I’m going to choose to omit it here and instead suggest you contact Microsoft support and simply ask for it.
Back to support, most recently we have been told (as of May 8th) that “It doesn’t appear the Product Group has any plans to release a permanent fix that will stop KB5034441 being offered to devices that don’t have WinRE.” We obviously challenged that and were met later on the 8th with “We aren’t saying that they won’t fix it, it is just that after the workaround, the issue doesn’t have a critical impact and the Product Group isn’t actively working to fix it with an ETA.”
In other words, sorry we created this problem in Windows update, sorry we are mistakenly telling it to apply where it shouldn’t (to a product we also own), here’s your band-aid to go fix it, don’t expect us to do anything about it anytime soon. That goes for any company utilizing Windows 365 on Win10, let alone however many other devices are out there without a WinRE for one reason or another. We have continued to push back on this for the past several weeks to no avail.
What does this impact?
To provide some clear and concise information on the impact this has (when the workaround is not in place), what we are seeing is devices getting repeatedly subjected to attempting to download, install, apply, and reboot for the update. This makes sense as effectively it’s a 4-month-old update that has yet to apply and is thus way beyond our update limits. Importantly, this causes other updates that are trying to apply to fail as well sometimes. It’s not 100% failure but notably, we are trying to upgrade our Cloud PC audience from Windows 10 to 11 and this is preventing that update from going through.
Below you can see how we have had some 928 attempts to install this update fail in the past 30 days, and that’s on a very minimal dwindling/remaining Windows 10 Cloud PC audience. Again, this is because it’s trying to go almost every day on every Windows 10 Cloud PC (that hasn’t been excluded already).
Updates:
(information that was gathered after initial posting of the original article)
6/6/24:
Allegedly Microsoft will be addressing the faulty assignment of KB5034441 sometime in June. I greatly look forward to this resolution, especially given we are six months into the issue at this point.
7/1/24:KB5034441 (WinRE): I still need to do some personal confirmation but, to my knowledge from the last update, I believe this was resolved in June.
This was incorrect, see 7/12/24.
7/12/24:
Correction to my 7/1/24 update – KB5034441 attempting to apply to machines it should not was not fixed it June. However, according to Microsoft support, it has been fixed by the monthly July updates, KB5039229 (Win10) and KB5040431 (Win11 21H2). While I’ve yet to personally test this, their communications and the specifics it provides are much easier for me to hold confidence in. While not directly listed by Microsoft, this list likely includes KB5040442 for Win11 22H2 and 23H2 (the patch they listed only covers Win11 21H2).
Disclaimer:
The following is the disclaimer that applies to all scripts, functions, one-liners, setup examples, documentation, etc. This disclaimer supersedes any disclaimer included in any script, function, one-liner, article, post, etc.
You running this script/function or following the setup example(s) means you will not blame the author(s) if this breaks your stuff. This script/function/setup-example is provided AS IS without warranty of any kind. Author(s) disclaim all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall author(s) be held liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the script or documentation. Neither this script/function/example/documentation, nor any part of it other than those parts that are explicitly copied from others, may be republished without author(s) express written permission. Author(s) retain the right to alter this disclaimer at any time.
It is entirely up to you and/or your business to understand and evaluate the full direct and indirect consequences of using one of these examples or following this documentation.
The latest version of this disclaimer can be found at: https://azuretothemax.net/disclaimer/
Azure to the Max 