Kurzer Nachtrag von der Vorwoche: Mit den kumulativen Sicherheitsupdates vom 14. Juli 2026 haben sich Administratoren, die den WSUS verwenden, ein Problem eingehandelt. Windows Clients könnten sich nicht mehr zuverlässig mit dem WSUS synchronisieren. Microsoft hat inzwischen dieses Problem bestätigt.
WSUS-Sync-Problem hier im Blog
Ich hatte die für Windows Clients verfügbaren kumulativen Sicherheitsupdates im Blog-Beitrag Patchday: Windows 10/11 Updates (14. Juli 2026) aufgelistet. Für Windows Server sind die Updates im Beitrag Patchday: Windows Server-Updates (14. Juli 2026) aufgeführt.
Bereit kurz nach Freigabe der Updates haben sich Blog-Leser in Kommentaren hier im Blog gemeldet und berichten über WSUS-Reporting-Probleme. Arno schrieb hier, dass der WSUS unter Windows Server 2022 mit dem Juli 2026-Update in das Problem gelaufen ist, dass die Windows Clients sich sehr schlecht im WSUS zurückmelden – das dauere ewig. Es gibt weitere Leser, die diese Probleme bestätigen. Ich hatte im Nachgang einen Abriss dieses Sachverhalts im Blog-Beitrag Windows-Clients: WSUS-Reporting-Probleme nach Updates vom 14. Juli 2026 veröffentlicht.
Microsoft bestätigt WSUS-Sync-Probleme
Nun hat Microsoft die Synchronisationsprobleme zwischen WSUS und Windows-Clients und Windows Servern als Folge der Sicherheitsupdates vom 14. Juli 2026 bestätigt.
In einem Beitrag mit dem Titel "Windows Server Update Service sync operations might have issues or time out" (ich bin über diesen Beitrag der patchmanagement.org-Mailing-Liste auf den Hinweis gestoßen), der im Cloud-Admin-Portal veröffentlicht wurde, heißt es, dass Microsoft eine Beeinträchtigung der Dienstleistung beim Windows Server Update Services (WSUS) festgestellt habe.
In Unternehmen kann es auf WSUS-Servern zu verlängerten Synchronisierungszeiten oder Zeitüberschreitungen bei Synchronisierungsvorgängen kommen. Dieses Problem trat in den letzten Tagen auf, wobei ab dem 13. Juli 2026 verstärkte Auswirkungen beobachtet wurden.
Die Annahme, dass ein Update vom Juli 2026-Patchday das Problem verursacht, ist nach meiner Lesart nun hinfällig. Denn Microsoft schreibt, dass das Problem mit einer Anhäufung von Veröffentlichungsmetadaten zusammen hängt.
Microsoft hat daher am 18. Juli 2026 eine Abhilfemaßnahme für dieses Problem bereitgestellt. Die Synchronisierungszeiten und Synchronisierungsvorgänge auf WSUS-Servern wurden wiederhergestellt und sollten bei neuen WSUS-Installationen und -Neuinstallationen wieder normalfunktionieren. Diese Abhilfemaßnahme verhindert, dass neu installierte oder neu aufgesetzte WSUS-Server von diesem Problem betroffen sind. Damit sollte auch das von mir im Blog-Beitrag Windows-Server: WSUS-Installations-/Erst-Sync-Problem angesprochene Problem behoben sein.
Für WSUS-Server, die zuvor betroffen waren, arbeitet Microsoft derzeit an Abhilfemaßnahmen, um Kunden dabei zu unterstützen, die betroffenen Metadaten sicher aus ihren Umgebungen zu entfernen. "Wir werden weitere Informationen bereitstellen, sobald diese Anleitungen verfügbar sind.", heißt es dazu.
Ähnliche Artikel:
Microsoft Security Update Summary (14. Juli 2026)
Patchday: Windows 10/11 Updates (14. Juli 2026)
Patchday: Windows Server-Updates (14. Juli 2026)
Patchday: Microsoft Office Updates (14. Juli 2026)
Exchange Server: Sicherheitsupdates 14. Juli 2026
Dell Windows 11-PCs zeigt mit Update KB5095093 Leistungsprobleme
Windows Papierkorb-Bug mit Juli 2026-Update behoben
Windows-Clients: WSUS-Reporting-Probleme nach Updates vom 14. Juli 2026
MVP: 2013 – 2016
Guten Morgen,
habe mir gerade mal den WSUS angesehen.
Teilweise sind Reports von Clients von heute vorhanden.
Teilweise gar nichts …
Ich denke mal, dass man das hier noch aussitzen muss, bis MS sich meldet.
Habe schon versucht mit neuer WSUSID und dem Reset-Script aber hat weder noch in den meisten Fällen geholfen.
Schönen Start in die Woche
Bei 2 von 2 Kunden hat das geholfen.
https://learn.microsoft.com/de-de/troubleshoot/mem/configmgr/update-management/error-80244007-when-wsus-client-scans-updates
Wie steht denn bei euch diese Option bei den WSUS Servern bei denen dieses Fix geholfen hat bzw. nicht geholfen hat.
Einstellung unter Update File and Langages:
Auf "Store Updates locally on this server" oder auf "Do not store updates files locally, computers install from Microsoft Update"?
Lokal speichern
[X] nur herunterladen, wenn genehmigt
Clients die über das Wochen durchgängig online ware haben sich nur zum Teil (ca 1/3) gemeldet, die meisten aber nicht. Also einfach länger warten ist keine Lösung.
Hab mal spaßeshalber "wsusutil reset" gestest ohne zu erwarten das es was bringt, da es eigentlich nur die Download Files nochmal tested
Hat es natürlich auch nicht, könnt ihr euch sparen.
Ergo abwarten bis MS eine Lösung bringt die defekten Daten aus der WSUS Datenbank wieder zu entfernen oder den WSUS komplett neu aussetzen.
wir hatten nac den Mai Updates solche Probleme. Da haben sich reihenweise Clients nicht mehr gemeldet.
Am Ende hat geholfen die Clients aus dem WSUS zu löschen, danach haben die sich wieder ohne Probleme gemeldet.
..ich zitiere…
Microsoft hat daher am 18. Juli 2026 eine Abhilfemaßnahme für dieses Problem bereitgestellt.
.. Zitat Ende ….
… meine Frage: – was wo wie wann ???
"neu" ist hier das entscheidende Wort
"Diese Abhilfemaßnahme verhindert, dass neu installierte oder neu aufgesetzte WSUS-Server von diesem Problem betroffen sind."
"Für WSUS-Server, die zuvor betroffen waren, arbeitet Microsoft derzeit an Abhilfemaßnahmen"
Tag zusammen
Server-Betriebssysteme sind nicht betroffen, oder wie? Würde bei mir Server 2016 bis 2025 betreffen….
Hier ist der WSUS (auf Server 2025) nicht betroffen.
Alle Server und Clients melden ihren Status nach ca. 5 Minuten nach dem Update.
Nach den Updates auf Windows Server 2016 und 2019 sehe ich bisher keine Probleme mit WSUS. Die bereits aktualisierten Clients melden sich wie erwartet und bekommen aktuelle Statusberichte.
Bei mir hat geholfen den MS Artikel, der den Fehler 0x80244007 behandelt, auf dem WSUS Server anzuwenden.
https://learn.microsoft.com/de-de/troubleshoot/mem/configmgr/update-management/error-80244007-when-wsus-client-scans-updates
Das ergibt auch dahingehend Sinn, weil über die Zeit immer mehr Pakete über den WSUS bereit gestellt werden. In Teilen hilft dann Produkte WSUS seitig abzuwählen sodass weniger Meta Daten ausgewertet werden müssen.
Zumindest hat es sofort nach dem Einspielen bei mir geklappt, auf dem Client die Updates zu beziehen. Vorher rannten manche Clients vergleichsweise häufig in "es wurde ein Problem festgestellt -> Wiederholen" Fehler.
Es macht doch keinen Sinn, den WSUS nach Updates für Produkte, die man gar nicht im Einsatz hat, suchen zu lassen.
Also vor der Erstsynchronisation nur die Produkte, für die der WSUS auch Updates bereitstellen soll, anwählen.
Und im WSUS die Rechner in Gruppen aufteilen.
Z.B. Clients und Server und dann die Updates nur für die passenden Gruppen freigeben.
Server brauchen keine Updates für Windows-Clients angeboten zu bekommen und Windows-Clients keine Updates für Server.
Und Windows 10-Rechner keien Updates für Windows 11 und Windows 11-Rechner keine Updates für Windows 10.
Zumal der Bugfix für 0x80244007 vom Februar ist.
Das ganze sollte nicht wirklich was mit der aktuellen Problematik zu tun haben.
Wir haben 3x WSUS an 3 Standorten im Einsatz.
Bei einem WSUS kein Fehler aufgetreten, bei den anderen beiden hat mir der Link geholfen, da exakt das den Fehler behoben hat.
Danke dafür.
Bei mir hat's auch ein paar Clients erwischt, ungefähr seit Mai, 2x WSUS Windows Server 2019. Trotz Objekte löschen, WSUS ID Reset usw. kommen die Clients nicht dazu zu reporten.
Auf den Clients mal in der Eingabeaufforderung wuauclt /reportnow probiert?
Manchmal hilft es auch, auf einem betroffenen Client noch einmal nach Updates suchen zu lassen und dann o.g. Befehl auf dem Client abzusetzen.
Ihr müsst euch das Log vom "Windows Update-Client"-Dienst auf den Clients mit
"Get-WindowsUpdateLog" anschauen. (konvertiert das .etl-Log in eine Text-Datei auf dem Desktop). Es gibt m. E. zwei Ursachen für die Probleme:
1. Reporting funktioniert nicht wegen Parameter welche die Report-API nach dem Juli-Update nicht mehr verarbeiten kann. Das sieht man im Client-Log gut. Betrifft nur Client einiger Hersteller. Der Leser Fritz hat dieses Problem hier im Blog letzte Woche gut dokumentiert.
2. Reporting funkioniert schlecht, nach mehreren Versuchen von
UsoClient StartInteractiveScan
wuauclt /reportnow
und ev. noch einen Reboot des Client gibt es dann irgendwann mal aktuelle Berichtsdaten. Bei uns waren vor allem Windows 11 Systeme betroffen. Windows 10 Systeme haben schneller Berichte gesendet. Bei diesen Symptomen hilft es möglicherweise das Scan-Intervall in der Gruppenrichtline "Windows-Komponenten/Windows Update/Vom Windows Update angebotene Updates verwalten/Suchhäufigkeit für automatische Updates" auf z.B. 4h zu setzen (Default ohne Gruppenrichtline ist 22h. Läuft ein Client mit der Einstellung 22h in einen Timeout oder ähnliches versucht er es erst am nächsten Tag wieder).
Das ganze ist eine wirklich dumme Geschichte. Microsoft möchte das Updates möglichst schnell installiert werden und dann machen sie ein wichtiges Werkzeug dazu kaputt.
https://borncity.com/blog/2026/07/09/microsoft-zur-windows-update-strategie-in-ki-zeiten/
Also dann sind das entweder mehrere verschiedene Probleme:
a) durch defekte Metadaten seitens MS für den WSUS (wie aktuell durch MS bestätigt)
b) das Update 07-2026 für den Windows Server und damit WSUS
(dort sind 2 Security Updates für den WSUS enthalten)
c) das Update 07-2026 für die Windows Clients (Report-API Problem)
oder eine "Melange" aus allen zusammen ;(
Ja, genau, eine "Wiener Melange" für die Nerven würde jetzt passen. :D
…
Das eine sind die Metadaten, dass andere vermutlich die geschlossenen Sicherheitslücken. Einmal geschüttelt und nicht gerührt. Da wir aber das Innenleben des WSUS nicht kennen kann man dies von Aussen nicht beurteilen.
Also das mit den Metadaten betrifft (wenn ich richtig verstehe) nur neue WSUS-Server und auch nur diesen. Da kommen dann keine Updates an. Dort ist kein Windows Server oder Windows Client, der mit dem WSUS synchronisiert betroffen. Kann ja auch noch kein Update beziehen.
Das mit den Windows Clients, die dann keine Berichte mehr senden, ist ein Phänomen dass immer wieder auftritt. Bei uns ist es jetzt ebenso wieder häufig aufgetreten und konnte mit Umbenennen vom Ordner C:\Windows\SoftwareDistribution in allen Fällen reibungslos behoben werden. Etwas Geduld ist dabei aber notwendig. Zumindest dieses Mal. Man merkt, dass dabei irgendwas länger bei der Verarbeitung benötigt, denn manuelles Auslösen vom Windows Update über den Einstellungen führt zu einer Fehlermeldung (weil im Hintergrund bereits zuvor ein Prozess ausgelöst wurde und scheinbar "länger" braucht und noch aktiv ist).
Zusatzhinweis: Zwei Dienste (BITS, wuauserv) müssen zuvor beendet sein. Zudem kann nachher der umbenannte Ordner ohne Gefahr gelöscht werden.
Nein, es kann gemäss Microsoft alle WSUS-Server betreffen die vor dem 19.7.26 aufgesetzt wurden. Es betrifft aber nicht alle, und nicht alle gleich.
C:\Windows\SoftwareDistribution löschen kann man machen, aber auf tausenden von Client in Grossfirmen auch nicht gerade die ideale Lösung.
Horst hat im Kommentar weiter unten die Lösung von Microsoft für bestehende WSUS-Server verlinkt. Sollte man aus meiner Sicht auf jeden Fall auf betroffenen WSUS-Server anwenden, auch wenn es nicht bei allen geholfen hat. Nur so ist man sicher, dass nicht noch unerwünschte Rest-Metadaten in der Datenbank schlummern. Und Microsoft schreibt auch, dass der nächste Sync nach dem bereinigen der Datenbank auf dem Client einmalig länger gehen kann, weil da dann die Client-Datenbank aufgeräumt wird.
Dachte hier wurde das Problem angegangen, dass hier am Blog genannt wurde und nur bei der ersten Synchonisation auftritt. Hatte uns nicht betroffen, hatte mich aber schon gefreut, dass die auch eine Lösung bekommen.
Hatte somit nur vermutet, es sind zusätzlich ein paar Fehler bzgl. fehlende Reports. Scheinbar komplett verwechselt und alles viel umfangreicher…
…ja generell bei vielen Clients – sofern es denn alle betrifft – ist schon blöd. Wir haben von früher noch ein Skript, dass das automatisch durchführt. Wir hatten aber nur vereinzelt fehlende Reports. Bei den, auf einer Hand abzählbaren, Systemen war hier die schnellere Lösung gegeben. Entsprechend dem neueren Blog scheint das alles noch weit umfangreicher zu sein.
@GB
https://support.microsoft.com/en-us/servicing/os/windows/docs/2026/07/kb5121986-windows-server-update-service-sync-operations-issues-and-timeouts
vielen Dank für die Info – ich hab grad die SQL Abfrage gestartet … lief erfolgreich durch.
Laufzeit fast 19 Minuten
Mal sehen obs dann was gebracht hat
Das hat hier höchstens eine Sekunde gedauert, ich fürchte das hat bei uns nichts gebracht.
Bei mit bringt das (bis dato) nix.
Nicht ein Client hat danach bis jetzt reportet, entweder dauert das wirklich sehr lange,
oder da in dem Artikel vom einem Problem seiten MS mit den Metadaten vom 13.7 gesprochen wird und hier andere schon davon gesprochen haben das nach der Deinstallation des Windows Patches vom 07-2026 (vom 14.07) auf dem WSUS Server das Problem mit den Clienets wieder weg ist, sind es doch zwei verschiedene Probleme.
Die Abfrage hat hier zwar länger gedauert, bewirkt hat sie aber garnichts.
Die Clients die vorher nicht reporten tun das auch weiterhin nicht…
kann ich bestätigen … Scripts ausgeführt aber Reports weiterhin ausständig. Schade :(
WSUS Server wurde auch mal durchgestartet zur Sicherheit
Äh, entweder ich verwechsle da was oder es tun viele Andere :-)
Das aus dem Link bewirkt nur eine Lösung, wenn man ein Problem mit der Synchronisation zwischen WSUS und den MS Servern hat – genauer bei der ersten Einrichtung.
Soweit kurz überflogen würde ich dies zudem auf keinen WSUS ausführen, der bereits erfolgreich den ersten Sync gemacht hatte.
WSUS-Clienst oder auch Windows Server und Windows Clients, die mit dem WSUS synchronisieren und Fehler bei den Reports haben bzw. keine mehr kommen: am WSUS-Client die Dienste (BITS, wuauserv) beenden, C:\Windows\SoftwareDistribution mit ".bak" ergänzen und beide Dienste wieder starten. Windows Update Suche starten und warten. Dauert… Reports sollten wieder kommen. Der umbenannten Ordner kann später gefahrlos gelöscht werden.
Die hilft bei Client Problemen die ab und zu vereinzelt auftreten.
Das Problem hier ist aber ein Anderes.
Dachte hier wurde das Problem angegangen, dass hier am Blog genannt wurde und nur bei der ersten Synchonisation auftritt. Hatte uns nicht betroffen, hatte mich aber schon gefreut, dass die auch eine Lösung bekommen.
Hatte somit nur vermutet, es sind zusätzlich ein paar Fehler bzgl. fehlende Reports. Scheinbar komplett verwechselt und alles viel umfangreicher…
Query lief bei mir auch ein paar (5-10) Minuten.
Bei uns hilft es zum Teil:
Betroffen sind (bei uns) nur noch 32 Bit Maschinen (W10-IoT-LTSB-2016 und W10-IoT-LTSC-2019). Die 64er (W10-IoT-LTSC-2019) laufen alle wieder.
Abfrage lief 20 Minuten oder so, geholfen hat es bei den Clients, die sich nicht richtig melden, nicht.
Tolle Wurst
Hallo an Günter Born,
vielen Dank für deinen Blog und den Artikel zum Thema „Microsoft bestätigt WSUS-Sync-Probleme nach Juli 2026-Updates"
Ich bin auch sehr vorsichtig, wenn es darum geht, einfach mal Skripte auszuprobieren – gerade beim WSUS.
KB ID: 5121986
https://support.microsoft.com/en-us/servicing/os/windows/docs/2026/07/kb5121986-windows-server-update-service-sync-operations-issues-and-timeouts
Unsere Win11 Clients hatten diese beiden Fehlermeldungen -> 0x80244010 und 0x80244007
Bei mir hat folgende Lösung funktioniert:
https://www.systemcenterdudes.com/sccm-error-code-0x80244007-windows-servers-2019-2022-2025-not-scanning-updates-from/
Auf dem WSUS-Server gibt es unter C:\Program Files\Update Services\WebServices\ClientWebService – die Datei „web.config".
Hier habe ich lediglich zwei Werte angepasst (ohne vorher Skripte auszuführen etc.)
"maxInstalledPrerequisites" value="800" Wert von 400 auf 800
"maxCachedUpdates" value="44000" Wert von 22000 auf 44000
WSUS-Server neu gestartet und abwarten.
Über Nacht haben sich dann die Clients wieder verbunden und die Reporte bzw. ausstehende Updates gezogen.
Vielleicht hilft das ein wenig zum Thema „WSUS-Störung".
Viele Grüße
Stefan Harbers
Damit bekämpft man aber eben nur die Symptome und nicht die Ursache. Es ist schon sinnvoll, wenn man die ganzen Testdinger wieder aus der Datenbank entfernt, die Microsoft da fälschlicherweise reingebaut hat.
— snip
Es ist schon sinnvoll, wenn man die ganzen Testdinger wieder aus der Datenbank entfernt…
— snap
Benenne die *Testdinger*. Was für *Dinger* meinst Du?
Na die hier halt:
https//support.microsoft.com/en-us/servicing/os/windows/docs/2026/07/kb5121986-windows-server-update-service-sync-operations-issues-and-timeouts
Was ich so an Informationen zusammen getragen habe:
Fehlerbild: Betroffene Clients können weiterhin scannen, Updates herunterladen/installieren und der Last Contact wird aktualisiert. Der Last Status Report bleibt jedoch auf „Not Yet Reported" bzw. auf einem alten Datum stehen. Betroffen scheinen insbesondere Geräte/BIOS-Konstellationen zu sein, die beim Reporting leere Hardware-/Telemetrie-Felder übertragen – berichtet wurden u. a. Fujitsu CELSIUS/ESPRIMO, Intel NUC und einzelne ASUS-Geräte.
Im SoftwareDistribution.log des WSUS findet man typischerweise:
ValidateMiscData: Rejecting MiscData entry with empty or whitespace-only value: t=
bzw. WebService.ValidateEventBatch … failed to validate.
Wichtig: Die von Microsoft veröffentlichte KB5121986 behebt die parallel aufgetretenen WSUS-Sync-/Scan-Time-outs durch fehlerhafte Detectoids. Sie ist sinnvoll, wenn Fehler wie 0x80244010, 0x80244007, 503 oder extrem lange Scans auftreten. Sie behebt aber nach den vorliegenden Berichten nicht den herstellerspezifischen Statusreport-Fehler mit ValidateMiscData.
Praktikable Lösung
Server-Log prüfen
Auf dem WSUS in:
C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log
Nach ValidateMiscData, empty or whitespace-only, ValidateEventBatch sowie den betroffenen Modellnamen suchen. Damit ist die Ursache sehr eindeutig abgegrenzt.
Bei mir sind das alle Fujitsu ESPRIMO P557 PC mit Windiows 11 25H2
die im Log mit dem Fehler auftauchen:
ComputerBrand=[FUJITSU] ComputerModel=[ESPRIMO P557] BiosRevision=[V5.0.0.12 R1.31.0 for D3500-A1x ] ProcessorArchitecture=[Amd64Compatible] OSVersion=[10.0.26200.65792.0.0.0.0.0]
Kurzfristiger Workaround: Juli-CU vom WSUS-Server deinstallieren
Für Server 2022 betrifft das in den bekannten Fällen KB5099540. Mehrere Administratoren berichten, dass unmittelbar nach der Deinstallation die zuvor betroffenen Geräte wieder Statusreports liefern. Das ist derzeit der verlässlichste Workaround für genau dieses Fehlerbild.
Beispiel PowerShell als Administrator:
wusa /uninstall /kb:5099540
Anschließend den Server neu starten und an einem betroffenen Client einen Scan/
Report auslösen:
cmd
UsoClient StartInteractiveScan
wuauclt /reportnow
Sicherheitsabwägung beachten
Das Rollback entfernt natürlich auch die Sicherheitskorrekturen des Juli-Updates. Daher: nur als temporäre Maßnahme, Risiko dokumentieren, Zugriff auf WSUS/IIS möglichst auf interne Netze begrenzen und auf ein korrigiertes Microsoft-Update prüfen. Der Fehler liegt im Reporting-Webservice auf dem WSUS, nicht an einer defekten WSUS-GPO oder einer falschen Client-ID.
Nicht zielführend für diesen speziellen Fehler:
SUSClientID zurücksetzen, Clientobjekte löschen/neu anlegen, IIS-/Zertifikatsprüfung oder Anpassungen wie maxCachedUpdates lösen das Problem mit leerem MiscData in der Regel nicht. Das kann bei allgemeinen Scan- bzw. Metadatenproblemen helfen, aber nicht wenn der WSUS die Statusmeldung wegen einer verschärften Datenvalidierung verwirft.
Empfehlung: Erst den Log-Eintrag verifizieren. Wenn MiscData … t= bzw. ValidateEventBatch erscheint, KB5099540 auf einem WSUS-Testsystem entfernen. Funktioniert das Reporting danach wieder, liegt der Sachverhalt eindeutig vor. Bis Microsoft ein korrigiertes CU liefert, ist das der realistische Workaround.
Ich warte erst einmal ab, ob Microsoft eine Lösung des Problems anbieten wird.
Wenn jemand einen Tipp hat, wie ich bei den Fujitsu ESPRIMO PC dafür sorgen kann, dass diese im WSUS nicht mehr als Störenfriede aussortiert werden, wäre ich dankbar.
Sehr gut zusammen gefasst. Dies sind genau die Infos welche ich so auch bestätigen kann. Wir haben auch Fujitsu Geräte welche sich entsprechend verhalten. Eine Lösung habe ich bisher nicht gefunden. Den Juli CU möchte ich nicht entfernen. Ich hoffe bald auf einen Update seitens MS.