[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.
Advertising
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:
Advertising
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
Hi,
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
WSUS: 2012R2
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.
Similar articles:
Windows 10 SSU: Hurdles, bugs and new version KB5003974 (June 15, 2021)
Windows 10: Microsoft confirms issues with June 2021 security update
Advertising
I had a sort of similar issue. In my case the 2021-05 SSU was marked as not installed not needed. Server is W2012R2 and clients are all 1809 LTSC. All Clients were on 2021-04 CU. The synchronize detected the May 11 SSU but would not flag any clients as needing it despite the fact that they all needed it. The 2021-05 CU was not detected at all.
I ran the AdamJ clean up script which did not resolve the issue. In the end I uninstalled WSUS and reinstalled it. Then and only then did the SSU get flagged as not installed but needed.
It was not until it was installed that the CU was detected on the next synchronize, and as I had been trying to get this to work for weeks, the June SSU and CU were released, but again showing as not installed not needed. Once the 2021-05 CU was installed the June 2021-06 SSU and CU changed to not installed but needed (I was under the impression the prerequisite for June's updates was only the the May SSU was installed).
Were there ever such problems with Windows 7 and Windows 8.1? By overstretching the Windows 10 product line's complexity, Microsoft's current Windows model has become chaotically unfit for purpose. The quality known as 'reliability' does not seem to be in Microsoft's considerations.
I guess that a lot of Microsoft devs are cursing the people upstairs for their departure from common sense. They are feature obsessed.