Microsoft hat nun eine Erklärung abgeliefert, warum die letzten kumulativen Updates in Windows 10 Anniversary Update (V1607) und Windows Server 2016 zu Verbindungsproblemen mit dem Fehler 0x8024401c in Umgebungen mit WSUS führen.
Anzeige
Worum geht es?
Updates können in Unternehmensnetzwerken über einen zentralen Windows Server per Windows Server Update Services (WSUS) verteilt werden. Dies ermöglicht Administratoren Updates gezielt für Clients freizugeben. So weit die Theorie und die Praxis funktionierte auch lange Jahre.
In letzter Zeit scheint Microsoft aber keine glückliche Hand mehr in Bezug auf WSUS zu haben. Zu häufig verursachen Updates für Windows Server oder für die Windows Clients Probleme mit WSUS (siehe Linkliste am Artikelende). In Windows 10 Anniversary Update (V1607) kommt es bei der Installation von Updates (seit Wochen) zum Problem, dass die Clients anschließend keine Verbindung mehr mit dem Windows Server Update Services (WSUS) aufnehmen können.
Update Fehler 0x8024401c bei Windows 10 V1607
Ich hatte auf diesen Sachverhalt bereits im Blog-Beitrag Windows 10 (V1607): WSUS-Fehler 0x8024401c mit KB4034658 und KB4034661 hingewiesen. Nach Installation der genannten Updates kommt es zu einer hohen CPU- und RAM-Auslastung und der Client liefert irgendwann den Update-Fehler 0x8024401c und bricht ab. Der Fehlercode 0x8024401C steht für WU_E_PT_HTTP_STATUS_REQUEST_TIMEOUT – Same as HTTP status 408 – the server timed out waiting for the request. Also: Es tritt ein Timeout bei der Verbindung zum Server auf.
Abhilfe schaffte bisher nur das Blocken diverser kumulativer Updates und falls diese installiert waren, deren Deinstallation. Das hatte ich in den diversen Blog-Beiträgen thematisiert. Viel interessanter ist aber, warum der Timeout auftritt.
Anzeige
Ein paar Erklärungsansätze hier im Blog
Im Blog-Beitrag Windows 10 (V1607): WSUS-Fehler 0x8024401c mit KB4034658 und KB4034661 hatte ich auf auf den Blog-Beitrag WSUS SUP causes high CPU and clients fail updates scan (Englisch) hingewiesen. Er schreibt:
When a client performs a scan, WSUS will generate an XML response to the client with the update metadata. This will vary in size depending on what products and categories you are syncing in WSUS and what updates you have that are not declined or expired.
Er hat also folgerichtig beobachtet, dass die Clients mit dem WSUS über XML-Datensätze mit Metadaten kommunizieren, um Updates auszutauschen. Im Artikel schreibt der Autor, dass der WSUS zum Erzeugen der XML-Antwortdateien für Windows 10-Clients einen WSUS IIS Worker Process startet. Dieser konsumiert die komplette CPU-Leistung, was zu anderen Problemen auf dem WSUS-Server führe. Manchmal könne die Anforderung nach Minuten ausgeführt werden, manchmal wird die Aufgabe niemals durchgeführt.
(Quelle: kickthatcomputer)
Dann tritt irgendwann ein Timeout auf, und die Clients werfen den oben erwähnten Fehlercode 0x8024401c. Im System Center ConfigMgr findet sich dann ein Fehlereintrag (siehe obiger Screenshot).
Eine sehr interessante Nebenbemerkung betrifft die SCCM-Clients. Er schreibt 'Configuration Manager clients have a "special" feature that plain WSUS clients don't have. When a request to scan fails they will retry 4 times before waiting to try again the next day. WSUS clients don't retry.' Beim SCCM wird eine Anfrage vier Mal wiederholt, und am nächsten Tag startet ein neuer Versuch. Im besten Fall klappt dann die Kommunikation mit den Clients und das Update wird ausgerollt. Im schlechtesten Fall führen die Wiederholungen zu einer Auslastung des Servers über längere Zeit.
Im Blog-Beitrag analysiert Scott Williams den Sachverhalt und führt vieles auf den von WSUS verwendeten IIS zurück. Zudem schlägt er einige Maßnahmen zur Abhilfe vor.
Microsoft erklärt die Hintergründe
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.
Der Stand war dort, dass Microsoft das Ganze untersuche und und so schnell als möglich Details veröffentlichen will. Blog-Leser Dietmar hat dann den Kommentar mit dem Link zum Microsoft Technet-Artikel High CPU/High Memory in WSUS following Update Tuesdays gepostet. Dort legt Microsoft die Ursache für das Problem offen – ich würde es als Designfehler interpretieren. Auf dem WSUS-Server gibt es folgende Symptome:
- High CPU on your WSUS server – 70-100% CPU in w3wp.exe hosting WsusPool
- High memory in the w3wp.exe process hosting the WsusPool – customers have reported memory usage approach 24GB
- Constant recycling of the W3wp.exe hosting the WsusPool (identifiable by the PID changing)
- Clients failing to scan with 8024401c (timeout) errors in the WindowsUpdate.log
- Mostly 500 errors for the /ClientWebService/Client.asmx requests in the IIS logs
Nach einer Analyse hat Microsoft herausgefunden, dass es vor allem bei Updates für Windows 10 Version 1607-Clients auftritt (Updates KB4022723, KB4022715, KB4025339 und so weiter). Die tiefere Ursache besteht darin, dass diese kumulativen Updates sehr umfangreiche Metadateien aufweisen, in denen die Abhängigkeiten festgehalten sind, um die benötigten Binärdateien installieren (und ggf. deinstallieren) zu können.
Nun werden die Metadaten vom WSUS in einem Cache im Arbeitsspeicher gehalten, um schneller auf Anforderungen reagieren zu können. Da die Metadaten teilweise noch komprimiert sind, kommt es zu diesen Speicheranforderungen:
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.
Fordern sehr viele Windows 10 Version 1607-Clients nun Updates per WSUS an, kommt es zu einer verzögerten Auflösung der Daten und gegebenenfalls zum oben erwähnten Timeout:
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 mit dem Fehler 0x8024401c am Client ausgelöst wird. Interessant ist dabei die Aussage, dass die Updates für Windows 10 Version 1703-Clients aktuell noch ausgerollt werden können, weil nur sehr wenige Pakete vorliegen. Es ist also nur eine Frage der Zeit, bis mit zunehmender Anzahl an kumulativen Updates für Windows 10 Creators Update (Version 1703) das Problem auch auftritt.
Im Technet-Beitrag schlägt Microsoft verschiedene Workarounds vor, um das Problem künftig zu umgehen.
- Configure IIS to stop recycling the App Pool
- Limit the number of inbound connections to WSUS
- Increase the ASP.NET timeout
Es sollten imho alle Maßnahmen ausgeführt werden, in der Hoffnung, dass dann die WSUS-Anfragen von den Windows-Clients sauber abgewickelt werden können. Für optimal halte ich das Ganze nicht – die Workarounds sorgen ja nur dafür, dass die Zahl der Anfragen an den WSUS und die CPU-/Memory-Belastung durch das Recycling des App-Pools reduziert werden. Zudem soll das Heraufsetzen des ASP.NET-Timeout das Triggern des Fehlers 0x8024401c verzögern. Da das Ganze aber ein Problem ist, welches durch dynamische Belastungen auftritt, bin ich nicht wirklich sicher, ob diese Fehler nicht mehr auftreten (speziell, wenn viele Clients vom WSUS bedient werden). Aber ich bin da kein Spezialist, zumal ich keinen WSUS betreibe (den letzten WSUS habe ich vor vielen Jahren mal aufgesetzt, um die Thematik in einem Windows 7-Buch zu behandeln).
Aber zumindest kennen Administratoren jetzt den Grund für den Fehlercode 0x8024401c bei Updates vom WSUS wissen, wo sie eingreifen können. Falls ihr andere Insights habt oder zu anderen Schlussfolgerungen gelangt, könnt ihr ja einen Kommentar hinterlassen.
Ähnliche Artikel:
Windows 10 (V1607): WSUS-Fehler 0x8024401c mit KB4034658 und KB4034661
Probleme nach Microsoft August-Updates
Windows 10 V1607: Update KB4034661 verfügbar (16.8.2017)
Microsofts Juli 2017-Updates KB4025336/KB4025331 als WSUS-Killer
WSUS-Installationsproblem mit KB4025252 teilweise gelöst
WSUS-Synchronisation scheitert seit April 2017-Patchday
Windows 7/8.1/Server: WSUS-Update KB4012864
Windows 10 Version 1607: WSUS-Fehler 0xc1800118 gefixt
Update KB3095113 ermöglicht WSUS-Support für Windows 10-Feature Upgrades
Windows 10: Update-Fehlercodes 0x8024…. entschlüsselt
Tipp: Windows Update Error Codes 0x8024xxxx dokumentiert
Anzeige
Hallo Günter danke für den Beitrag. Ich würde mich als Spezialisten im Bereich WSUS bezeichnen.
Die Erklärung von Microsoft ist für mich nicht schlüssig. Dieser Fehler hätte dann ebenfalls bei Windows 10 1507 und 1511 auftreten müssen.
oder auch früheren Versionen. Es ist bekannt, dass das hosten vieler Updates im WSUS zu verlängerten Anfragen und Suchzeiten des Clients führt. Das sollte man es vermeiden zu viele Produkte auf dem WSUS zu aktivieren, ja sogar bei sehr inheterogenen Umgebungen mehrere WSUS Server einzusetzen z. b einen für XP bis Windows 7 einen für Windows 8.x und einen für alle windows 10 Releases.
Ebenso sollte man zugunsten der Performance auf Bereitstellung von Treibern verzichten, was an sich bedauerlich ist. Treiberpakete sind bei Windows 10 su
ogar dupliziert "Windows 10 xxxx servicing drivers" oder "Windows 10 xxx servicing and later drivers"
alles in allem ist die Windows internal database mit seit 2008 r2 bis 2016 unverändert und hat ein kleines Limit.
es gibt nur eine Abhilfe: ein ultimative powershell Script aus der technet gallery welches mehrere WSUS Datenbank und Maintenance jobs ausführt weil WSUS die Datenbank nur unzureichend bereinigt und pflegt.
Dies führt dann auch auch zu timeouts auf dem Server selbst in der WSUS mmc beziehungsweise Ursache der Datenbank.
Ich suche dir dieses Script raus. Es ist das Beste was ich je gefunden habe.
wie gesagt ich finde die Erklärung von MS hanebüchen. Windows 7 hat wesentlich mehr Updates und Abhängigkeiten. Und genau diese Metadaten sollten doch durch die kumulativen Updates bei allen verringert werden.
Meine Vermutung ist das dass Problem hausgemacht ist, und durch die Bereitstellung von Delta Updates verschärft wird, da so Updates übersprungen werden können.
bis später… und danke nochmal.
Danke Karl für die Insights. Mir schoss zwar beim Schreiben des Beitrags der Gedanke 'warum tritt der Fehler nicht bei V1507 und V1511 auf?' durch den Kopf. Aber ich habe mich wohl selbst in den Fuß geschossen, weil ich meinte, dass WSUS erst ab Windows 10 V1607 unterstützt werde. Habe das mit dem Thema Windows 10 Anniversary Update ab 16.8.16 in WSUS verwechselt.
Ich habe nun mal nachgezählt, wie viele Updates es für die diversen Windows 10-Versionen gab.
Schaut man sich diese Zahlen an, ist es imho klar, dass es zuerst bei Windows 10 Anniversary Update platzen muss. Gleichzeitig gehe ich davon aus, dass dort das Gro der Installationen – zusammen mit V1703 – liegt.
Ob Delta-Updates, die erst ab V1703 unterstützt werden, da mit hineinspielen, kann ich nicht endgültig beurteilen. Die Wahrscheinlichkeit spräche eigentlich dagegen – oder?
Den Fehler gab es übrigens bereits Anfang des Jahres 2017 (siehe hier) und im Mai 2017 hat jemand hier auch schon Workarounds beschrieben.
BTW: Bei Windows 7 gab es übrigens immer mal wieder WSUS-Connect-Probleme bei Update Rollups. Dort trat der Fehlercode 0x80244019 auf, der für WU_E_PT_HTTP_STATUS_NOT_FOUND – Same as HTTP status 404 – the server cannot find the requested URI (Uniform Resource Identifier) – steht.
Insgesamt eine unbefriedigende Situation, aus Sicht der Admins. Drei Kreuze, dass ich damit nix am Hut habe ;-).
Habe bei mir AdamJ's WSUS Cleanup Script laufen und die "interne Windows DB" für WSUS auf ne normale SQL-Server Instanz migriert. Danach waren die die Timeouts weg. Gegen das Juli/August-Win10-1607 Patchproblem half das aber nicht – der Fehler 0x8024401c kam bei meinen Win10-1607-Clients trotzdem.
Hallo Oli, Günter. Ja genau das ist das Script von dem ich sprach
https://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus
Wenn aber selbst dies nicht mehr hilft Oli dann weiß ich auch nicht mehr weiter, als den offiziellen Workaround zu nutzen.
nochmal zu der Anzahl der Updates 29 ist ja quasi niedlich, zumal alle vorherigen CUs im wsus abgelehnt sein sollten, also blieben für einen nackten 1607 Client vielleicht 5 übrig. Die Windows Versionen vor 10 haben mehr als 200 Patches. Ich mag immer noch nicht glauben das dies das Problem ist. Wenn man Windows 7 mit den 2 WU patches Juli 2016 versieht funktioniert es selbst mit gelöschter Datenbank, wie sie eben durch das Update resettet wurde. Mich würde die Erklärung dieses Problem von Microsoft interessieren.
Servus,
in diesem Artikel wird erklärt, wie man den Speicher der WSUSPools etwas nach oben drehen kann. Alternativ auf 0 setzen, dann hat der WSUSPool freie Fahrt. https://www.404techsupport.com/2016/03/21/iis-wsus-private-memory/
BTW: Sollte man von der WSUS-Konsole aus wieder mal keinen Kontakt zum WSUS bekommen, überprüfen ob der WSUSPool auch läuft. Falls nicht, einfach per Rechtsklick starten, Konsole schließen und neu starten. Jetzt sollte wieder ein Verbindung bestehen.
Zusätzlich sollte wirklich täglich ein Bereinigungsscript laufen und es sollten auch täglich die Indexe und Statistiken der SQL Server Datenbank SUSDB neu erstellt werden.
https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61
Auch kann es nicht schaden einmal pro Woche die Synchronisierungen zu löschen:
— Synchronisierungen löschen
PRINT 'Synchronisierungen löschen.' + convert(nvarchar, getdate(), 121)
USE SUSDB
GO
DELETE FROM tbEventInstance WHERE EventNamespaceID = '2' AND EVENTID IN ('381', '382', '384', '386', '387', '389')
PRINT 'Synchronisierungen gelöscht.' + convert(nvarchar, getdate(), 121)
Ich gebe Karl recht, ich habe bei uns WSUS auf einem SBS2011 im Einsatz und alle Clients mit Windows 10 1511 und keinerlei Probleme. Das Windows10 1607 mehr Updates als 1511 hat, leucht mir nicht wirklich ein.
Ich habe auf unserem WSUS-Server aber nur Updates zu Produkten eingestellt, welche wir auch wirklich Nutzen (Office2010, Exchange2010, Server 2008-2016 etc.) und auch nur die Sprache welche installiert ist. Ev. führt ein selektives Auswählen von Produkten zu einer reduzierten Last.
Da man die letzten Jahre aber kaum Probleme mit WSUS gehabt hat, muss das Problem aber mit den Augustupdates hausgemacht sein. Oder wieso passiert das Problem nicht mit Windows 7 oder 8 Clients, die haben doch sicher tausende Updates in der Warteschlange…
Zufall oder nicht, aber die Schritte aus dem Artikel hier haben bei mir offenbar funktioniert:
https://community.spiceworks.com/topic/1970827-wsus-on-server-2016-windows-10-1607-client-0x8024401c-error
Hallo allerseits
Vielen Dank für die hilfreichen Erläuterungen und die vielen Hinweise zum netten Problemchen… Habe mir eine gute Arbeitswoche die Zähne ausgebissen, bis ich gestern endlich auf diese Seite gestossen bin.
Den Artikel von Spiceworks (Beitrag von Thomas L.) habe ich bereits ganz am Anfang gefunden, der hat bei mir aber so nicht geholfen. Bin dann noch auf diesen Artikel gestossen:
https://www.404techsupport.com/2016/03/21/iis-wsus-private-memory/
Ganz unten verweist der Verfasser ganz am Rand, man soll im ISS Application Pool noch auf Recycle klicken (Was man machen muss verschweigt er). Aber schnell hab ich entdeckt – muss gestehen ISS ist nicht so meine Baustelle – dass dort die "Private Memory usage" auch nochmals aktiviert ist.
Seit ich diese Option deaktiviert habe, haben nun alle Tests 100% geklappt. Wie es scheint, kann ich nun auch die Windows 2016 Server wieder mit Patches bestücken.