RDS-Ausfälle nach dem September-Patchday: Haben wirklich alle Server das Out-of-Band-Update?

Die September-Updates haben Terminalserver reihenweise lahmgelegt. Microsoft hat nach sechs Tagen mit Out-of-Band-Updates nachgebessert – doch die Korrektur erreicht längst nicht jeden Server automatisch. Vor dem Oktober-Patchday am 13.10. lohnt sich ein Kontrollblick.

Was ist passiert?

Nach den kumulativen Updates vom 8. September 2026 meldeten Administratoren, dass Remote Desktop Services auf Windows Server 2016, 2019, 2022 und 2025 zunächst normal liefen und nach einigen Stunden ausfielen. Typische Symptome:

• RDP-Verbindungen und Anmeldungen brechen nach einigen Minuten ab.
• Der Server hängt bei der Meldung „Bitte warten Sie auf die Remotedesktopkonfiguration“.
• MMC, RD-Lizenzierungsdiagnose, Explorer und die Windows-Update-Seite reagieren nicht mehr.
• In einzelnen Fällen half nur ein harter Reset.

Microsoft hat das Problem am 12. September bestätigt und am 14. September Out-of-Band-Updates veröffentlicht. Windows 365 und Azure Virtual Desktop waren nicht betroffen.

Die richtigen KB-Nummern

Die OOB-Updates sind kumulativ: Sie enthalten die Sicherheitskorrekturen des September-Patchdays plus den RDS-Fix. Das ursprüngliche Update muss also nicht deinstalliert werden – und sollte es auch nicht, denn damit verschwinden die Sicherheitsfixes gleich mit.

Warum viele Server die Korrektur noch nicht haben

• WSUS: OOB-Updates werden nicht in jeder Umgebung per Synchronisierung angeboten. Dann müssen sie aus dem Microsoft Update Catalog importiert und freigegeben werden.
• Server 2016: KB5129239 wird nur angeboten, wenn das aktuelle Servicing Stack Update installiert ist.
• Rollback statt Fix: Wer im Stress das September-Update entfernt hat, steht jetzt ohne die Sicherheitsfixes da und hat die Rückkehr womöglich vergessen.
• Known Issue Rollback (KIR): Eine per GPO verteilte KIR-Richtlinie stört das OOB-Update nicht, bleibt aber als Altlast liegen und sollte nach dem Fix wieder entfernt werden.

Prüfskript für den eigenen Bestand

Das folgende Skript ermittelt per WinRM auf allen Servern Build und UBR und zeigt, ob das passende OOB-Update installiert ist:

$server = Get-ADComputer -Filter 'OperatingSystem -like "*Server*" -and Enabled -eq $true' |
          Select-Object -ExpandProperty DNSHostName

Invoke-Command -ComputerName $server -ErrorAction SilentlyContinue -ScriptBlock {
    $soll = @{ 14393 = 'KB5129239'; 17763 = 'KB5129238'; 20348 = 'KB5129237'; 26100 = 'KB5129235' }
    $cv   = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
    $build = [int]$cv.CurrentBuildNumber
    $kb    = $soll[$build]
    [pscustomobject]@{
        Build    = "$build.$($cv.UBR)"
        SollKB   = $kb
        OOB      = if ($kb) { [bool](Get-HotFix -Id $kb -ErrorAction SilentlyContinue) } else { 'n/a' }
        RDS      = (Get-Service TermService).Status
    }
} | Select-Object PSComputerName, Build, SollKB, OOB, RDS | Sort-Object OOB | Format-Table -AutoSize

Überwachung: Den nächsten Ausfall früher sehen

Der Fehler zeigte sich erst nach Stunden. Wer die Ereignisse 7031 und 7034 des Dienststeuerungs-Managers im System-Protokoll für den Dienst TermService überwacht, erkennt solche Regressionen, bevor die Benutzer anrufen. Ergänzend lohnt ein Blick auf das Protokoll Microsoft-Windows-TerminalServices-LocalSessionManager/Operational.

Lehren für den Oktober-Patchday

Compliance-Bezug

Der BSI-Baustein OPS.1.1.3 (Patch- und Änderungsmanagement) verlangt, Updates vor dem Einsatz zu testen und eine Rückfallstrategie vorzuhalten. Ein dokumentierter Pilotring mit festen Wartezeiten erfüllt genau das – und ist gleichzeitig die beste Antwort auf NIS2 Art. 21 Abs. 2 lit. e, der Wartung und Schwachstellenbehandlung ausdrücklich nennt.

Fazit

Der akute Brand ist gelöscht, aber nicht überall. Vor dem 13. Oktober sollte jeder Server entweder das OOB-Update oder einen höheren Build haben, zurückgerollte Systeme müssen wieder auf Stand gebracht und KIR-Richtlinien aufgeräumt werden. Und für den nächsten Patchday gilt: Pilotring mit echten RDS-Hosts, Wartezeit einplanen, Dienste überwachen.