Der klassische Fehlerfall
Nach einer geplanten Umstellung auf SSL oder der Verschiebung des WSUS-Targets bekommen die Clients plötzlich den Fehler 0x80072EE2 angezeigt. Der Windows Update-Dienst läuft, aber eine Verbindung zum Server kommt nicht zustande. In vielen Fällen fehlt an der betroffenen Maschine einfach das Registry-Artefakt, das die Gruppenrichtlinie geschrieben haben sollte. Ein ähnliches Bild zeigt sich bei Fehlercode 0x8024401c: Der Client kann keine Updates vom Server abrufen.
Die folgende Anleitung hilft Ihnen, das Problem reproduzierbar einzugrenzen – ohne stundenlanges Raten. Die Schritte sind für WSUS 6.x ab Windows Server 2012 bis hin zu Current Branch von Configuration Manager getestet worden.
Diagnose – Schritt für Schritt
1. Gruppenrichtlinien-Persistenz prüfen
Öffnen Sie auf dem betroffenen Client eine elevate Befehlszeile und rufen Sie den Richtlinienspiegel auf:
GPRESULT /V > C:Tempgpresult.txt
Notepad C:Tempgpresult.txt
Suchen Sie nach dem Namen Ihrer WSUS-Richtlinie im Abschnitt „Angewendete Gruppenrichtlinienobjekte“. Ist sie dort nicht gelistet, wurde die GPO entweder nicht auf den Computer vererbt oder der Client hat die Zuordnung noch nicht gezogen – hier hilft ein gpupdate /force.
Ist die GPO vorhanden, prüfen Sie die Registry unter:
reg query "HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdate" /s
Dort müssen die Werte WUServer, WUStatusServer und im Unterkey AU der Flag UseWUServer = 1 stehen. Fehlen diese Schlüssel, ist die Richtlinienverteilung defekt oder wurde zwischenzeitlich entfernt, ohne dass der Agent sich neu registriert hat.
2. Netzwerkkonnektivität zum WSUS testen
Ein TCP-Connect auf den WSUS-Port klärt schnell, ob die Firewall dazwischen funkt. Abhängig von der Konfiguration ist Port 80, 443, 8530 oder 8531 betroffen:
Test-NetConnection -ComputerName wsus.contoso.local -Port 8531
# alternativ klassisch:
telnet wsus.contoso.local 8531
Eine Time-out-Meldung deutet typischerweise auf einen Filter zwischen Client und Server hin. Prüfen Sie danach auf der Netzwerkseite die Route und eventuelle SSL-Inspection-Regeln, die unbedingte Zertifikatsanker voraussetzen.
3. Dienste und BITS kontrollieren
Der Background Intelligent Transfer Service wird für Downloads benötigt. Er muss mit LocalSystem gestartet sein:
Get-Service bits, wuauserv | Select Name, Status, StartType
# Falls nicht korrekt:
sc config bits obj= LocalSystem
Restart-Service bits, wuauserv
Hier empfiehlt es sich zudem, einen sauberen Reset des Client-Caches vorzunehmen:
Stop-Service bits, wuauserv
Rename-Item C:WindowsSoftwareDistribution SoftwareDistribution.old
Start-Service bits, wuauserv
Der Aufruf wuauclt /resetauthorization /detectnow /reportnow löst danach eine sofortige Neuanmeldung am Server aus.
4. Weitere Fehlercodes im Blick behalten
Neben 0x80072EE2 tauchen in der Praxis häufig weitere Netzwerk-Fehlercodes auf, die ähnliche Ursachen haben:
0x80072EFD– kann keine Verbindung aufbauen0x80072EE7– Hostname kann nicht aufgelöst werden0x80072EFE– Verbindung wurde vorzeitig abgebrochen0x8024401c– kein Zugriff auf die Verteilungsrolle0x8024402C– DNS-Namen konnte nicht aufgelöst werden
Diese Liste reduziert die Fehlersuche auf eine handvoll konkreter Anlaufstellen und spart Zeit beim Kundenkontakt.
Typische Lösungen
Registry-Werte nachtragen
Sind die Policies verschwunden oder auf 0 gesetzt, können Sie die Schlüssel manuell wiederherstellen:
reg add "HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdate" /v WUServer /d "http://wsus.contoso.local:8530" /f
reg add "HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdate" /v WUStatusServer /d "http://wsus.contoso.local:8530" /f
reg add "HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU" /v UseWUServer /d 1 /f
Danach erneut gpupdate /force ausführen und den Dienste-Reset durchführen.
MSXML und Signatur-Bibliotheken reparieren
In selteneren Fällen fehlt dem Client die Fähigkeit, HTTPS-Verbindungen ordentlich aufzubauen. Folgende DLLs sollten dann erneut registriert werden:
regsvr32 MSXML3.dll /s
regsvr32 softpub.dll /s
regsvr32 mssip32.dll /s
Restart-Service wuauserv, bits
Dies hebt häufig Probleme nach größeren Windows-Updates oder bei versehentlicher Löschung der Systembibliotheken auf.
Zertifikatsprobleme bei SSL-Umstellung
Bei einem Wechsel von HTTP auf HTTPS prüfen Sie unbedingt den Zertifikatshaken am Client. Das WSUS-Zertifikat muss im Vertrauenswürdigen Stammregister liegen. Ein fehlendes Root oder abgelaufenes Intermediate bricht die Verbindung mit genau den oben genannten Timeout-Fehlern ab. Exportieren Sie das WSUS-CA-Zertifikat vom Server und importieren Sie es lokal in den Store des vertrauenswürdigen Stammzertifizierungsstellen-Containers.
Fazit
Der Großteil der als mysteriös empfundenen WSUS-Fehler lässt sich auf drei Punkte reduzieren: fehlende Registry-Werte, blockierte TCP-Ports oder ungültige Zertifikate. Die Kombination aus GPResult-Audit, Test-NetConnection und sauberem Dienst-Resete hebt meistens schon innerhalb weniger Minuten die Blockade. Wer diesen Pfad systematisch abarbeitet, spart Zeit und vermeidet Fehlschlüsse, die sonst gern auf kaputte Client-Images oder schadhafte Updates geschoben werden.
Quellen
- Behandeln von Problemen mit WSUS-Client-Agenten – Microsoft Learn (abgerufen November 2026)
- WSUS und Windows Update Troubleshooting – Mathias Jäkel (9. Februar 2021)
- Häufige Windows Update-Fehler – Microsoft Learn (Stand November 2026)
Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.
No responses yet