Hier noch ein Blog-Beitrag zu einem Problem, welches von einem Leser aufgeworfen wurde. Nach einem Umzug eines WSUS auf Windows Server 2016 werfen die Windows 10-Clients und auch der Windows Server 2016 den Fehlercode 0x80244007.
Anzeige
Blog-Leser Steffen beschreibt in einer Mail sein Ausgangsszenario sowie die auftretenden Probleme folgendermaßen:
Ausgangssituation: Bis vor einiger Zeit hatten wir nur einen WSUS auf Basis 2008R2. Der versorgt(e) alles bis einschl. Windows 8.1 und Server 2012R2 mit Updates. Irgendwann kamen die ersten Windows 10-Geräte. Dafür habe ich notgedrungen auf unserem 2012R2-DC einen WSUS aufgesetzt. Soll man nicht machen, aber in Ermangelung einer passenden Kiste… Dann kamen die ersten Server 2016 dazu. Auch diese Konstellation funktionierte. Zuordnung der Geräte zu den passenden WSUS erfolgte über GPO.
Da nun aber reichlich Speicher und auch eine neue Kiste extra dafür da ist, habe ich einen Server 2016 aufgesetzt und alles für den WSUS ans Laufen gebracht. Soweit so gut. Da ich aber gerne vorhandene Genehmigungen und Gruppen mitnehmen wollte habe ich den neuen WSUS als Replikat-Downstreamserver eingerichtet. Zuerst vom WSUS 2012R2 für Win 10 und Server 2016, danach vom WSUS 2008R2 für alle anderen Kisten.
Istsituation: Der neue WSUS zieht Dateien für genehmigte Updates aus dem Internet.
Die umgezogenen Kisten von WSUS 2008R2 verbinden sich mit dem neuen WSUS, es gibt aktuell keine Fehlermeldungen, allenfalls 0x80244010, weil es zu viele Updates sind, die erneut ausgewertet werden müssen.
Die umgezogenen Geräte vom WSUS 2012R2 meckern primär mit 0x80244007 rum. Teilweise auch mit 0x80244010, enden dann aber meist in 0x80244007. Die Geräte kontakten zwar, aber reporten nicht.
Neue Windows 10er-Clients arbeiten korrekt. Sie kontakten, reporten und finden auch Updates. Nach Genehmigung dieser Löschen/Umbenennen von SoftwareDistribution hat nichts gebracht. Entfernen und wieder zur WSUS-Gruppe hinzufügen auch nicht.
Schöner Mist. Gut es sind nur ein paar (un)wichtige Kisten – Test-Clients (10er) und AV, Backup, WSUS (jeweils 2016er).
Da ich keinen WSUS betreibe, lasse ich das einfach mal so im Raum stehen. Vielleicht hat einer der Blog-Leser eine Idee oder einen Tipp.
Error 0x80244007
Der Fehlercode 0x80244007 steht unter Windows schlicht für einen Protokollfehler (siehe meinen Blog-Beitrag Windows 10: Update-Fehler 0x8024xxxx erklärt):
WU_E_PT_SOAPCLIENT_SOAPFAULT
Same as SOAPCLIENT_SOAPFAULT – SOAP client failed because there was a SOAP fault for reasons of WU_E_PT_SOAP_* error codes.
Die Kommunikation zwischen Client und WSUS ist wegen eines Protokollfehlers gescheitert.
Anzeige
Diverse Hinweise im Internet
Der Fehler kommt immer mal wieder vor, der Technet-Forenbeitrag [Win 10; WSUS] Windows Update Client failed to detect with error 0x80244007 aus 2015 adressiert ebenfalls diesen Fehler. Winfried Sonntag hat in diesem Thread auf den SuperUser-Forenbeitrag Windows update failing with error 80244007 "could not search for new updates" verwiesen. Dort gibt es folgenden Hinweis:
Since you're connected to a domain, I assume it's an invalid Target Group name. So what you have to do is to open the registry, and then go to:
HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate
And then look for Target Group key, export it first (just a backup) then delete it.
Now, restart your computer and check Windows Updates.
Ob das bei WSUS hilfreich ist, kann ich nicht beurteilen. Im deutschsprachige Technet-Thread werden noch einige weitere Hinweise diskutiert. Dieser englischsprachige Technet-Thread vom März 2018 (sowie dieser Thread) erwähnt diesen Eingriff ebenfalls.
Zudem hat Microsoft zu Windows 8 und dem Update-Fehler 0x80244007 beim WSUS diesen KB-Artikel veröffentlicht. Dort wird ein Update-Rollup erwähnt, was aber unter Windows 10 wohl nicht mehr relevant ist.
Ähnliche Artikel:
Windows 10: Update-Fehler 0x8024xxxx erklärt
Windows 8.1/10: Fehler 0x80244007
Anzeige
Ich würde noch versuchen einem betroffenen client eine neue SUSClientID zu spendieren:
https://gallery.technet.microsoft.com/scriptcenter/Reset-WSUS-Authorization-2e26d1b0
Das löschen vom SoftwareDistribution Ordner ist auch nur die halbe Wahrheit:
https://gallery.technet.microsoft.com/scriptcenter/Reset-WindowsUpdateps1-e0c5eb78
Vorsicht: Punkt 10 im WU-Reset Script würde ich allerdings durch das löschen der SUSClientID ersetzen und Punkt 4 ist unter W10 auch nicht sinnvoll.
Vielleicht hilft das.
Da fällt mir folgendes Problem ein, über welches ich beim Test von Windows 10 1703 mit unserem WSUS 2016 gestolpert bin: https://social.technet.microsoft.com/Forums/de-DE/03149e80-65d4-4c47-938c-11ca8f46b4db/issue-with-windows-10-cant-download-updates-from-wsus-with-kb3213986-installed?forum=winserverwsus
Hallo Leute,
hier ein kurzer Zwischenstand:
SUSID resetten, SoftwareDistribution löschen, TargetGroup checken – Alles ohne Erfolg. Es bleibt beim 0x80244007.
Ich baue jetzt mal noch einen WSUS und amche den ganzen Kram nochmal von Hand. Nix Replikate von keinem alten WSUS. Dann wird erstmal der WSUS auf sich gelenkt.
Meinen win 10 Testrechner lasse ich derweil nochmal an den alten WSUS (2012R2) reporten, mal sehen, ob die sich ncoh verstehen.
An den neueren WSUS kommen dann erst die TEstrechner (Win 10 und 7) und dann die anderen Kisten. Sofern es funktioniert.
—
VG, Steffen
Neben SoftwareDistribution kann auch das Löschen (bzw. Umbenennen) des CatRoot2 im System32 helfen. Wenn die TargetGroup nicht stimmt (je nachdem, ob die Gruppe überhaupt per Gruppenrichtlinie zugeordnet wird), tauchen die Computer in den nicht-zugeordneten Computern auf.
Ist SSL im Einsatz? Falls ja, gibt der Server (im IE/Edge) für den konfigurierten Hostnamen das gewünschte Zertifikat zurück?
Wie schauts mit einem neuinstallierten Client aus? Funktionierts dann wie es soll?
Hallo zusammen,
ich glaube, ich kann das Thema abhaken. Alle Clients reporten nach Rückstellung auf ihre ursprünglichen WSUSe. Klappt. Ein neuer WSUS baut sich derweil auf, wie oben geschrieben und kann mit sich selbst hantieren.
Meine Vermutung ist, dass es sicher problemlos möglich ist, einen Up- und mehrere Downstreamer zu betreiben, aber nicht einen neuen WSUS über mehrere Upstreamer zu befüllen. Zumindest nicht, ohne Biegen und Brechen.
Ich werde mal weiter machen (lassen) und euch auf dem laufenden halten.
—
VG, Steffen
Hallo zusammen,
der Form halber hier noch mein "Abschlussbericht". Läuft.
WSUS auf Server 2016 v1607 habe ich für die Aufnahme aller Clients und Server vorbereitet, in dem ich all benötigten Gruppen und Sichten angelegt habe. Dazu habe ich dann auch die Produkte und Klassifizierungen gesetzt und die Genehmigungen definiert.
Nachdem der Server alle Dateien von Microsoft gezogen hat, habe ich gruppenweise meine Geräte auf den WSUS umgestellt. Erst die Win10-Lab-Clients, dann die 2016er-Server und dann alle anderen Geräte.
Nun kann ich die WSUSe auf meinen beiden "Alten" abschalten und wieder Plattenplatz schaffen.
—
VG, Steffen