Windows 10, der WSUS und das SSU+LCU-Erkennungs-Chaos

Windows[English]Hier im Blog hatte ich mich ja bereits über Probleme in Verbindung mit dem Juni 2021-Updates für Windows 10 ausgelassen. Dieses macht Probleme, wenn ein früheres Update fehlt. Ein Blog-Leser hat mich dann per Mail darauf aufmerksam gemacht, dass es in Windows 10 sowie in den Server-Pendants seit Monaten ein gravierendes Problem in der Erkennung der in WSUS verfügbaren kombinierten SSU- und LCU-Pakete gebe. Ich stelle die Informationen daher in diesem Blog-Beitrag zur Information und Diskussion ein.


Anzeige

Die Klippen bei Windows 10-Updates

Ich hatte bereits im Blog-Beitrag Windows 10 SSU: Klippen, Bugs und neue Version KB5003974 (15.6.2021) darauf hingewiesen, dass Administratoren von Windows 10 Version 2004, 20H2 sowie 21H1, die kumulative Updates selektiv installieren, aufpassen und die Installationsvoraussetzungen einhalten müssen. Voraussetzung zur Installation der Juni 2021-Updates ist ein installiertes Update KB5003173 vom 11. Mai 2021.

Das Ganze hängt damit zusammen, dass Microsoft die Servicing Stack Updates (SSU) für Windows 10 Version 2004, 20H2 sowie 21H1 in  die kumulativen Updates (Latest Cumulative Update, LCU) integriert hat. Das LCU soll zwar kumulativ sein, fehlt aber ein SSU, geht die Installation des kumulativen Updates schief.

Im WSUS knallt es

Normalerweise ist das kein Problem, werden halt die geforderten Updates vom 11. Mai 2021 installiert und gut ist? Mitnichten, denn als Microsoft später diesen Sachverhalt bestätigt hat, siehe mein Blog-Beitrag Windows 10: Microsoft bestätigt Probleme mit Juni 2021 Sicherheitsupdate, kommt ein Problem ans Tageslicht. Wird das zur Installation vorausgesetzte Update vom 11. Mai 2021 in einer Verwaltungsumgebung wie WSUS (und vermutlich auch in SCCM/ConfigMgr) als abgelaufen (expired) gekennzeichnet, steht es nicht mehr zur Installation zur Verfügung.

Erster Hinweis auf ein tiefergehendes Problem

Zum Blog-Beitrag Windows 10: Microsoft bestätigt Probleme mit Juni 2021 hat sich dann noch ein anonymer Benutzer mit nachfolgendem Kommentar zu Wort gemeldet:

Dann hätte MS das Mai Patch einfach mal nicht als „superseded“ (durch das Juni Patch) markieren sollten.

Auch gibt es das mMn größere Problem, dass bei Upgrades von 1909 auf 20H2 per WSUS, der Patchlevel bei manchen Systemen auf November 2020 hängen bleibt (WSUS verteilt beim 20H2 Upgrade leider immer noch nur die Nov.2020 Patch Version).

Danach meinen einige Systeme sie hätten das Mai und Juni Patch schon installiert (taucht im QFE auf) und WSUS meldet es als installiert und nicht benötigt. Effektiv sind diese Systeme aber immer noch auf dem Stand von Nov 2020.

Wenn man diese betroffenen System extern bei MS suchen lässt werden die Mai und Juni Patches erneut gefunden und dann sauber installiert. Welche System betroffen sind scheint zufällig.

Der erste Satz mit dem Hinweis auf die „superseded“ Updates hätte das oben beschriebene Problem, dass ein Update fehlt, theoretisch beheben können. Aber im Nachfolgetext kommt der Hinweis, dass es ein tiefergehendes Problem mit der Erkennung des Patchlevel in Windows 10 gebe, sofern ein Upgrade von der Version 1909 auf die 20H2 erfolgt und der WSUS beteiligt ist.

2. Leserrückmeldung zum Erkennungsproblem

Kommen wir nun zur Information von Blog-Leser Markus Dählmann, der mir per E-Mail den nachfolgenden Sachverhalt zukommen ließ (an dieser Stelle mein Dank für den Hinweis).

Hallo Herr Born,

ergänzend  zu Ihren diversen Blog-Artikeln über die neuerlichen Missstände mit den kombinierten SSU+LCU Updates in den neueren Windows 10-Versionen, und konkret Bezug nehmend auf diesen Kommentar (ist ja im vorhergehenden Abschnitt herausgezogen) möchte ich gerne eine Beobachtung mit Ihnen teilen, die ich bereits vor einigen Wochen in der Microsoft Techcommunity geschildert habe, allerdings ohne sonderliche Beachtung.

Es handelt sich um den gleichen Hinweis, den ich als Kommentar eines anonymen Lesers oben herausgezogen habe. Hier die Hinweise von Markus:

Es geht darum, dass die Erkennungs-Logik der in WSUS verfügbaren kombinierten SSU+LCU-Pakete schon seit Monaten einen gravierenden Fehler aufweist, von dem es mich wundert, dass ich davon außer in oben verlinktem Kommentar noch nirgendwo etwas gelesen habe.

Die kombinierten SSU+LCU-Pakete bündeln ja intern lediglich das SSU und das LCU zu einem Paket. Die beiden Updates lassen sich extrahieren und auch manuell einzeln installieren, so wie es in Offline Servicing-Szenarien (Custom ISO/WIM erstellen) laut MS sogar zwingend erforderlich ist (Stichwort: Neuer Edge nicht vorhanden, wenn dies nicht befolgt wird).

Nun habe ich folgende Beobachtung gemacht: Extrahiert und installiert man nur das SSU aus einem kombinierten kumulativen Update, erkennt WSUS im Anschluss das komplette Paket als bereits installiert/nicht mehr anwendbar.

Ab dem kumulativen Update vom Mai wurde dies sogar noch undurchsichtiger: Das Update wird durchaus von den Clients als benötigt erkannt, „installiert“ sich dann allerdings innerhalb von wenigen Sekunden und verlangt keinen Neustart. Führt man diesen durch, erkennt man in den Windows Einstellungen, dass sich die Build-Nummer nicht erhöht hat.

Das allein ist eigentlich schon schlimm genug, wenngleich man berechtigterweise behaupten kann, dass dies ein ziemlich obskurer administrativer Spezialfall ist. Ich bin allerdings durch ein viel alltäglicheres Szenario überhaupt auf das Problem aufmerksam geworden:

Seit Windows 10 2004 bietet Windows Setup die Möglichkeit, das Verhalten von „Dynamic Update“ bei einem Feature Upgrade granularer zu steuern (siehe diesen Microsoft-Artikel). So ist es z.B. möglich, alle verfügbaren Dynamic Updates (Setup Updates, SafeOS Updates, Treiberupdates) zuzulassen, das neueste kumulative Update allerdings auszulassen.

Gerade in einer gemanagten Umgebung möchte ich nicht, dass bei einem Feature Upgrade das neueste LCU bandbreitenlastig direkt von MS geladen wird, obwohl ich in WSUS bisher nur das LCU des Vormonats freigegeben habe (Wir erinnern uns: Ab 1809 können Dynamic Updates nicht mehr von WSUS geladen werden, sondern kommen immer von MS direkt).

Der Knackpunkt ist, dass in einem solchen „/DynamicUpdate NoLCU“-Szenario dennoch das brandaktuelle SSU geladen und installiert wird – womit die oben geschilderte Problematik greift. Das heißt, wenn ich meine Rechner über das WSUS-Upgradepaket, welches zuletzt im Dezember 2020 aktualisiert wurde, unter Verwendung einer setupconfig.ini mit „DynamicUpdate=NoLCU“ auf 20H2 aktualisiere, bleiben diese nach dem Upgradevorgang auf dem LCU-Stand von Ende 2020 (!) stecken, bis Microsoft ein neueres kumulatives Update released hat und dieses in WSUS freigegeben wurde – aus IT-Sicherheitssicht eine Katastrophe.

Noch einmal betonen möchte ich, dass diese Problematik nur in WSUS-Umgebungen greift. Geräte, die direkt von Microsoft updaten, finden und installieren das neueste LCU auch mit bereits vorinstalliertem SSU-Teil problemlos.

Er schreibt, dass das Ganze reproduzierbar in folgender Umgebung getestet wurde:


Anzeige

Upgradepfad: 1809 -> 20H2
WSUS: 2012R2

Markus meinte dazu, dass ich die Leserschaft auf dieses nicht leicht zu erkennende Problem aufmerksam machen könnte, was ich hiermit gemacht habe. Nochmals danke an Markus für den Hinweis, vielleicht hilft es den WSUS-Administratoren weiter.

Ähnliche Artikel:
Windows 10 SSU: Klippen, Bugs und neue Version KB5003974 (15.6.2021)
Windows 10: Microsoft bestätigt Probleme mit Juni 2021 Sicherheitsupdate


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Anzeige


Dieser Beitrag wurde unter Windows 10 abgelegt und mit Problem, Windows 10, WSUS verschlagwortet. Setze ein Lesezeichen auf den Permalink.

22 Antworten zu Windows 10, der WSUS und das SSU+LCU-Erkennungs-Chaos

  1. 1ST1 sagt:

    Am Freitag Nachmittag hatte ich mal etwas Luft und habe mir mal die Sache mit dem zurückgezogenen bzw. nicht installierten KB5003173 bei uns angesehen. Ich habe dann tatsächlich bei über 500 PCs mit 20H2 (auf 21H1 haben wir aus Zeitgründen noch nicht aktualisiert, vielleicht überspringen wir direkt zu 21H2) 7 Stück gefunden, die meinten, sie hätten KB5003637 nicht nötig und Patchstand Mai wäre völlig ausreichend… Diese PCs waren scheinbar zwischen Veröffentlichung des Mai-Patchdays und dem Rückzug KB5003173 ausgeschaltet bzw. außer Haus ohne Netzwerk/Internetzugang eingesetzt, man muss ja auch die Ursache kennen, warum sowas passiert. Das Schlimme ist, ohne die Hinweise hier und anderswo wäre dieser Umstand nie aufgefallen, das Schätzeisen WSUS zeigt in dem Fall in der Statusübersicht ja nur „alles gut“ an.

    • Anonymous sagt:

      Am besten beim WSUS immer die Versionsspalte für die Clients einblenden und ggf danach gruppieren.
      Es wird zwar (leider) nicht die eigentliche Windows Version des Clients, sondern nur die Version der WSUS Updatekomponente des Clients angezeigt und diese ändert sich auch nicht bei jedem Patch, aber so erkennt man recht schnell Clients die total hinterherhängen.

    • JohnRipper sagt:

      Mir war es aufgefallen, aber ich war unfähig eine Lösung zu finden, weil es auch immer so Random aussah.

  2. Alfred sagt:

    Hallo, vielleicht noch ein kleiner Hinweis:
    Mit KB5004760 (gestern hier im Blog verlinkt) scheint der Knoten zu platzen.
    Ich habe es gestern direkt vom MU in den WSUS importiert und im Moment machen zumindest alle Rechner, die am Wochenende an sein sollen, fleißig Reboots.

    Das KB5004760 scheint es auch nicht als dynamisches Update zu geben – es ist immer das volle Paket (ca 500MB).

    Ich warte gespannt auf Montag.

    • David sagt:

      Hi Alfred
      Hat sich bei Ihnen noch was ergeben bezüglich der Patch-Stände? Unser WSUS hat sich die KB5004760 derzeit noch nicht geholt und ich überleg gerade, dieses ebenfalls manuell rein zu pumpen.

      • Alfred sagt:

        Hallo David,

        Günter Born hatte ja geschrieben, daß dieses Update nicht per WSUS ausgerollt wird, manueller Import ist hier Pflicht (https://www.borncity.com/blog/2021/06/30/windows-10-2004-21h1-update-kb500476-fixt-pdf-probleme/)
        Im Moment sind ca 95% der heute eingeschalteten (es ist Ferienzeit) Clients aktualisiert oder stehen im Reboot pending. Die 5% Bodensatz sind normal (chronisch volle Festplatten, krude Netzwerkkonfiguration oder exotische Software).
        Sieht also gut aus.

        • Alfred sagt:

          Eine weitere Wasserstandsmeldung: Praktisch alle Systeme sind laut WSUS auf Build 10.0.19041.1081 angekommen, obwohl sie vorher auf Build 10.0.19041.906 verharrt haben. Das betrifft übrigens nur die Anzeige im WSUS, die Systemsteuerung meint 10.0.19043.1082.

      • test sagt:

        Das Update KB5004760 muss man auch manuell importieren, wenn man es verteilen will, kommt laut MS-Beschreibung nicht automatisch zum WSUS.

  3. Markus K sagt:

    Ich habe da einen Verdacht, kann es sein, dass die superseded SSUs nicht declined sind?

    Wenn ich das richtig verstanden habe müsste ja eine Neuinstallation eines 20H2 clienten in einem ungepatchten client enden? Dynamische Updates am WSUS für 20H2 gibt es bei mir allerdings schon, nur ob diese geladen werden kann man eher schwer sagen.

    • Markus K sagt:

      Ja, ich kann inzwischen auch bestätigen:
      Eine frische Installation von 20H2 bleibt auf 19042.508 picken.

      Habe nun gesehen, dass der client gerne KB5003173 hätte, das bei mir natürlich bereits declined war. Sollte das funktionieren wäre die Lösung KB5003173 wieder freizugeben.
      MS muss jedenfalls die Hausaufgaben nocheinmal machen! Dass man so, obwohl man theoretisch nichts falsch gemacht hat am WSUS, komplett ungepatchte clients produziert ist schon ein starkes Stück!

    • Markus D. sagt:

      Danke für die Idee mit dem Declinen der alten SSUs (in meinem Fall war nur KB4598481 noch genehmigt). Leider hat dies auch keinen Unterschied gemacht.

      Ein neu installiertes System sollte von dem Problem (also zumindest das o.g. Szenario, das ich Herrn Born gemailt habe) nichts merken. Es tritt nur auf, wenn der SSU-Part eines kumulativen SSU+LCU Updates allein installiert wurde – entweder manuell (leicht selbst zu reproduzieren) oder halt bei einem Feature Update mit „NoLCU“ oder „NoDriversNoLCU“ als Parameter für „/DynamicUpdate“.

      Dass auch für neuere Versionen noch Dynamic Updates in den WSUS synchronisiert werden, war für mich auch schon immer ein Rätsel. Laut Microsoft und auch eigenen Tests werden die seit 1809 nur noch direkt von MS geladen, siehe z.B. hier: https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-benefits-of-windows-10-dynamic-update/ba-p/467847

  4. Beat sagt:

    Microsoft scheint davon auszugehen, dass innerhalb eines Monats sämtliche Clients gepatcht sind. Wer das nicht schafft, ist selbst schuld.

    Ich habe SSU-19041.985-x64.cab aus dem KB5003173 extrahiert und ein eigenes Package gebaut. Nach der Installation bietet SCCM das Juni-Update ohne Reboot an.

  5. JohnRipper sagt:

    Das ist dann meine Lösung.
    Durch mein Aufräumen des WSUS wurde das superspeded abgelehnt weil einige Clients mit der Suche hatten.
    Jetzt fehlt das natürlich, denen die entsprechend offline waren.

  6. riedenthied sagt:

    Ich hatte hier gerade einen 2004er, der seit September offline war. KB4598481 war notwendig, damit KB5003173 gefunden wurde. Beide sind beim WSUS eigentlich als superseded gekennzeichnet und sollten aus dem Grund trotzdem nicht abgelehnt werden.

    Außerdem hatte ich einen weiteren Rechner mit der 1909, der das Upgrade auf 20H2 installiert hat. Nachdem er sich das vom WSUS gezogen hat, hat er direkt im Anschluss einen weiteren fetten Download gemacht, bevor er mit der Installation begonnen hat. Ich habe nicht verfolgt, wohin er sich verbunden hat, aber der WSUS war es nicht. Ich gehe deshalb davon aus, dass sich die Clients beim Upgrade noch das neueste CU bei Microsoft besorgen und danach nicht auf dem Stand vom Dezember 2020 sind, sondern doch aktuell.

  7. Anonymous sagt:

    und der Detectionbug bei 20H2 geht mit dem Patch vom 13.7 leider weiter ;(
    Wenn das Patch vom 6.7 installiert ist wird das vom 13.7 als installiert erkannt obwohl dies nicht so ist.

  8. MikeRowSoft sagt:

    Hat jemand eine Idee wie man am WSUS die Installation des KB5003173 erzwingen kann, ist ja nun leider Voraussetzung aber gleichzeitig superseeded?

    • Anonymous sagt:

      nein, da ist ja das Problem.
      Lösung (seitens MS) wäre mMn:
      a) das Mai Patch (KB5003173) als nicht superseded zu re-releasen
      (für die bei denen es schon declined ist ohne das sie es gemerkt haben)
      b) keine Patches nach dem Mai Patch als „needed“ zu erkennen wenn das Mai Patch noch nicht drauf ist, dann würde immer erst das Mai Patch installiert.

    • Anonymous sagt:

      In eine eigene wsus gruppe packen in der nur KB5003173 freigegeben ist, aber nicht die neueren.

    • Günter Born sagt:

      War das nicht das Thema, welches ich in in diesem Kommentar mal angerissen und auf die entsprechenden Blog-Beiträge verlinkt habe?

      Schau dir mal den Kommentar von Bolko an. Wenn ich es nicht ganz verpeilt habe, sollte das dein Problem adressieren. Auch wenn dort die direkte Installation des fehlenden SSU auf den Clients mittels dism vorgeschlagen wird. Oder habe ich das Problem jetzt falsch verstanden – WSUS ist nicht so meine Baustelle ;-).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.