pn-schrauber
Goto Top

WSUS - Fehler 0x8024401c am Client

Hallo Gemeinde, ich habe ein Problem mit meinem WSUS

Und zwar bringen die Clients den Fehler 0x8024401c bei der Suche nach Updates

Im Ereignisprotokoll finde ich die Folgende Meldung

Fehlerbucket 127739624120, Typ 5
Ereignisname: WindowsUpdateFailure3
Antwort: Nicht verfügbar
CAB-Datei-ID: 0

Problemsignatur:
P1: 10.0.14393.594
P2: 8024401c
P3: 00000000-0000-0000-0000-000000000000
P4: Scan
P5: 0
P6: 1
P7: 0
P8: UpdateOrchestrator
P9: {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
P10: 0

Angefügte Dateien:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER5A34.tmp.WERInternalMetadata.xml

Diese Dateien befinden sich möglicherweise hier:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\NonCritical_10.0.14393.594_ebaaae9096af33225fd123b0a2f22b0a6f33b91_00000000_1ae860ad

Analysesymbol:
Es wird erneut nach einer Lösung gesucht: 0
Berichts-ID: ac5dc924-080c-11e7-b2fc-b01041c77d9a
Berichtstatus: 0
Bucket mit Hash: 63a0c03ba3e90ff9ec56c06f32855ed0


Mein Netzwerk sieht wie folgt aus:

2 Server, beide DC, einer eben als Backup virtualisiert auf einem Client der immer läuft

Der physiche Server ist mehr oder Weniger ein Datengrab und hat die Dienste mehr zum Testen und üben für mich.

Nennen wir den physichen Server SV-P und den virtuellen SV-V

Auf dem SV-P ist ein MSSQL installiert um Datenbank abfragen zu üben, in diesem leigt auch die WSUS Datenbank.

AUf dem SV-V liegt der WSUS-Dienst, da auf dem SV-P eine Webanwendung läuft, welche sich mit dem WSUS behagt hat, hab ich diesen auf dem SV-P deninstalliert und auf dem SV-V installiert und so Konfiguriert, dass die Daten und auchdie Datenbank vom SV-P weiter genutzt werden, das ganze funktioniert auch, Updates werden sysnchronisiert und können genehmigt oder abgelehnt werden

Suche ich jedoch mit den Clients nach Updates erhalte ich oben genannten Fehler, deaktiviere ich die GPO, laden die Clients die Updates aus dem Internet ganz normal.

Wenn ich die CLients bei aktiver GPO aus dem WSUS löschen, melden SIe sich wieder an, ich erhalte jedoch keinen Stusbericht, und auch keine IP und soweiter, und der Client bringt wieder den bekannten Fehler.

Die Verbindung zur Datenbank läuft, slbst wenn alle Firewall auf allen geräten deaktiviert ist, funzt es nicht (alle Geräte stehen im selben Netz, alsó kein Router zwischen, alles andere Funktioniert auch.

Könnt Ihr mir sagen wo mein Fehler liegt, es hatte ja schon funktioniert, und plötzlich nix mehr, hatte es auf die Webanwendung geschoben, aber auch nach dem Umzug vom WSUS funzt es nicht, GPO ist natürlich angepasst an den neuen Server.

OS, sind WIndows 10 und Windows Server 2016

Google hat mich bisher nicht weitergebracht

Content-Key: 332046

Url: https://administrator.de/contentid/332046

Ausgedruckt am: 19.03.2024 um 05:03 Uhr

Mitglied: BassFishFox
BassFishFox 13.03.2017 um 18:31:36 Uhr
Goto Top
Mitglied: PN-Schrauber
PN-Schrauber 14.03.2017 aktualisiert um 10:33:46 Uhr
Goto Top
Ich hab nun alles gemacht, wie beschriben, also die Anleitung aus dem 1. Link, und das was im 2. Link steht, selbst das Script habe ich ausgeführt, dass lief durch, bis auf das mit der Report-Mail.

DIe Einstellungen im IIS habe ich geändert.

Den Registry Eintrag, gibt es bei mir nicht, aber das berichten ja viele, auch in anderen Beiträgen zu diesem Thema.

Die Server, und auch die Clients sind auf dem Aktuellen Updatestand (Update mit deaktivierter WSUS-GPO)

Ich hab nun mal einen der beiden Server in die GPO geschrieben, also der Server erstellt berichte und macht was er soll, werd ich wohl den nächsten Patchday abwarten, und hoffen, dass Microsoft das ganze fixt, bzw. weiter den Fehler suchen
Mitglied: Gahmuret
Gahmuret 15.03.2017 um 15:34:28 Uhr
Goto Top
Hier hat das jemand durch eine andere Netzwerkkarte gelöst.

https://answers.microsoft.com/en-us/windows/forum/windows_10-update/wind ...

Evtl. hilft bei dir ein Treiberupdate.
Mitglied: User1000
User1000 19.04.2017 um 16:52:36 Uhr
Goto Top
Konnte das Problem gelöst werden? Bei uns taucht es auch auf, mit ähnlichem Ereignis:

Fehlerbucket , Typ 0
Ereignisname: WindowsUpdateFailure3
Antwort: Nicht verfügbar
CAB-Datei-ID: 0

Problemsignatur:
P1: 10.0.14393.594
P2: 8024401c
P3: 00000000-0000-0000-0000-000000000000
P4: Scan
P5: 0
P6: 1
P7: 0
P8: UpdateOrchestrator
P9: {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
P10: 0

Angefügte Dateien:

Diese Dateien befinden sich möglicherweise hier:


Analysesymbol: 
Es wird erneut nach einer Lösung gesucht: 0
Berichts-ID: ea436fb8-250d-11e7-8bc6-901b0ec3f57f
Berichtstatus: 262144
Mitglied: PN-Schrauber
PN-Schrauber 19.04.2017 um 18:19:31 Uhr
Goto Top
Ich habe es immer noch, keinen Erfolg bisher leider.

Ein Client holt sich Updates, und der Rest. meldet sich am WSUS, und dann nichts mehr, keinen Bericht und nix, hab sie schon mehr fach gelöscht, und dann tauchen Sie wider auf, erstellen aber keinen Bericht und ziehen auch keine Updates, der Client jedoch geht, hab auch 2 Server, holen beide nix

wsus

keine Ahnung was es sein soll, habe auch schon mehrfach die GPO deaktiviert, alles raus und wieder rein, aber bis auf den einen Client, alle den selben Fehler.

Kommunikation scheint ja aber zu funzen, sonst würden sie ja nicht wieder in der Liste auftauchen
Mitglied: BassFishFox
BassFishFox 19.04.2017 um 18:59:05 Uhr
Goto Top
Ok,

Auf einem Client, der sich am WSUS meldet, aber dann nix mehr tut.
Generiere mal das WindowsUpdate.log mit dem folgendem Kommando in der powershell.
Get-WindowsUpdateLog

oder cmd
powershell Get-WindowsUpdateLog

Ackere die entstehende Datei mal durch nach Fehlern.

Wie aktuell sind Deine W10 und wie aktuell ist der WSUS? Lass mal Versionsnummern heraus!
Den W10 Pro kannst Du sicherlich auf 1703 anheben.

Ist das hier ungefaehr gleich?
Windows 10 1607 und WSUS - Registryeinträge

Haben Deine Clients das hier schon?
http://www.catalog.update.microsoft.com/Search.aspx?q=KB4015217


BFF
Mitglied: kgborn
kgborn 20.08.2017 um 02:24:44 Uhr
Goto Top
Das Thema ist zwar schon etwas älter - da es mit den August 2017-Updates verstärkt auftrat (Windows 10 (V1607): WSUS-Fehler 0x8024401c mit KB4034658 und KB4034661), bin ich auf den Tread hier gestoßen.

Microsoft hat inzwischen den Technet-Beitrag High CPU/High Memory in WSUS following Update Tuesdays veröffentlicht, der das Thema und die Hintergründe, sowie Workarounds beleuchtet. Vielleicht hilft es weiter.