Die zum 14. Juli 2026, am Patchday für Windows 10 / 11 freigegebenen kumulativen Updates sollen Bugs und Sicherheitslücken auf noch unterstützten Client-Betriebssystem-Versionen beheben. Installierte Updates führen aber dazu, dass das Reporting beim Windows Server Update Services (WSUS) nicht mehr funktioniert. Hängt mit CVE-2025-59287 zusammen, weshalb eine Funktion im WSUS temporär deaktiviert wurde.
July 2026-Patchday für Windows
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.
Leserberichte über WSUS-Reporting-Probleme
Bereit kurz nach Freigabe der Updates haben sich Blog-Leser in Kommentaren hier im Blog gemeldet und berichten über WSUS-Reporting-Probleme.
Ein erster Thread
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.
Dort im Thread gibt es noch den Hinweis auf den Fehler 80244007, wenn der WSUS nach Updates sucht. Dazu gibt es den Support-Beitrag Error 80244007 when a WSUS client scans for updates, der meinem Gefühl nach nichts mit obigem Problem zu hat. Auch das von mir Anfang Juli 2026 angesprochene Problem (siehe Windows-Server: WSUS-Installations-/Erst-Sync-Problem) ist anders gelagert.
Der Support-Beitrag Client computers do not report back to the Windows Software Update Services (WSUS) server trifft es mit der Warnung 80244008 schon eher (dürfte aber nicht initial die Ursache sein, siehe Erklärung am Beitragsende).
Angeblich nur bestimmte Clients
In diesem Kommentarthread heißt es, dass die Probleme nur von bestimmten Clients bestimmter Hersteller abhängen.
Nach dem gestrigen Patchday können Fujitsu Clients (CELSIUS W580, CELSIUS W570, ESPRIMO D958) keine Reports mehr an den WSUS Server schicken. Sie konnten noch die Patches runterladen und installieren, der anschliessende Report wird an den WSUS Server übermittelt aber er wird nicht in die DB übernommen.
Im Logfile des Servers ("C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log") werden dazu Warnungen angezeigt: "WebService.ValidateEventBatch Event in batch failed to validate. Exception: MiscData entry has empty or whitespace-only value: t="
Der Leser gibt an, dass es nur Fujitsu Geräte betrifft. Dell, Lenovo, Asus usw. haben alle kein Problem. Die KI meint dass eine Fujitsu-spezifische SMBIOS-/BIOS-Eigenschaft fehlt oder ist leer ist.
In diesem Kommentarthread hier im Blog werden noch diverse Maßnahmen und mögliche Fixes diskutiert. Wenn ich aber nachfolgende Ausführungen von Microsoft lese, dürften diese Maßnahmen nichts bringen, da eine Funktion temporär suspendiert wurde.
Bestätigung in den Known Issues
Microsoft hat in den Known Issues für das Update KB5099540 für Windows Server 2022 folgende Information eingetragen:
After installing KB5070884 or later updates, Windows Server Update Services (WSUS) does not display synchronization error details within its error reporting. This functionality is temporarily removed to address the Remote Code Execution Vulnerability, CVE-2025-59287.
Microsoft hat also eine bestimmte Funktionalität auf Grund der Remote Code Execution-Schwachstelle CVE-2025-59287 temporär entfernt. Den gleichen Eintrag gibt es für Windows Server 2025 und das kumulative Update KB5099536.
Hintergrundinformation zu CVE-2025-59287
Die kritische Schwachstelle CVE-2025-59287 (CVSS 3.1 Score 9.8) im WSUS wurde im Oktober 2025 offen gelegt. Eine Deserialisierung nicht vertrauenswürdiger Daten im Windows Server Update Service ermöglicht es einem unbefugten Angreifer, Code über ein Netzwerk auszuführen. Es gab ein Out-of-Band-Update, was aber möglicherweise nicht ausreichend war – so dass Microsoft nun reagiert hat.
Ergänzung: Microsoft hat das Problem bestätigt und am 18. Juli 2026 einen Fix ausgerollt (siehe Microsoft bestätigt WSUS-Sync-Probleme nach Juli 2026-Updates).
Ä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
MVP: 2013 – 2016
@GB
"After installing KB5070884 or later updates, Windows Server Update Services (WSUS) does not display synchronization error details within its error reporting. This functionality is temporarily removed to address the Remote Code Execution Vulnerability, CVE-2025-59287."
Das ist uralt uns steht schon sein Monaten als known Issue drin. Das ist nicht das aktuelle Problem
Ah, ok, hab mir den KB nicht angeschaut. Also weiter rätseln?
Leider ja
dar das Security Fix für den WSUS in den 07-2026 Updates gegen DDOS ist, schätze ich mal das es einfach an der Menge der Reports liegt.
Wenn sich zu viele Clients in einer gewissen Zeit melden werden die vermutlich geblockt und können kein Report senden. Wenn es mal zufällig weniger sind kommt was durch, dadurch vermutlich dieses inkonsitente Verhalten.
Denn wie haben noch einen anderen WSUS mit sehr wenigen Clients, der zeigt dieses Problem nicht obwohl auch mit 07-2026 gepatched.
sorry, Korrektur, kein DDOS aber andere Security Fixes für den WSUS in den 07-2026 Updates
Windows Server Update Service (WSUS) Elevation of Privilege Vulnerability
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50444
Windows Server Update Service (WSUS) Tampering Vulnerability
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50328
Wie andernorts schon geschrieben: Deinstalliert man die 2026-07 Security fixes (also Stand 2026-06), dann reporten die fraglichen Intel- und Fujitsu-Systeme.
Die DLL C:\Program Files\Update Services\WebServices\ReportingWebService\bin\Microsoft.UpdateServices.Reporting.dll hat vor dem Patch Stand 14.04.2026, danach 14.07.2026 und eine andere Versionsnummer (10.0.20348.5386).
Das ist auch so in der Dateiliste des Updates (über die KB als CSV abrufbar, https://go.microsoft.com/fwlink/?LinkId=2371326) dokumentiert. Ebenso die anderen beim WSUS geänderten Dateien.
Die neue Version schreibt Errors in der Art
"ReportingEvent.ValidateMiscData Exception occurred while parsing MiscData for event InstanceId: e457a4b7-93bd-4d43-b2ea-697ada57d003. Exception: System.InvalidOperationException: MiscData entry has empty or whitespace-only value: t="
und in den Stack Trace Details wie
"Failed Event:EventInstanceId=[38ea4828-c78a-40c1-9a44-af194a865bf6] EventId=[147] TargetId=[Id=[2b5cdb4f-f052-42c5-9038-444be2c7f40d] ] TimeAtTarget=[2026-07-17 05:56:42.248 UTC] SequenceNumber=[0] SourceId=[101] NamespaceId=[1] Win32HResult=[0] AppName=[Windows Defender] TargetGroup=[00000000-0000-0000-0000-000000000000] ComputerBrand=[Intel Corporation] ComputerModel=[NUC7i5DNHE] BiosRevision=[DNKBLi5v.86A.0052.2018.0808.1335] ProcessorArchitecture=[Amd64Compatible] OSVersion=[10.0.26100.65792.0.0.0.0.0] OSLocaleId=[1031] ClientVersion=[0.0.0.0.0.0.0.0.0] BundleId=[UpdateId=[00000000-0000-0000-0000-000000000000] RevisionNumber=[0] ] LastErrorCode=[0] ByteCount=[0] RepeatFailCount=[0] NumberApplicable=[0] ClientsUsed=[0] ClientSamplingValue=[0] BiosName=[] BiosReleaseDate=[01.01.1900] ServiceGroupId=[0] ServerErrorType=[] ServerErrorMessage=[] EventType=[0] BundleByteCount=[0] BundleRepeatFailCount=[0] MsiAction=[] MsiPatchCode=[00000000-0000-0000-0000-000000000000] MsiProductCode=[00000000-0000-0000-0000-000000000000] ServerFileHash=[] MiscInt1=[0] MiscInt2=[0] MiscVarChar1=[] MiscVarChar2=[] ReplacementStrings=[0] miscData=[B=11,C=4,G=1507.2605.13032.0,J=158,K=DNKBLi5v.86A.0052.2018.0808.1335,L=2018-08-08T00:00:00,N=Intel NUC,O=38,P=1,Q=1,T=Intel Corp.,AppName=Windows Defender,CsiErrorType=0,c=48,k=false,l=38,m=0,n=1,o=0,p=0,q=1,r=1,t= ,w=0,x=1,dd=0,ff=1,gg=1,WUfBOn=1,WUfBDS=1,DisableDS=1,PauseQU=1,PauseFU=1]"
(wobei hinter dem t= wirklich 32 Leerzeichen stehen) in die WSUS-Protokolldatei "C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log".
Die Logs vor dem Update zeigen solche Einträge nicht.
Es gibt auch noch "Parametername: e —> System.FormatException: GUID muss 32 Ziffern mit 4 Bindestrichen enthalten (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).".
Soweit ich sehen kann wurde dem ursprünglichen CVE ein PoC (https://hawktrace.com/blog/cve-2025-59287/) beigefügt, der nur den ClientWebService (also den primären EInsprungpunkt für die Abfrage nach Updates) angreift und der initiale Patch KB5070884 behandelt auch nur diesen. Inzwischen hat man das Update wohl überarbeitet und die Report-Komponenten mit aufgenommen, da sie ebenfalls angreifbar sind.
Letztendlich ist das aber nur ein kosmetisches Problem, die Clients erhalten Updates und spielen sie ein, man hat halt nur keine Rückmeldung über die WSUS-Konsole.
bei mir sind verschiedene Hersteller betroffen und quasi alle System, denke nicht das es wirklich daran liegt.
bzgl "kosmestisch" ist halt doof wenn das Update auf dem Client warum auch immer fehlschlägt und man dadurch kein Feedback bekommt.
Ich habe nun testweise einen neuen WSUS Server installiert und 3 Clients konfiguriert welche dort hin reporten. 2 davon sind solche welche beim produktiven WSUS Server nicht mehr funktionieren (Fujitsu). Sobald der CU vom Juli auf dem Test WSUS Server installiert wird, reporten diese 2 nicht mehr. Zeigen also das selbe Verhalten wie beim produktiven Server. Der 3. Client (Hyper-V VM) reportet nach wie vor problemlos. Bei uns hat es also nichts mit der Menge an Clients zu tun sondern das Problem besteht bei bestimmten HW Typen. Zwischenzeitlich ist uns noch ein Asus Zenbook UX333FN aufgefallen mit dem selben Problem.
Das Fehlerbild ist genau dasselbe wie bei User "Fritz".
Wann genau hast du den WSUS neu aufgesetzt? Heute? Oder schon früher?
Und sync der direkt mit MS oder ist es ein Downsteam Server eines bestehenden WSUS?
siehe
https://borncity.com/blog/2026/07/20/microsoft-bestaetigt-wsus-reporting-probleme-nach-juli-2026-updates/
Letzten Do/Fr einen neuen Test WSUS aufgesetzt, der synct direkt mit MS.
Der Sync mit MS funktioniert jedoch, das Problem sind die Clients (je nach HW Vendor) welche an den WSUS reporten, das funktioniert nicht mehr.
Stimmt VM CLient sind bei uns auch nicht betroffen, hängt also vermutlich zusammen was Fritz geschrieben hat.
Das kann ich bestätigen, ich hab hier ein Asus Zenbook433 das auch nicht mehr reportet….
Was passiert wenn ihr auf der Firewall (vom WSUS) einen Teil der IP-Range der Client eingehend auf Port 8530/8531 sperrt? Dann reduziert sich die Last und ein Teil der Client müsste abgearbeitet werden können, wenn an der DDOS-These was dran ist. Ich denke dieser Versuch sollte keine Nebenwirkungen verursachen.
Kämpfe schon länger mit WSUS weil neue Clients irgendeinen 0x80244010…… auswerfen. Das dürfte schon länger im Hintergrund schwelen. Liegt am Server
Neue Client oder solche wo der Dienst wuauserv zurückgesetzt wurde (C:\Windows\SoftwareDistribution gelöscht), brauchen hier immer 3-4 Suchvorgänge bis der erste Report im WSUS empfangen wird. Habe da was über die Ursache geschrieben und die Informations-Quelle dazu verlinkt:
https://borncity.com/blog/2026/07/15/patchday-windows-10-11-updates-14-juli-2026/#comment-261370
Danke!
D.h. bei jeder Neuinstallation von WSUS darf man das erneut setzen, da MS ja WSUS als "deprecated" sieht…
Mit dieser Batchdatei kann das Onboarding neuer Client am WSUS beschleunigt werden, brachial, aber effektiv. Läuft auch im normalen Benutzer-Kontext, braucht keine Admin-Rechte.
UsoClient-StartScan-4x.cmd:
REM Accelerating WSUS onboarding for Windows computers
REM Adjust the timeout and number of iterations to the local environment.
REM
UsoClient StartInteractiveScan
timeout 180
UsoClient StartInteractiveScan
timeout 180
UsoClient StartInteractiveScan
timeout 180
UsoClient StartInteractiveScan
Testweise hilft es vielleicht auch, die SUSClientID der betroffenen Clients für den WSUS zurückzusetzen.
CMD auf dem Client als Admin ausführen, Syntax (ohne Gewähr):
net stop wuauserv
REG Delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId /f
REG Delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientIdValidation /f
net start wuauserv
wuauclt.exe /resetauthorization /detectnow
"wuauclt.exe /resetauthorization /detectnow" das funktioniert bei Windows 11 nicht mehr
In unserer Umgebung (Windows Enterprise 25H2) funktioniert der Fallback "wuauclt.exe" nach wie vor ohne Probleme.
Mag bei anderen Windows-Editionen (Home, Pro) nicht der Fall sein.
Übersicht laut KI:
Der Befehl usoclient /reportnow existiert in Windows nicht. Um einen Client dazu zu zwingen, seinen aktuellen Patch-Status an einen WSUS-Server zu melden, muss stattdessen das ältere Kommandozeilentool wuauclt.exe mit dem Parameter /reportnow verwendet werden.
W10: wuauclt.exe /detectnow
=
W11: UsoClient StartInteractiveScan
Ja, der Parameter /reportnow funktioniert noch, aber wie Horst schon schrieb, /detectnow nicht mehr!
Hilfreiche Informationen rund um das Thema Windows Update Client:
https://inventivehq.com/blog/windows-update-commands-powershell-usoclient-amp-wuauclt
Hier hat folgendes geholfen:
Link: https://learn.microsoft.com/de-de/troubleshoot/mem/configmgr/update-management/error-80244007-when-wsus-client-scans-updates
takeown /f web.config
icacls web.config /grant administrator:(F)
notepad.exe web.config
Änderung auf:
"maxInstalledPrerequisites" value="800"
"maxCachedUpdates" value="44000"
Dann hat nur der Neustart des WSUS-Dienstes etwas gebracht.
Nur Windows11-Kisten hatten sich zum letzten Mal am 02.07.26 gemeldet. Danach nicht mehr. Jetzt trudeln sie langsam alle ein.
Auf das verhalten der Clients seit (kein Report an den WSUS) seit letzter Woche hat das bei uns leider keine positiven Effekt.
Wer kaputt macht, muss auch wieder ganz machen….
https://www.heise.de/news/Microsoft-raeumt-Stoerungen-der-WSUS-Dienste-ein-11370682.html
> Microsoft hat in den Known Issues für das Update KB5099540 für Windows Server
> 2022 folgende Information eingetragen:
> After installing KB5070884 or later updates, Windows Server Update Services (WSUS) > does not display synchronization error details within its error reporting.
Die Top-Profis, für die alles selbstverständlich ist, verzeihen mir bitte die Frage … es fehlt mir hier die Info, ob das Verhalten seitens der WSUS-CLIENTS auftritt, nachdem man auf ihnen KB5070884/5099540 installiert hat?
ODER das Verhalten auftritt, wenn man direkt auf dem WSUS-SERVER KB5070884/5099540 installiert hat?
Vielleicht kann sich jemand erbarmen und das einmal deutlich benennen.
Habe den Workaround 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 durchgeführt. Dennoch melden zwei Fujitsu Desktop Rechner keinen Status mehr. Was kann man noch tun? das CU deinstallieren?