WSUS Sync Störung Juli 2026

Seit dem 13. Juli synchronisieren WSUS-Server nicht mehr zuverlässig. Microsoft hat die Störung bestätigt, am 18. Juli eine Mitigation ausgerollt – die aber nur für neu installierte Server greift. Bestehende Installationen warten weiter auf eine Cleanup-Anleitung. Was ihr jetzt tun solltet: erstaunlich wenig. Und warum das die schwierigste Empfehlung ist.

Was passiert ist

Einen Tag vor dem Juli-Patchday, am 13. Juli 2026, begannen WSUS-Server auffällig langsam zu synchronisieren. Kurz darauf liefen die Sync-Vorgänge in Timeouts. In den Logs standen Verbindungsfehler zu den Microsoft-Update-Endpunkten – also genau das Fehlerbild, bei dem jeder erfahrene Administrator zuerst an Proxy, TLS oder IIS denkt.

Genau das war es diesmal nicht. Microsoft nennt als Ursache eine Anhäufung von Publishing-Metadaten, die den Synchronisationsprozess verstopft hat. Betroffen sind laut Microsoft alle unterstützten Windows-Client- und Server-Versionen. Es handelt sich ausdrücklich nicht um einen Fehler in den kumulativen Updates vom 14. Juli.

Das ist ein wichtiger Unterschied: Die Ursache liegt nicht in eurer Umgebung. Sie ist geteilt. Und deshalb helfen die Maßnahmen, die bei den üblichen WSUS-Problemen wirken, hier nicht – sie können sogar Schaden anrichten.

Der Stand am 21. Juli

Szenario	Status
Neu installierter WSUS	Die serverseitige Mitigation vom 18.07.2026 greift. Sync-Zeiten und Sync-Vorgänge sind wieder normal. Auch das zuvor gemeldete Problem beim Erst-Sync neuer Installationen sollte damit erledigt sein.
Neu aufgebauter WSUS	Ebenfalls unproblematisch – sofern der Aufbau nach dem 18.07. erfolgt ist.
Bestehender, betroffener WSUS	Weiterhin blockiert. Die problematischen Metadaten liegen bereits in der Installation. Microsoft arbeitet an einer Anleitung zum sicheren Entfernen – veröffentlicht ist sie noch nicht. Es gibt aktuell keinen vom Kunden ausführbaren Workaround.

Schritt 1: Seid ihr überhaupt betroffen?

Bevor irgendetwas unternommen wird, gehört der Zeitpunkt der letzten erfolgreichen Synchronisation geprüft. Beginnen die Fehlschläge am oder kurz nach dem 13. Juli, handelt es sich mit hoher Wahrscheinlichkeit um diesen Vorfall – und nicht um ein Problem in eurer Umgebung.

<#
    Get-IswWsusSyncStatus.ps1
    Liest die Synchronisationshistorie eines WSUS-Servers aus und
    bewertet, ob das Fehlerbild zum bekannten Vorfall ab 13.07.2026 passt.
    Rein lesend. Auf dem WSUS-Server oder mit installierter WSUS-Konsole ausfuehren.
#>

[CmdletBinding()]
param(
    [string] $WsusServer = $env:COMPUTERNAME,
    [int]    $Port       = 8530,
    [switch] $UseSSL,
    [int]    $Tage       = 21
)

[void][reflection.assembly]::LoadWithPartialName('Microsoft.UpdateServices.Administration')

try {
    $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer(
                $WsusServer, [bool]$UseSSL, $Port)
}
catch {
    Write-Host "Verbindung zum WSUS fehlgeschlagen: $($_.Exception.Message)" -ForegroundColor Red
    return
}

$sub = $wsus.GetSubscription()

Write-Host ''
Write-Host '=== WSUS Synchronisationsstatus ===' -ForegroundColor Cyan
Write-Host ("Server                : {0}" -f $WsusServer)
Write-Host ("Letzte Sync (Ergebnis): {0}" -f $sub.GetLastSynchronizationInfo().Result)
Write-Host ("Letzte Sync (Start)   : {0}" -f $sub.GetLastSynchronizationInfo().StartTime.ToLocalTime())
Write-Host ("Letzte Sync (Ende)    : {0}" -f $sub.GetLastSynchronizationInfo().EndTime.ToLocalTime())
Write-Host ("Aktueller Status      : {0}" -f $sub.GetSynchronizationStatus())
Write-Host ''

$seit    = (Get-Date).AddDays(-$Tage)
$verlauf = $sub.GetSynchronizationHistory() |
           Where-Object { $_.StartTime.ToLocalTime() -ge $seit } |
           Sort-Object StartTime -Descending

$tabelle = foreach ($h in $verlauf) {
    $start = $h.StartTime.ToLocalTime()
    $ende  = $h.EndTime.ToLocalTime()
    [pscustomobject]@{
        Start    = $start
        Ergebnis = $h.Result
        Dauer    = '{0:hh\:mm\:ss}' -f ($ende - $start)
        Fehler   = if ($h.Error) { $h.Error } else { '' }
    }
}

$tabelle | Format-Table -AutoSize

# --- Bewertung ---
$vorfall     = Get-Date '2026-07-13'
$letzterOk   = ($verlauf | Where-Object { $_.Result -eq 'Succeeded' } |
                Select-Object -First 1).StartTime
$fehlerNach  = @($verlauf | Where-Object {
                    $_.Result -ne 'Succeeded' -and $_.StartTime.ToLocalTime() -ge $vorfall })

Write-Host '=== Bewertung ===' -ForegroundColor Cyan
if ($letzterOk) {
    Write-Host ("Letzte erfolgreiche Sync : {0}" -f $letzterOk.ToLocalTime())
} else {
    Write-Host "Letzte erfolgreiche Sync : keine im Betrachtungszeitraum" -ForegroundColor Yellow
}

if ($fehlerNach.Count -gt 0 -and $letzterOk -and $letzterOk.ToLocalTime() -lt $vorfall) {
    Write-Host ''
    Write-Host "PASST ZUM BEKANNTEN VORFALL (ab 13.07.2026)." -ForegroundColor Yellow
    Write-Host "-> Keine SUSDB-Bereinigung, kein Neuaufbau. Microsofts Cleanup-Anleitung abwarten." -ForegroundColor Yellow
} elseif ($fehlerNach.Count -eq 0) {
    Write-Host ''
    Write-Host "Keine Fehlschlaege seit dem 13.07.2026 - Server vermutlich nicht betroffen." -ForegroundColor Green
} else {
    Write-Host ''
    Write-Host "Fehlerbild passt nicht eindeutig. Proxy, TLS, IIS und Speicherplatz pruefen." -ForegroundColor Gray
}
Write-Host ''

In Configuration-Manager-Umgebungen gehört zusätzlich die wsyncmgr.log geprüft, bevor ein fehlgeschlagener Lauf als Datenbankkorruption oder Zertifikatsproblem interpretiert wird. Der Software Update Point meldet in diesem Fall Folgefehler, keine Ursachen.

Schritt 2: Patchen, ohne auf WSUS zu warten

Das eigentliche Problem ist nicht der kaputte WSUS – es ist, dass die Juli-Updates nicht ausgerollt werden. Und der Juli-Patchday enthält aktiv ausgenutzte Zero-Days. Warten ist also keine Option; nur das Aufräumen des WSUS muss warten.

Drei gangbare Wege für die Übergangszeit:

Kritische Systeme manuell	MSU aus dem Microsoft Update Catalog ziehen und gezielt auf DCs, Exchange, RDS-Hosts und internetexponierte Systeme einspielen. Aufwendig, aber für die zehn wichtigsten Server machbar.
Clients temporär direkt	Per GPO für einen begrenzten Zeitraum auf Windows Update umstellen. Funktioniert, macht aber die Reporting-Kette kaputt – und muss zwingend zurückgedreht werden, sonst fällt es euch in sechs Monaten auf die Füße.
Zweiter WSUS	Eine neue Instanz auf einer VM aufsetzen – die synchronisiert wieder normal. Der alte Server bleibt unangetastet stehen, bis die Cleanup-Anleitung da ist. Der sauberste Weg, wenn Kapazität vorhanden ist.

Die unbequeme Frage dahinter

WSUS ist von Microsoft als deprecated eingestuft. Es bekommt keine neuen Funktionen mehr, wird aber im Rahmen der Produkt-Lifecycles weiter unterstützt und ist für den Produktivbetrieb weiterhin zulässig. Genau diese Zwitterstellung macht den aktuellen Vorfall so unangenehm: Ein Dienst, in den nicht mehr investiert wird, ist bei vielen Organisationen der einzige Pfad, über den Sicherheitsupdates ins Netz kommen.

Ich halte nichts von Panikreaktionen – ein funktionierender WSUS mit gepflegten Genehmigungsgruppen ist immer noch besser als eine hastig eingeführte Cloud-Lösung, die niemand bedienen kann. Aber die Frage, die dieser Juli aufwirft, sollte man sich stellen: Habt ihr einen zweiten Weg, Patches auszurollen, wenn der erste ausfällt? Bei den meisten Umgebungen, die ich sehe, lautet die ehrliche Antwort nein.

Das ist kein WSUS-Problem. Das ist ein Single-Point-of-Failure im Patch-Prozess – und für NIS-2-pflichtige Einrichtungen ist genau das ein Punkt, der im Risikomanagement dokumentiert und mit einer Ausweichoption hinterlegt sein sollte.

Checkliste

1.	Sync-Historie prüfen. Beginnen die Fehler ab 13.07.? Dann ist es der bekannte Vorfall.
2.	Bei WSUS-Hierarchien alle Ebenen vergleichen, nicht nur den Upstream.
3.	Nichts löschen. Keine SUSDB-Bereinigung, kein Reindexing, kein Content-Store-Reset, kein Neuaufbau als Reflex.
4.	Juli-Updates für kritische Systeme auf einem Ersatzweg ausrollen – die Zero-Days warten nicht.
5.	Aktuelle Konfiguration dokumentieren und sichern, bevor später irgendetwas bereinigt wird.
6.	Windows Release Health und das Message Center im Blick behalten – die Cleanup-Anleitung kommt dort zuerst.

Ich aktualisiere diesen Beitrag, sobald Microsoft die Anleitung zur Metadaten-Bereinigung veröffentlicht.