Seit Freigabe der Sicherheitsupdates vom 14. Juli 2026 haben Administratoren das Problem, dass Windows Clients sich nicht mehr sauber beim WSUS melden. Microsoft hatte das Problem bestätigt und einen serverseitigen Fix implementiert. Zudem hat Microsoft eine Lösung veröffentlicht, falls Clients trotzdem nicht reporten.
Rückblick auf das WSUS-Problem
Kurz nach Freigabe der Windows-Updates vom 14. Juli 2026 (siehe Patchday: Windows 10/11 Updates (14. Juli 2026) und Patchday: Windows Server-Updates (14. Juli 2026)) 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 beim 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.
Zum 20. Juli 2026 hat Microsoft dann die WSUS-Sync-Probleme offiziell bestätigt. In einem Beitrag mit dem Titel "Windows Server Update Service sync operations might have issues or time out" 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. 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.
Microsoft veröffentlich WSUS-Hinweise für Fixes
Einige Administratoren stellten aber fest, dass Windows-Clients weiterhin nicht sauber an den WSUS reporten. Zum 20. Juli 2026 hat Microsoft dann noch den Supportbeitrag Resolved: Windows Server Update Services sync operations issues and timeouts veröffentlicht. Horst hat in diesem Kommentar hier im Blog auf diesen Supportbeitrag hingewiesen (danke dafür). Ich bin zudem über die Patchmanagement.org Mailingliste sowie diesen Beitrag der Kollegen auf den Supportbeitrag aufmerksam geworden.
Microsoft erklärt das Problem der fehlerhaften WSUS-Client-Synchronisation als gelöst. Die Beeinträchtigung der Dienstleistung (Client-Reporting an WSUS) ging auf eine Anhäufung veröffentlichter Test-Detectoids im Windows Server Update Services (WSUS)-Kanal zurück. Diese Detectoids lassen sich anhand eines Namensmusters erkennen:
Produkt-Detectoid für Produktname TestProdukt%
Ein Problem-Detectoid könnte beispielsweise wie folgt aussehen:
Produkt-Detectoid für Produktname TestProduct1272ad5c-e150-4370-b18d-7b940bd0e518
In Unternehmen kann es zu verlängerten Synchronisierungszeiten oder Zeitüberschreitungen bei Synchronisierungsvorgängen auf WSUS-Servern kommen. Dieses Problem trat laut Microsoft erst kürzlich auf, wobei seit dem 13. Juli 2026 verstärkte Auswirkungen zu beobachten sind.
Microsoft hat am 18. Juli 2026 intern die bereits oben erwähnte Abhilfemaßnahme für dieses Problem bereitgestellt. Die Synchronisierungszeiten und Synchronisierungsvorgänge auf WSUS-Servern wurden wiederhergestellt und funktionieren bei neuen WSUS-Installationen und -Neuinstallationen wieder normal. Diese Abhilfemaßnahme verhindert, dass neu installierte oder neu aufgesetzte WSUS-Server von diesem Problem betroffen sind.
Auf Clients kann die Anhäufung außerdem dazu führen, dass Windows Update-Scans fehlschlagen oder eine Zeitüberschreitung auftritt. Betroffene Clients protokollieren möglicherweise diverse Fehler, die im Microsoft-Supportbeitrag Resolved: Windows Server Update Services sync operations issues and timeouts aufgeführt sind.
Für WSUS-Server, bei denen dieses Problem weiterhin auftritt, empfiehlt Microsoft im Supportbeitrag eine Schrittfolge, um die SUSDB-Datenbank zurück zu setzen. Dabei muss ein Backup der Datenbank angelegt und diese dann per Clean-Befehl geleert werden. Die genaue Schrittfolge ist im Microsoft-Supportbeitrag Resolved: Windows Server Update Services sync operations issues and timeouts beschrieben. Den Kommentaren hier im Blog scheint es aber nicht bei allen Fällen zu helfen.
Ähnliche Artikel:
Windows-Clients: WSUS-Reporting-Probleme nach Updates vom 14. Juli 2026
Microsoft bestätigt WSUS-Sync-Probleme nach Juli 2026-Updates
Windows-Server: WSUS-Installations-/Erst-Sync-Problem
MVP: 2013 – 2016
Tatsächlich scheint es sich hier um zwei Probleme seit dem Patchday zu handeln:
a) die SUSDB Metadaten-Problematik -> ist wohl gelöst durch den MS Workaround / Datenbankbereinigung
b) die (erneut?) gepatchte "parameter deserialization flaw" Lücke im WSUS ReportingWebService. Es dürfen da nun nicht mehr als 32 Zeichen im DMI-Infobereich als Bezeichner stehen & vor allem KEIN leeres Feld (möglicherweise hat ja die KI nen Weg gefunden diese leeren Felder mit ausführbaren Code zu füllen & zu interpretieren ?).
Wir haben das mal im Labor mit zwei Systemen getestet -> und schwupps sofort haben die wieder anstandslos an den WSUS reported .
Die Systeme mit einem leeren Feld in des System-IDs machen hingegen weiterhin zicken.
das mehr als 32 Zeichen (mehr wäre vermutlich ziemlich ungewöhnlich?) geblockt wird um zu verhindern das dort möglicherweise Code mit übermittelt wird macht durchaus Sinn.
Das es aber auch geblockt wird wenn das Feld leer ist, würde ich eher als Bug sehen.
Wie genau ist das betroffene Feld bezeichnet?
Wir haben auf HP Rechnern getestet, da befinden sich die relevanten Informationen im BIOS ( F10) auf der Startseite in "System-IDs" -> "Nummer für Systemverfolgung" & "Eigentümerkennung".
In beide einfach alphanumerischen Code eintragen z. B. PC0123 & Meiner.
Das Feld "Eigentümerkennung" war bei diesen Rechnern default leer, nach einem Eintrag haben die wieder den Report ausgeführt.
@Khappa
weißt du in welchen Feldern die von die eingetragenen Werte im Windows landen?
Findest du die ggf. mit Get-ComputerInfo wieder?
Der Asset Tag & der Ownership Tag liegen in zwei unterschiedlichen WMI-Klassen:
Asset Tag: das was hier ausgegeben wird ist der relevante Wert -> (Get-CimInstance -ClassName Win32_SystemEnclosure).SMBIOSAssetTag
Ownership Tag: das was hier ausgegeben wird ist der relevante Wert -> Get-CimInstance -Namespace "root\hp\instrumentedBIOS" -ClassName HP_BiosSetting |
Where-Object { $_.Name -like "*Ownership Tag*" } |
Select-Object -ExpandProperty Value
hoffe das hilft dir weiter -> VG Khappa
Hallo,
> "root\hp\instrumentedBIOS"
Das ist ein HP-spezifischer Fall, den Pfad gibt es so auf Fujitsu Maschinen nicht.
Was mir beim rumpopeln auffiel:
r=1,
t= ,
w=0,
Der in der Fehlermeldung beanstandete Parameter "t" scheint eher NULL zu sein.
Grüße
Zu b)
https://learn.microsoft.com/en-us/answers/questions/5953231/wsus-and-windows-11-25h2-asus-clients-sync-success
Der Enabler der 22H2 Funktionen funktioniert auch mit 21H2 LTSC. Darf man auch installieren.
Hier geht es aber mehr um .net. Es wird künftig nur noch 4.81 unterstützt werden. Man muss das Update von 4.8 auf 4.81 halt auf älteren Windows 10 Versionen installiert haben. Bei LTSC/B selbst, weil es nicht automatisch geschieht.
Wer nicht aus Legacy-Gründen auf dem funktionalen Stand von so ollen Kamellen gefangen ist dürfte hier keine Probleme haben. Und welche dieser dann doch sehr speziellen Fossilien hängt in der Cloud? Die sollte man dann halt auf Google umstellen ;)
Daran dürfte sich nicht nur bis 2029, sondern mindestens 2031 nicht wirklich etwas ändern. Sagt zumindest mein heutiger Kaffeesatz.
Der Fix funktioniert nur, wenn WSUS mit MS-SQL betrieben wird. Wer WSUS mit der WID (Windows Internal Database) betreibt, kann dieser Anleitung leider nicht folgen, da er kein MS-SQL-Management-Studio hat, in dem die Befehle ausgeführt werden müssen. Wenn mehrere WSUS für z.B. verschiedene Standorte kaskadiert werden, muss das alles wahrscheinlich auf allen WSUS-Instanzen durchgeführt werden.
man kann das SQL Mangement Studio kostenfrei bei MS runterladen und damit auf die WID zugreifen
Open SQL Server Management Studio 🡪 On Connect to Server screen, specify the following named pipe connection string in the Server name textbox and click on Connect.
np:\\.\pipe\MICROSOFT##WID\tsql\query
Oder einfach mit der PowerShell:
https://pastebin.com/WNFprrsj
"-Encrypt Optional" braucht es IIRC ab Server 2022.
WID ist ein SQL-Server im Tarnkappenmodus im Pfad C:\Windows\WID\Binn. Die SUSDB-Datenbank liegt in C:\Windows\WID\Data und die Logfiles in C:\Windows\WID\Log. Der Prozess heisst auch sqlservr.exe. WID hat kein Datenbankgrößenlimit. Der Versionsnummer 2014.120.5214.6 nach ein SQL Server 2014 hier auf einem Windows Server 2022.
Auch die Remote Desktop Services nutzen WID. Dort liegt die Datenbank in C:\Windows\rdcbDb (Standardinstallation ohne Hochverfügbarkeit der Sessionbroker).
Wie man WID verwalten kann haben die Vorposter schon beschrieben.
Die SUSDB liegt standardmäßig am angegebenen Ort.
Aber da muss die nicht liegen.
Man kann die auch auf ein anderes Laufwerk verschieben.
Und aus Performance- und Platzgründen evtl. auch empfehlenswert.
Denn im Grunde haben Datenbanken auf einem Systemlaufwerk nichts zu suchen. Das sollte rein fürs System sein und nicht für Daten.
Spricht etwas dagegen, die Problemlösung von Microsoft für bestehende WSUSe einfach mal umzusetzen? Ich habe nicht wirklich Probleme festgestellt, es allerdings nicht genau beobachtet. Allerdings so als Profilaxe…..
Ich hab WSUS auf einem Server 2022 im Einsatz und verwende ihn nur, um Server-Systeme zu patchen. Also nur Windows Server 2016, 2019, 2022 und 2025. Als DB wird ein SQL Standard eingesetzt, keine WID
Behandelt aber leider aber auch nur das eine mittlerweile gelöste Problem (metadata/susdb) und nicht das zweite WSUS Security fix im 07-2026 Patch das Clienten mit diversen DMI Einträge vom Reporting blockt
Ergänzend:
Zu der Thematik hat Björn Walter am 21.07.26 auf seinem Blog einen Beitrag mit zusätzlichen Informationen veröffentlicht.
Siehe:
WSUS Sync Störung Juli 2026
https://www.der-windows-papst.de/2026/07/21/wsus-sync-stoerung-juli-2026/
Danke, das ist der bisher beste Beitrag zum Thema.
Auch Wolfgang Sommergut hat auf seinem Blog am 22.07.26 zu der Thematik einen Beitrag mit zusätzlichen Informationen veröffentlicht.
Siehe:
Wegen Sync-Problemen: WSUS von Microsofts Test-Detectoids bereinigen
https://www.windowspro.de/wolfgang-sommergut/wegen-sync-problemen-wsus-microsofts-test-detectoids-bereinigen
#Bernie – btw Fix auch schon erhalten..
regedit HKLM\SAM – per Nachricht von Sam :-)
https://ibb.co/kVdjqg45
Hallo,
Frage an die, die Fujitsu Maschinen im Einsatz haben, die nicht mehr reporten wollen:
Unter "Computer\HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS", was steht im Wert "SystemSKU"?
Ich habe die Beobachtung gemacht, dass die Maschinen, die unter "SystemSKU" einen Wert haben, reporten, die, die dort kein Wert haben nicht reporten.
Grüße
Bei uns steht da tatsächlich nichts. Ist es Wurst, was man da einträgt?
bei des MS Hyper-V Clients (die problemlos die ganze Zeit reporten) steht da tatsächlich einfach nur das Wort "none" drin.
Hm, scheint nicht zu helfen. Habe hier zwei Kandidaten von Fujitsu. Bei einem habe ich was eingetragen, beim anderen nicht. Schicken aber beide keinen Report. Auch nicht nach der Datenbankbereinigung.
Allerdings geht die Suche nun wieder schnell und ohne "Round Trip" Fehlermeldung.
Hier dauert es immer 8-10 Minuten nach dem Scan bis ein Report gesendet wird, auch wenn man nach dem Scan den Report mit wuauctl /reportnow anfordert. Letzter Kontakt sollte sich in der WSUS-Console aber schneller ändern nach dem Scan.
Als Administrator kann man den Wert von SystemSKU aus Windows heraus nur in der Registry ändern, ABER dieser Wert überlebt keinen Neustart, da er beim booten wieder aus dem BIOS ausgelesen wird.
Man könnte nach dem Neustart einen Skript ablaufen lassen welcher den Wert für SystemSKU auf „none" setzt. Könnte mit einer Startup-Computer-Gruppenrichtlinie funktionieren (habe es nicht getestet).
Einfacher wäre es, wenn Microsoft im Code des Windows Update Client einfach „none" oder „undefined" übergeben würde wenn SystemSKU leer ist. Das hatten die Entwickler aber vermutlich nicht auf dem Radar als die Sicherheitslücke geschlossen wurde.
Wenn man die Variable (DMI-Felder) aus dem OS heraus im BIOS permanent setzen möchte, liefert der Suchbegriff „how to write description field bios SystemSKU" mit Google einige Infos dazu. Es soll aber auch BIOS geben wo das Feld immer read-only ist (aber hoffentlich vom Hersteller ordentlich gefüllt).
"Man könnte nach dem Neustart einen Skript ablaufen lassen welcher den Wert für SystemSKU auf „none" setzt. Könnte mit einer Startup-Computer-Gruppenrichtlinie funktionieren (habe es nicht getestet)."
Oder besser als Scheduled Task, dann geht man auf Nummer sicher das das auch geschrieben wird, wenn der Rechner mal außerhalb des Firmennetzwerks neu gestartet wird.
Hallo,
SystemSKU war eine Vermutung, ist es leider nicht – ob da was drinsteht (vom BIOS aus oder per Brechstange) ist egal.
Grüße
Ergänzung:
Leser Fritz hatte letzte Woche die Vermutung geäussert „Problem ist wohl hauptsächlich die Inventarnummer (Asset Tag) im DMI-Infobereich" und erwähnt einen Vorschlag vom Hersteller:
„FSAS/Fujitsu bog mit dem Vorschlag um die Ecke, die mit Hilfe eines Kommandozeilentools aus der DeskUpdate-Suite zu setzen, das geht wohl auch aus einem laufenden Windows heraus, braucht aber Administratorrechte."
Ob das „Asset Tag" auch in der Registry vorhanden ist und jeweils nach dem Neustart auf "undefined" gesetzt werden könnte wenn es leer oder nicht vorhanden ist?
Ist dieser Wert gemeint? wmic bios get serialnumber
https://borncity.com/blog/2026/07/15/patchday-windows-server-updates-14-juli-2026/#comment-261463
Könnte man mal zum testen und vergleichen auf betroffenen/nicht betroffenen Systemen auslesen per Powershell:
(Get-WmiObject win32_SystemEnclosure).smbiosassettag
addon, mögliche Variablen:
https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-systemenclosure
(Get-WmiObject win32_SystemEnclosure).smbiosassettag gibt sowohl auf dem HP-Notebook wie auch in einer Hyper-V Windows 11 VM den gleichen String-Wert aus wie wmic bios get serialnumber, diese Systeme liefern auch Reports. Betroffene Systeme habe ich keine (auch der Intel NUC funktioniert hier), trotzdem beschäftigt mich die Frage wie man das lösen könnte.
Ergängung:
(Get-WmiObject win32_SystemEnclosure).tag gibt auf beiden Systemen "System Enclosure 0" aus.
(Get-WmiObject win32_SystemEnclosure).SKU gibt auf beiden Systemen nichts aus, hat also vermutlich nichts mit dem Registry-Wert von SystemSKU weiter oben zu tun, denn SystemSKU ist mit einer Zeichenfolge gefüllt.
Get-WmiObject win32_computersystem | Select-Object SystemSKUNumber
Scheint bei betroffenen Systemen leer zu sein. Bei nicht betroffenen steht irgendwas drin.
Die Frage ist auchm ob dieses Feld die einzige Ursache ist.
Ich habe Systeme wo das Feld leer ist (nicht Fujitsu) und nicht reporten.
Ich habe aber auch Systeme wo das Feld gefüllt ist (von Fujitsu) die auch nicht reporten. Das allein scheint es also nicht zu sein.
"none" eintragen hat bei mir auch nicht geholfen bei den Systemen mit leerem Feld.
Hallo,
hier reporten die Celsius'se, die Esprimos nicht.
Grüße
Hallo,
Als Sammelantwort:
Mein Einstiegspunkt ist der Wert "BiosLockString" unter "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization". Mit diesem Wert kann man dem HyperV sagen, welchen BIOS-Hersteller an die VMs melden soll. Dass ermöglicht dann das Verwenden von Lizenzen, die an einen Hersteller gebunden sind.
Eben dieser Wert muss 32 Zeichen haben, nicht belegte Zeichenpositionen müssen mit Leerzeichen aufgefüllt werden. Daran musste ich bei den "32 Leer- bzw. Nul-Zeichen" denken, die beim Reporting nicht mehr zulässig sind.
Beim Vergleichen der BIOS-Werte fiel mir auf, dass "SystemSKU" bei den betroffenen Geräten leer ist – was mich zu der Frage brachte, ob das eventuell die Ursache ist.
Aber leider zeigte diverses Rumprobieren keine Abhilfe.
Grüße
ich rate nur rum:
ggf gibt es mehrere Werte (einer davon ist SystemSKU) die vom System aus leer sein können und sobald eine oder mehrerer leer sind tritt das Problem auf, dann könnte es auch passieren, das wenn man testweise SystemSKU befüllt aber noch ein anderer relevanter Wert leer ist, das Problem trotzdem auftritt.
Moin,
hab mir grad das BIOS meines Rechners angesehen, ich hab hier keine Möglichkeit für eine SKU was einzutragen, wenn das wirklich das Problem sein sollte.
(Get-WmiObject win32_SystemEnclosure).tag
System Enclosure 0
Get-WmiObject win32_computersystem | Select-Object SystemSKUNumber
SystemSKUNumber
—————
Modell: Fujitsu Esprimo P558
lt. meinen Reports bzw. Listen sind es auch nur diese PCs die Probleme haben. Alle anderen (Teilweise andere Fujitsu Modelle, HP, Lenovo … alles OK)
Computer\HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS\SystemSKU ist auch leer
Wie macht man das jetzt? Noch aussitzen?
WSUS neu aufsetzen?
Darf der SKU Wert bei allen gleich sein, oder muss es immer ein anderer sein?
Da hat Microsoft wieder saubernen Bock geschossen
Schöne Restwoche noch :(
"WSUS neu aufsetzen?" bringt nix.
Du könntest das Juli Security Patch für den Server mit dem WSUS deinstallieren (wenn man das denn wirklich will) dann geht es auch wieder, oder auf MS warten.
Mal eine Frage in die Runde.
Ist irgendwas bekannt, dass selbst bei nicht verwalteten Geräten, sprich Privaten Rechner aktuell auch die Windows Update Suche nicht funktioniert ?
Server 2022 mit mehreren Raidvolumen – No accasible Bootdevice nach Update 07.2026 auf Tarox Server.
Wir haben willkürliche Vergabe von Laufwerksbuchstaben, mit Diskpart repariert, boot dennoch defekt. Im Bios sind die Volumen aber noch richtig.
Nach der Reparatur der urspünglichen Laufwerksbuchstaben kann der Systemwiederherstellungpunkt erfolgreich angewendet werden.
Server startet dann sauber.
Updates wieder eingespielt – Server nach reboot sofort wieder defekt.
Updates nun ausgesetzt.
Frage: Hat das noch Jemand?
Ich habe 4 weiter Server der Baureihe Nov.2025, diese haben nur ein Raidvolumen und produzieren den Fehler nicht. Die KI sagt das liegt an den mehreren Volumen, aber die Lösung der KI(im Bios VoluemnbootOrdern herstellen und SafeBoot ausmachen) hilft nicht, da im Bios alles oaky und richtig aussieht.
Was hat das jetzt mit dem WSUS-Sync zu tun?
Moin,
hier gibts wohl noch nix Neues wie ich so lese.
Meint ihr, dass MS das wieder hinbekommt mit dem nächsten Patch?
Was für alternativen hat man? Hab jetzt leider kein Budget um Drittanbieter-Software zu kaufen, welches Patchmanagement übernimmt.
Worst case jeden Client einfach "online" Updates ziehen lassen ohne WSUS?
Wünsche euch ein schönes Wochenende
Nicht nur hier, ich habe nirgendwo neue Erkenntnisse zum Kommunikationsproblem der Clients gefunden. Bei uns sind alte Esprimo-Modelle (P558, Q558) betroffen und zwar alle. Manche wurden noch gepatcht, da sie in der Testgruppe drin sind, aber es meldet sich keiner mehr, seitdem der WSUS-Server aktualisiert wurde. Neuere Modelle und VMs kommunizieren weiterhin wie gewohnt.
Nachtrag – die betroffenen Clients werden aktualisiert, lediglich die Kommunikation mit WSUS findet nicht statt.
Ich denke, das ist im Moment erstmal das erwartbare Verhalten des WSUS-Servers. Ich hoffe mal, dass sie das im nächsten Monat angehen.
P558 haben wir hier auch zu 90%
alle anderen 10% funktionieren problemlos
bei den p558 finde ich nichts im bios zum einstellen der sku o. ä.
Bei uns sind auch nur Fujitsu Esprimo P557 mit Windows 11 25H2 betroffen. HP-Server, HP Notebooks und Lenovos haben keine Probleme und haben im WSUS einen aktuellen Statusbericht.
Von Fujitsu wird da nichts mehr kommen, da DeskUpdate auf den Kisten nur bis Windows 10 funktioniert hat und Fujitsu ja eh Geschichte ist im PC-Bereich.
Ein echt ärgerliches Problem.