[German] I already talked about problems in connection with the June 2021 update for Windows 10 within some blog posts. If updates required as a prerequisite are missing, the installation will causes issues. But a blog reader emailed me to point out that there has been a serious issues in Windows 10 and its server counterparts for months in the detection of the combined SSU and LCU packages available in WSUS. I am therefore posting the information in this blog post for information and discussion.
The pitfalls with Windows 10 updates
I had already pointed out in the blog post Windows 10 SSU: Hurdles, bugs and new version KB5003974 (June 15, 2021) that administrators of Windows 10 version 2004, 20H2 as well as 21H1 who selectively install cumulative updates need to pay attention and follow the installation requirements. The prerequisite for installing the June 2021 updates is an installed update KB5003173 dated May 11, 2021.
This is related to the fact that Microsoft has integrated the Servicing Stack Updates (SSU) for Windows 10 version 2004, 20H2 as well as 21H1 into the Latest Cumulative Update (LCU). The LCU is supposed to be cumulative, but if an SSU is missing, the installation of the cumulative update goes wrong.
WSUS fails in certain conditions
Normally, this is not a problem, just install the required updates from May 11, 2021 and that's it? Not at all, because when Microsoft later confirmed this fact, see my blog post Windows 10: Microsoft confirms issues with June 2021 security update. If the May 11, 2021 update that is required for installation is marked as expired in a management environment such as WSUS (and presumably also in SCCM/ConfigMgr), it is no longer available for installation.
A more deeper WSUS problem
Within my German blog post Windows 10: Microsoft bestätigt Probleme mit Juni 2021 an anonymous user commented "Then MS should simply not have marked the May patch as "superseded" (by the June patch) ". But the more interesting information may be found below:
Also, there is a larger problem that when upgrading from 1909 to 20H2 via WSUS, the patch level detection stucks on some systems on November 2020 (WSUS distributes 20H2 upgrade unfortunately still only the Nov. 2020 patch version).
After that, some systems think they already have the May and June patch installed (shows up in QFE) and WSUS reports it as installed and not needed. Effectively, however, these systems are still at the Nov 2020 level.
If you search for these affected systems externally at MS, the May and June patches are found again and then installed cleanly. Which systems are affected seems random.
German blog reader Markus Dählmann contacted me again via e-mail and wrote:
Hello Mr. Born,
in addition to your various blog articles about the recent abuses with the combined SSU+LCU updates in the newer Windows 10 versions, and specifically referring to the above comment I would like to share with you an observation that I already described a few weeks ago in the Microsoft Techcommunity, but without particular attention.
Latest LCU not detected from WSUS if corresponding SSU preinstalled
for a few months now, the SSU is bundled with the LCU. I have noticed that, if the bundled SSU is manually preinstalled with e.g. DISM, the corresponding LCU portion will no longer be detected as applicable from WSUS! It will however be detected if I scan against WU directly. WSUS will even show the entire bundle as installed for clients which only have the SSU portion installed!
This doesn't seem like a common scenario, however it becomes a huge problem if a device does a feature upgrade (from media or WSUS, doesn't matter) from an older version (<= 1909) to 20H2, with the "/DynamicUpdate NoLCU" option enabled. What seems to happen is, Windows Setup does not, as instructed, download and apply the latest LCU, but will still download and apply the latest SSU! This results in an installation that's effectively stuck at the LCU of the upgrade media used (currently 2020-11 for the WSUS upgrade package) and cannot upgrade to the current LCU, if WSUS is used as the only update source – at least until a newer LCU is released and approved. And since SSUs cannot be uninstalled, there is no easy workaround for affected machines.
I don't know if anyone from the WSUS team reads this, but there seems to be a faulty "is installed" detection logic in the SSU+LCU bundles published to WSUS, that needs to be addressed asap. Right now I have 35 Windows 10 clients stuck at the November '20 LCU, unable to upgrade.
He asked: Can anybody else confirm this problem?, but didn't received any feedback. He wrote within his latest e-mail:
The point is that the detection logic of the combined SSU+LCU packages available in WSUS has had a serious bug for months now, which I'm surprised I haven't read about anywhere except in the comment linked above.
After all, the combined SSU+LCU packages internally just bundle the SSU and LCU into one package. The two updates can be extracted and also installed manually individually, as it is even mandatory in offline servicing scenarios (create Custom ISO/WIM) according to MS (keyword: New Edge not available if this is not followed).
Now I made the following observation: If you extract and install only the SSU from a combined cumulative update, WSUS subsequently recognizes the complete package as already installed/no longer applicable.
Starting with the May cumulative update, this became even more obscure: The update is indeed recognized as needed by the clients, but then "installs" itself within a few seconds and does not require a reboot. If you do this, you can see in the Windows settings that the build number has not increased.
That alone is actually bad enough, although one can legitimately claim that this is a rather obscure administrative special case. However, I became aware of the problem in the first place because of a much more mundane scenario:
Since Windows 10 2004, Windows Setup has offered the ability to more granularly control the behavior of "Dynamic Update" during a feature upgrade (see this Microsoft article). For example, it is possible to allow all available Dynamic Updates (Setup Updates, SafeOS Updates, Driver Updates), but omit the latest cumulative update.
Especially in a managed environment, I don't want the latest LCU to be loaded bandwidth-heavy directly from MS during a feature upgrade, even though I've only allowed the previous month's LCU in WSUS so far (remember: as of 1809, Dynamic Updates can no longer be loaded from WSUS, but always come directly from MS).
He writes that the whole thing was reproducibly tested in the following environment:
Upgrade path: 1809 -> 20H2
Markus commented that I could alert the readership to this problem which is not easy to spot, which I have done with this. Thanks again to Markus for pointing this out, maybe it will help the WSUS administrators.
Cookies helps to fund this blog: Cookie settings