Microsoft fixt WSUS-Bug der verhinderte, dass Updates für Windows 11 22H2/Server 2022 angeboten wurden

Windows[English]Seit Februar 2022 gab es das Problem, dass im Windows Server Update Service (WSUS) Updates nicht auf Clients mit Windows 11 22H2 sowie auf Windows Server 2022 verteilt werden konnten. Ich hatte sogar im Blog einen entsprechenden Beitrag zum Thema publiziert. Nun hat Microsoft den Bug in diesem Bereich, der das Bereitstellen von Updates für Windows 11 22H2 sowie für Windows Server 2022 in WSUS seit Februar 2022 verhinderte, beseitigt.


Anzeige

Erinnerungsmäßig haben hier im Blog Administratoren immer mal wieder (z.B. hier) berichtet, dass in WSUS bestimmte Updates, die ich zum Patchday aufgelistet habe, nicht im WSUS auftauchten. Das konnte häufig auf Konfigurationsfehler (Kategorie zur Synchronisation nicht ausgewählt) oder andere Ursachen zurückgeführt werden oder war "Einzelfall".

Es gab aber von mir den Blog-Beitrag Microsofts Februar 2023-Patchday: Falsche Updates in WSUS, Exchange und Windows, der das Problem aufgriff, dass mit dem Februar 2023 in bestimmten Konstellationen Updates für Windows 11 22H2 sowie für Windows Server 2022 über WSUS nicht verteilt werden konnten.

Fix für das WSUS-Problem

Nun hat Microsoft bekannt gegeben, dass dieses Problem im WSUS, das die Verteilung von Updates für Windows 11 22H2/Server 2022 in bestimmten Szenarien verhinderte, mit den Juli 2023-Updates behoben sei. Auf der Windows Health Statusseite für Windows Server 2022 findet sich im Abschnitt "Resolved Issues" ein entsprechender Hinweis mit dem Titel WSUS might not offer updates to Windows 11, version 22H2. Dort heißt es:

Updates released February 14, 2023 or later might not be offered from some Windows Server Update Services (WSUS) servers to Windows 11, version 22H2.

In Kurzfassung: Seit dem im Februar 2022 veröffentlichten Sicherheitsupdate gibt es Probleme mit der Verteilung von Updates über WSUS. Dabei ist nicht nur Windows 11 Version 22H2 betroffen. Sondern Microsoft gibt auch an, dass der Bug sich ebenfalls auf die Verteilung von Updates für Windows Server 2022 auswirken kann. Die Updates werden zwar auf den WSUS-Server heruntergeladen, aber möglicherweise nicht an die Client-Geräte weitergegeben.


Anzeige

Das Ganze betrifft aber nur Systeme mit WSUS-Server mit Windows Server 2022, die von Windows Server 2016 oder Windows Server 2019 aktualisiert wurden. Hintergrund ist, dass die erforderlichen Unified Update Platform (UUP)-MIME-Typen versehentlich bei Windows Server 2022 entfernt wurden. Ich hatte im Blog-Beitrag Windows Server Feb. 2023-Updates: Kollateralschäden mit MIME-Typen auf dieses Thema hingewiesen. Administratoren hatten in den letzten Monaten die Möglichkeit, betroffene Maschinen manuell mit den Definitionen für die fehlenden Mime-Typen nachzurüsten (siehe Adding file types for Unified Update Platform on premises). Laut Microsoft ist das nun aber nicht mehr erforderlich, denn das Problem wurde zum 14. Juli 2023 mit dem Sicherheitsupdate KB5023705 für Windows Server 2022 behoben. (via)


Anzeige

Dieser Beitrag wurde unter Problemlösung, Update, Windows abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

14 Antworten zu Microsoft fixt WSUS-Bug der verhinderte, dass Updates für Windows 11 22H2/Server 2022 angeboten wurden

  1. 1ST1 sagt:

    Beknackt, dass MS über 6 bzw. 11 Monate (je nach dem ob man beim Born- oder MS-Artikel aufs Erscheinungsdatum schaut) brauchte, um das mit einem Patchdayupdate zu fixen.

  2. Anonymous sagt:

    @Günni

    1)
    "14. Juli 2023 mit dem Sicherheitsupdate KB5023705"
    KB5023705 ist vom 14 März 2023 und der Juli Patchday ist am 11 Juli gewesen.

    2)
    "Windows Server 2022 in WSUS seit Februar 2022"
    vs
    ", dass mit dem Februar 2023 in bestimmten Konstellationen"
    "Updates released February 14, 2023 or later might not be offered from"

    Ergo war das ganze nach dem nächsten Patchday schon wieder gefixt!?

    • pau1 sagt:

      Sollte man seine Systeme nicht auf den aktuellen Patchstand halten, oder sind diese Patches doch nicht soooo wichtig, dass man sie auch mal 3 Monate aussetzen kann?

      Könnte es sein, das MS nur noch von da er Substanz lebt?

      • Fritz sagt:

        Gut erkannt.

        Microsoft hat ein gewisses "Glück" darin, wichtige Trends zu verschlafen – Beispiele gab es in der Vergangenheit genug.

        Ein Trend, den sie möglichst nicht verschlafen wollen ist es, große Rechenzentren zu errichten und den Nutzern die Technik darin nutzungsabhängig zu vermieten.

        Google und Amazon haben vorgemacht wie man damit ein weiteres Standbein aufbaut, welches mindestens so tragfähig ist wie das bisherige Kerngeschäft.

        Nachdem die Android- und iOS-Ökosysteme enteilt sind ist es auch für Microsoft höchste Zeit eine Plattform zu schaffen, die einen niederschwelligen (d.H. bis auf die Hardware kostenlosen) Zugang zu den in der Cloud liegenden Diensten ermöglicht.

        Ich denke die Zeit "fetter" Desktopanwendungen ist vorbei. Während sich heute vermutlich kaum jemand erlauben kann einen kostenpflichtigen Webbrowser auf den Markt zu bringen ist die Lizenzpflicht für Betriebssystem und Standard-Officeanwendungen (Mail!) inzwischen ein größeres Hindernis.

        Mal ehrlich, wann hast Du für ein Windows das letzte mal wirklich (also nicht als Bundle mit Hardware oder kostenloses Update) bezahlt?.

        Die Web-Anwendungen der Office-Anwendungen (Word, Excel…) sind nur ein folgerichtiger Schritt – sie erfordern auf Anwenderseite weder großartige Installation noch eben Lizensierung.

        Microsoft selbst hat ja schon oft angekündigt wo sie hin wollen: kein Office on-premise mehr und idealerweise nur noch ein rudimentäres Windows als Programmstarter zur Verbindung zu der in der in der Cloud liegenden gemieteten Instanz.

        Das vereinfacht auch die Wartung ungemein, eine zentrale (M365) Exchange-Instanz ist eben schneller und konsequenter zu patchen als tausende bei den Endanwendern auf die Server verteilte.

  3. Fritz sagt:

    Genau in dieses gleiche Chaos ist Microsoft vor etlichen Jahren schon mal bei der Verteilung der Windows-10-Updates hinein gelaufen.
    Damals war es der Mime-Type .esd, der im IIS nicht vordefiniert war und deswegen per Default als ASCII ausgeliefert wurde – was Binärdateien natürlich inhaltlich zerstört.

    Es sind gleich zwei Designentscheidungen im IIS, die dieses Chaos begünstigen:
    1) unbekannte Dateitypen werden nicht as-is sondern zwanghaft in ASCII ausgeliefert, man muß sie zwingend als Binärinhalt deklarieren
    2) Eine Deklaration in einem untergeordneten Kontext (Verzeichnis oder virtueller Host) ist sowohl in der Datei als auch über den IIS-Manager erst mal möglich, verhindert aber, daß der IIS startet, wenn sie einer übergeordneten Direktive widerspricht (der zweite Screenshot im Februar-Beitrag).

    Wenigstens ist die Liste etwas kleiner als die von Sophos in einem vergleichbaren Szenario:

  4. 1ST1 sagt:

    Firefox 116 und 115.1 sind da.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

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.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.