Microsoft hat im August zwei kumulative Updates KB4034658 und KB4034661 für Windows 10 Anniversary Update (Version 1607) freigegeben. Diese führen aber zu Problemen mit WSUS, die Clients laufen bei der Update-Suche auf den Fehler 0x8024401c.
Anzeige
Worum geht es?
In Business-Umgebungen lässt sich auf Windows Server die Verteilung von Updates an Clients per WSUS vornehmen. Windows Server Update Services (WSUS) ist dabei eine Komponente von Windows Server (ab Version 2003).
Allerdings hat Microsoft keine wirklich glückliche Hand mit seinen Updates für Windows-Clients in Verbindung mit WSUS. In den letzten Monaten gab es immer wieder Probleme, dass Updates die Verbindung der Clients zu WSUS blockierten. Ich erinnere an meinen Blog-Beitrag Microsofts Juli 2017-Updates KB4025336/KB4025331 als WSUS-Killer, wo es unter Windows Server 2012 R2 mit Updates Probleme gab.
Windows 10 Version 1607: KB4034658 & KB4034661
Im August 2017 wurden von Microsoft zwei kumulative Updates KB4034658 (am 8. August 2017) und KB4034661 (am 16.8.2017) für Windows 10 Anniversary Update (Version 1607) freigegeben. Diese führen aber zu Problemen mit WSUS, die Clients laufen bei der Update-Suche auf den Fehler 0x8024401c.
Ich hatte dies, auf Grund von Leserkommentaren, in den Blog-Beiträgen Probleme nach Microsoft August-Updates und Windows 10 V1607: Update KB4034661 verfügbar (16.8.2017) bereits erwähnt und von der Verteilung des Updates KB4034661 abgeraten.
Anzeige
Beschreibung des Fehlers
Nach der Installation der obigen Updates auf dem Windows 10-Client, kann dieser nach dem Neustart keine Verbindung mehr zum WSUS aufnehmen. Die Clients laufen bei der Update-Suche auf den Fehler 0x8024401c.
Ich bin bereits am 13. August 2017 auf den Blog-Beitrag WSUS SUP causes high CPU and clients fail updates scan (Englisch) gestoßen, der von einer hohen CPU- und RAM-Belastung bei WSUS durch Windows 10-Clients berichtet und einige Maßnahmen zur Abhilfe vorschlägt.
Robert Wray hat am 15. August 2017 den Artikel 2017-08 update for Windows 10 Anniversary Update ("1607") breaks WSUS veröffentlicht, der das Update KB4034658 benennt und Details zur Deinstallation dieses Pakets enthält.
Microsoft hat den Bug bestätigt
Beim Schreiben des Blog-Beitrags Windows 10 V1607: Update KB4034661 verfügbar (16.8.2017) fiel mir auf, dass Microsoft das WSUS-Problem am 16. August 2017 als bekannten Fehler bei den kumulativen Updates KB4034658 (am 8. August 2017) und KB4034661 (am 16.8.2017) für Windows 10 Anniversary Update (Version 1607) führt.
WSUS servers will exhibit increased CPU, memory, and network utilization when Windows Update clients perform their first scan after installing KB4034658.
Microsoft untersucht zur Zeit das Problem und will so schnell als möglich Details veröffentlichen. Bis dahin bleibt lediglich die betreffenden Updates zur Installation auf den Clients zu sperren und sofern bereits installiert, wieder zu deinstallieren.
Ergänzung: Microsoft erklärt das Problem
Blog-Leser Dietmar hat in den Kommentaren den Link zum Microsoft Technet-Artikel High CPU/High Memory in WSUS following Update Tuesdays gepostet (danke für den Link – bei Askwoody.com findet sich ebenfalls ein Hinweis). Dort hat Microsoft (entweder parallel zu meiner Veröffentlichung dieses Artikels oder kurz danach) eine Erklärung veröffentlicht, warum das Problem auftritt.
Hintergrund ist, dass die WSUS Metadaten für die Update-Pakete in einem Cache führt.
WSUS has a caching mechanism whereby the first time update metadata is requested by any client WSUS will store it in memory. Further requests for the same update revision will retrieve the update metadata from memory instead of reading it from the database. Some of the metadata in the database is compressed, so not only must it be retrieved, it must be decompressed into memory, which is an expensive operation.
Wenn sehr viele Clients die Metadaten für die Update-Pakete anfordern, kommt es zu einer verzögerten Auflösung der Daten:
For large metadata packages and many simultaneous requests, it can take longer than ASP.NET's default timeout of 110 seconds to retrieve all of the metadata the client needs. When the timeout is hit, ASP.NET disconnects the client and aborts the thread doing the metadata retrieval.
Sobald also ein Timeout am Client auftritt, welches 110 Sekunden übersteigt, trennt ASP.NET den Client, so dass die Fehlermeldung wohl ausgelöst wird. Interessant ist dabei folgende Hintergrundinformation: Für die Updates der Version 1703 klappt momentan noch alles, weil nur sehr wenige Pakete vorliegen. Bei den Updates der Version 1607 kommt es aber bei der Update-Suche sehr schnell zu obigem Problem. Microsoft gibt im Technet-Artikel Hinweise, wie man feststellt, ob das Problem an den letzten Updates liegt. Weiterhin finden sich Hinweise für Workarounds, um den Fehler zu umgehen.
Ähnliche Artikel:
Windows 10 V1607: Update KB4034661 verfügbar (16.8.2017)
Windows 10 Version 1607: WSUS-Fehler 0xc1800118 gefixt
Windows 10 Version 1607: WSUS und Download von Updates
Microsofts Juli 2017-Updates KB4025336/KB4025331 als WSUS-Killer
Microsoft erklärt das WSUS-Problem in Windows 10 V1607 (Fehler 0x8024401c)
Anzeige
Das Problem tritt (logischerweise) auch bei Server 2016 auf (da diese mit 1607 identisch sind). Nach meinen bisherigen Erkenntnissen darf das Update KB4034658 nicht auf dem WSUS-Server (bei mir ein Windows Server 2016) sein, der Update-Agent bringt den erwähnten Fehler. Auf den anderen 2016-er darf es sein. Windows 10 1607 habe ich nicht (sind auf 1703).
Ich hatte das Update auf dem 2016er-WSUS installiert und wieder entfernt, aber auch danach funktionierte das Abfragen von Updates nicht. Erst, nachdem ich im IIS für den Application Pool "WsusPool" die Werte "Queue Length" auf 25000 (vorher: 1000) und "Private Memory Limit (KB)" auf 0 (vorher: 1843200) setzte, funktionierte es wieder. Das Update bleibt momentan weg vom WSUS-Server, auf den anderen 2016ern habe ich es drauf. Nach dem erfolgreichen Abfragen von Updates habe ich die Werte des WsusPool wieder auf Standard gesetzt und im Moment funktioniert alles wunderbar.
Gegenfrage wie soll man es per WSUS deinstallieren wenn die Clients keinen Kontakt mehr herstellen können?
Ivo du solltest deine wertvolle Lösung an Microsoft melden. Da es offensichtlich ein Bug ist bekommst du dein Geld für den Supportcase ja wieder.
Schreib ein Skript das überprüft, ob das jeweilige KB installiert ist, wenn ja > Uninstaller anstoßen, ansonsten exit. Das Skript würde ich in der Startup GPO einhängen. Aber teste es unbedingt bevor du es einsetzt und ändere es ab. Die wichtigen beiden Kommandos hast du aber bereits zu Hand, die Abfrage mit WMIC nach dem KB und das Uninstall Kommando über WUSA.
Könnte so aussehen, hab ich aber nicht getestet. Ggf. noch nen Reboot am Ende einbauen, aber nur wenn er auch was deinstalliert hat ;-)
wmic qfe list | find "KB4034658"
if %errorlevel% EQU 0 (
wusa /uninstall /kb:KB4034658 /quiet /norestart
)
wmic qfe list | find "KB4034661"
if %errorlevel% EQU 0 (
wusa /uninstall /kb:KB4034661 /quiet /norestart
)
exit
Snaker das man es per Script entfernen kann, bestenfalls als shutdown per GPO (erspart den Neustart) ist ohne Zweifel. Codetechnisch einfacher wäre es noch via powershell.
Jedoch ist das nicht die Antwort auf meine Frage. Nur ein Workaround einer Lösung. Ich hoffe meine Intention ist deutlich.
Wenn die Antwort auf meine Frage ist: "Geht nicht", jt es MS abermals geschafft ein Update auszurollen, das man ohne manuellen Eingriff nicht mehr korrigieren kann. Zuletzt war dies in großem Umfang schon mit dem WU Problem das im Juli 2016 gepacht wurde so, und auch danach das ein oder andere Mal.
Nunja, als Admin ist es natürlich unsere Aufgabe, die Steine, die uns die OS-Hersteller in den Weg legen, aus dem Weg zu räumen. Schön ist etwas anderes und gefühlt hat das in den letzten 12 Monaten tatsächlich sehr zugenommen, dass hier derlei Fauxpas passieren, grobe Schnitzer die unseren Arbeitsalltag nur unnötig erschweren. Mir ist bereits mehrfach aufgefallen, dass Windows 10 gerade nach einem Funktionsupdate anschließend nicht mehr mit dem WSUS kommunizieren will, beim AU 1607 war das auf jeden Fall so und beim aktuellen CU ebenfalls. Erst das darauf folgende Kumulative Update schaffte es, das zu beheben. Dass dann MS seine Updatepolitik alle paar Monate abändert macht es nicht besser. Gefühlt war es "früher" besser und das obwohl der Rest des Betriebssystems durchaus in vielen Bereichen zu überzeugen weiß, schnell arbeitet, ansehnlich ist. Aber Sie haben Recht, es kann nicht andauernd unsere Aufgabe sein, den Bockmist von Microsoft auszubügeln und "drumherum" zu arbeiten. Diese Entwicklung empfinde ich wie Sie als Belastung und sehe sie mit großer Besorgnis.
Seht euch das mal an: https://blogs.technet.microsoft.com/configurationmgr/2017/08/18/high-cpuhigh-memory-in-wsus-following-update-tuesdays/
Danke für den Hinweis – sehr aufschlussreich. Ich habe ein paar Zeilen in obigem Beitrag ergänzt. Als mein Beitrag erstellt wurde, habe ich den Artikel bei der Suche noch nicht gefunden.
Alle Windows 10 1607 bzw. Server 2016 1607 hatten den Fehler 0x8024401c.
Diverse IIS Application Pool Tuning Empfehlungen brachten keine Lösung.
Abhilfe brachte Adamj Clean-WSUS PowerShell 3 script auf dem WSUS Server siehe:
http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus
https://community.spiceworks.com/topic/1970827-wsus-on-server-2016-windows-10-1607-client-0x8024401c-error