[English]Zum 11. Mai 2021 mussten Administratoren feststellen, dass dass im Windows Server Update Service (WSUS) keine Windows-Updates gefunden wurden. Nach einigen Stunden löste sich das Problem. Nun hat Microsoft das Problem bestätigt noch einige Hinweise geliefert.
Anzeige
Ich hatte zeitnah im Blog-Beitrag WSUS erhält keine Updates (11. Mai 2021) über den Sachverhalt berichtet, nachdem ein Blog-Leser mich darauf hingewiesen hatte. Der WSUS zeigte zwar eine erfolgreiche Synchronisation, aber außer Defender Updates kam kaum etwas – vor allem tauchten die zum Patchday (11. Mai 2021) freigegebenen Windows-Updates nicht auf. Im oben verlinkten Blog-Beitrag gab es Hinweise auf Zeitprobleme und dass Microsoft das Problem beheben wolle. Ist dann auch passiert, wie Leser bestätigen.
Microsoft erklärt die Panne
Im Statusbereich von Windows 10 hat Microsoft nun einen neuen Eintrag hinterlegt, in dem man den Sachverhalt nochmals aufgreift. Redmond bestätigt, dass bei der Suche nach Updates in Windows Server Update Services (WSUS) oder Microsoft Endpoint Configuration Manager und verwalteten Geräten, die eine Verbindung zu diesen Servern herstellen, das Sicherheitsupdate für den Windows-Client möglicherweise nicht verfügbar sei oder nicht angeboten wurde. Dies kann auch die kumulativen Rollups für Security Only und Internet Explorer auf den Windows Plattformen betreffen. Betroffen waren praktisch alle unterstützten Windows-Versionen, wie nachfolgende Aufstellung zeigt.
- Client: Windows 10, Version 20H2; Windows 10, Version 2004; Windows 10, Version 1909; Windows 10, Version 1809; Windows 10 Enterprise LTSC 2019; Windows 10, Version 1803; Windows 10 Enterprise LTSC 2016; Windows 10, Version 1607; Windows 10 Enterprise 2015 LTSB; Windows 8.1; Windows 7 SP1
- Server: Windows Server, Version 20H2; Windows Server, Version 2004; Windows Server, Version 1909; Windows Server, Version 1809; Windows Server 2019; Windows Server, Version 1803; Windows Server 2016; Windows Server 2012 R2; Windows Server 2012; Windows Server 2008 R2 SP1; Windows Server 2008 SP2
Inzwischen ist das Problem aber wohl gelöst. Microsoft schreibt dazu, dass man dieses Problem nun auf der "Service-Seite" (also auf den Microsoft-Servern, die die Updates bereitstellen) behoben habe. Meinen Informationen nach wurden falsche Zeitzonenangaben für die Freigabe der Pakete festgelegt, so dass die Updates nicht zur Verteilung freigegeben wurden. Die Updates sollten zwischenzeitlich in WSUS und Co. verfügbar sein.
Hinweis: Wenn ein Synchronisierungszyklus eingeleitet wird und die Updates immer noch nicht angeboten werden, sollte zyklisch geprüft werden, ob Updates ankommen. Inzwischen sollte der Fix aber auf alle Server in allen Regionen weltweit verteilt worden sein. (via)
Anzeige
Anzeige
Genau so wurde es ja in dem verlinkten Twitter-Post beschrieben.
Der ServerSyncWebService, mit dem Microsoft die Updates bereitstellt, arbeitet ähnlich wie ein WSUS es tut, wenn er Parent eines anderen WSUS ist.
Man kann für ein Update nicht nur eine Freigabe einstellen oder ablehnen, sondern auch einen Zeitpunkt (TTLG, Time to go live) dazu hinterlegen.
Das macht Microsoft (die Patches selbst werden schon vorher in der Datenbank hinterlegt und können von Mitgliedern spezieller Testgruppen auch heruntergeladen werden, nicht aber von der Allgemeinheit.
Wie gesagt, alles Standardverhalten der WSUS-API.
Aufgrund der "Reasonable Disclosure Policy" sollen Patches weltweit zum gleichen Zeitpunkt verfügbar gemacht werden, um nicht bestimmten Teilen der Welt einen unfairen Vorteil (sei es einfach frühere Aktualisierung oder sei es Analyse der Patches zum Entwickeln für Exploits) zu geben.
Diesen Zeitpunkt hat Microsoft seit langem auf 10 Uhr Ortszeit im HQ in Seattle (das ist die amerikanische pazifische Zeitzone PST/PDT, also GMT-7) am Patchday (üblicherweise Dienstag der B-Woche) festgelegt. Aufgrund der unterschiedlichen Sommerzeitregelungen auf beiden Kontinenten (erstes April- bzw letztes Märzwochenende) sind das oft 9, manchmal auch 10 Stunden Versatz.
Das Team, welches die Sicherheitsupdates einpflegt hat sich bei der Zeitangabe für die TTGL genau um diese 7 Stunden vertan und somit hat der Update-Server von Microsoft die Upates automatisiert 17 Uhr Seattle Time verfügbar gemacht.
Den zweiten verlinkten Tweet von John Storbeck konnte man entnehmen, daß Microsoft versucht hat, das Freigabedatum direkt in der Datenbank ihres Update-Servers zu korrigieren. Da ein solches SQL Update Statement natürlich aber sehr viel mehr Potential hat Schaden anzurichten als die etliche male abgesicherte UI brauchte es natürlich einen SQL-Guru mit der nötigen Erfahrung (und Zugangsberechtigung) so daß das nicht genau 10 Uhr 01 gemacht wurde, sondern irgendwann in der Nacht.
Wie dem auch sei, jeder von uns kann jetzt seine Server patchen oder – je nach Veranlagung – einen unbeschwerten Vatertag genießen!
Dank für die Ergänzungen.
Erfreulich, weil interessant, dass Du die Hintergründe genauer erläutert hast.
Sage auch "Danke!" dafür.
(Auch, weil Du Günter mit der Recherche entlastet hast;-))
Gruß!
ibbsy
Betrifft: Installation und Verteilung der SSU und CU für Windows 10 Enterprise 1809/1909 und Windows Server 2019 über WSUS.
Was mir gestern nach Freigabe der Updates in WSUS (SSU,CU und .NET) für unsere Clients und Server noch aufgefallen ist:
Bisher war es so, dass die Clients das CU und SSU zeitgleich bzw. in einem Rutsch beim WSUS angefordert, heruntergeladen und installiert haben.
Gestern war es dann so, dass alle Clients und Server zunächst nur das SSU und weitere Updates wie z. B. .NET und Office als benötigte Update erkannt und heruntergeladen haben.
Erst nach erfolgreicher Installation des SSU und erneuter Suche nach Updates wurde auch das CU als benötigtes Update erkannt, heruntergeladen und installiert.
Ärgerlich ist die Sache auf jeden Fall für das Einspielen der Updates auf den Servern wo auch .NET Updates anstehen, da diese nun 2-mal neu gestartet werden müssen.
Also:
– Suche nach Updates auf den Servern
– SSU, .NET und Office-Updates werden gefunden, heruntergeladen und installiert
– Neustart des Servers erforderlich
– erneute Suche nach Windows Updates
– erst jetzt wird das CU gefunden, heruntergeladen und installiert
– zweiter Neustart erforderlich
Fazit:
Aktuell werden SSU und CU über WSUS nicht mehr gemeinsam angefordert, heruntergeladen und installiert.
Zuerst wird das SSU angefordert und nach Installation und erneuter Update-Suche wird auch das CU erkannt und installiert.
Ich weiss jetzt nicht, ob das an unserer Umgebung liegt.
Daher die Frage in die Runde, kann das jemand bestätigen?
ganz einfach
https://support.microsoft.com/en-us/topic/may-11-2021-kb5003171-os-build-17763-1935-3f03e74b-4759-4ca3-b9f1-4bc0d5ab5d27
"You MUST install the May 11, 2021 servicing stack update (SSU) (KB5003243) or later before installing the latest cumulative update (LCU)."
ganz einfach dinge, die der admin und die welt nicht brauchen. alle updates auf einmal installieren und beim reboot löst sich alles. nicht erstmal 5 updates, dann wieder ein update, und danach wieder 3 updates.
das kann sich keine firma leisten. bei uns im rechenzentrum ist gefordert, dass 100ere server automatisiert zum zeitpunkt x patchen, automatisiert rebooten und fertig sind.
bekommt die opensource gemeinde in linux ja auch wunderbar hin.
aber in redmond muss man wieder so einen dreck sie service stack und was nicht alles konstruieren.
keep it short and simple is dort halt mal wieder ein fremdwort.
Danke, aber dass betrifft nich die Probleme, die ich in meinem Kommentar beschrieben habe (sorry, vielleicht habe ich mich da auch missverständlich ausgedrückt).
Wie dem auch sei, ich habe mir heute die Update-Logs vom April angeschaut.
SSU und CU wurden vom WSUS zeitgleich heruntergeladen und in der Reihenfolge SSU + CU ohne Probleme installiert.
Mit den Mai-Updates über WSUS:
– nur das SSU wird zuerst als benötigstes Update erkannt, heruntergeladen und installiert.
– nach erneuter Update-Suche: CU wird als benötigstes Update erkannt, heruntergeldaeb und installiert,
@MOM20xx
+1 geht mir auch so
War letzten Monat zum grossen Teil bei mir schon auf den 1909 Patches so gewesen.
Aktuell sehe ich auch dass zuerst der SSU kommt und erst danach der CU.
Ich habe aber in den letzten 2 Monaten verhältnismässig viele Maschinen bei denen der CU dann nicht oder erst beim 2. oder 3. Versuch installiert wird. (H2 aktuell)
Allgemein ist wohl die Qualität des April und Mai CU nicht so hoch wie davor oder die Umstellung dass die SSU teils integriert ist (H2) oder jetzt nicht mehr gleichzeitig läuft macht es nicht stabiler.
vielleicht hätt man es auch so belassen sollen wie es mal in windows 7 windows server 2008 r2 oder server 2012 r2 ist. die lassen sich noch am einfachsten und schnellsten patchen. server 2016 eine zumutung, was die patchzeit bedingt, server 2019 scheint aber langsam aber sicher aufzuholen.