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"?
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.
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.