RDS-Probleme nach Windows Update – September 2026

Stand: 13. September 2026. Die Sicherheitsupdates vom 8. September 2026 legen in zahlreichen Umgebungen die Remote Desktop Services lahm. Microsoft hat das Problem inzwischen bestätigt und stellt einen Known Issue Rollback bereit. Dieser Beitrag zeigt, wie Sie betroffene Systeme erkennen, welche drei Handlungsoptionen es gibt – und warum ein Rollback des Updates gerade für Schweizer Unternehmen die schlechteste davon ist.

Kurzantwort

Die Windows-Sicherheitsupdates vom 8. September 2026 verursachen auf Windows Server 2012 bis 2025 sowie auf Windows 10 und 11 Ausfälle der Remote Desktop Services. Betroffene Terminalserver laufen nach dem Neustart zunächst normal und blockieren dann – meist nach der ersten Benutzerabmeldung – sämtliche neuen RDP-Verbindungen. Microsoft hat den Fehler am 11. September 2026 bestätigt (Status „Mitigated“) und stellt Known-Issue-Rollback-Gruppenrichtlinien bereit. Die empfohlene Massnahme ist die Aktivierung des passenden Known Issue Rollback, nicht die Deinstallation des Updates.

Betroffene Server-Updates: KB5122871 (Server 2025), KB5122882 (Server 2022), KB5122876 (Server 2019), KB5123099 (Server 2016), KB5123066 (Server 2012 R2), KB5123065 (Server 2012)
Erkennungsmerkmal: Event ID 20498, Winlogon-Event 6005, Dienst TermService im Status StopPending
Empfohlene Lösung: Known Issue Rollback per Gruppenrichtlinie, Sicherheitsupdates bleiben aktiv
Nicht empfohlen: Deinstallation des kumulativen Updates – sie öffnet 966 Schwachstellen erneut, darunter CVE-2026-69525 (CVSS 9.8) und zwei aktiv ausgenutzte Zero-Days

Stand: 13. September 2026. Dieser Beitrag wird aktualisiert, sobald Microsoft eine Korrektur ausliefert.

Was ist beim September-2026-Update passiert?

Nach der Installation der September-Updates laufen Terminalserver zunächst unauffällig. Typischerweise einige Stunden nach dem Neustart, oft ausgelöst durch die erste Benutzerabmeldung, kippt das System: Neue RDP-Verbindungen bleiben unbegrenzt am Anmeldebildschirm hängen und erzeugen Event ID 20498 im Log TerminalServices-RemoteConnectionManager mit dem Hinweis, dass die Remote Desktop Services zu lange für den Verbindungsaufbau benötigen. Bestehende Sitzungen lassen sich weder sauber trennen noch abmelden.

Microsoft beschreibt das Verhalten im Windows Release Health Dashboard zurückhaltend: In manchen Umgebungen werde RDS instabil, RDP-Verbindungen brechen nach einigen Minuten ab, es treten Anmeldeprobleme auf oder Server bleiben bei „Please wait for the Remote Desktop Configuration“ stehen. Auch Microsoft Management Console, RDS Licensing Diagnoser und der Datei-Explorer können nicht mehr reagieren, ebenso kann die Windows-Update-Seite dauerhaft einen Ladeindikator anzeigen.

In der Praxis ist der Befund gravierender, als diese Formulierung vermuten lässt. Ein regulärer Neustart bleibt in vielen Fällen selbst hängen; nur ein harter Reset stellt den Dienst wieder her – bis zum nächsten Mal.

Was ist die technische Ursache des RDS-Ausfalls?

Die Analyse stammt aus der Community, nicht von Microsoft. Ein Administrator führte Kernel-Debugging auf einem betroffenen Windows Server 2022 durch und lokalisierte die Routine RDPSERVERBASE!WDLIB_Close, die beim Abbau einer Sitzung aufgerufen wird. Bei aktivem internem Feature-Flag ruft diese Routine RtlWaitOnAddress ohne Timeout auf, wodurch der Thread unbegrenzt wartet. Da der Local Session Manager alle Änderungen am Sitzungsstatus über einen einzigen kritischen Abschnitt serialisiert, blockiert der hängende Thread sämtliche nachfolgenden Operationen – neue Verbindungen, Abmeldungen und Broker-Anfragen – bis der Host hart zurückgesetzt wird.

Der Zusammenhang mit der Audioumleitung ist plausibel: Microsoft weist in den Update-Beschreibungen selbst darauf hin, dass die Remote-Desktop-Audioumleitung verbessert wurde, damit Audio aus Remote-Sitzungen korrekt auf dem lokalen Gerät wiedergegeben wird. Das erklärt auch, weshalb nicht alle Umgebungen betroffen sind.

Welche Systeme und KB-Nummern sind betroffen?

Betroffen ist die gesamte unterstützte Windows-Produktfamilie und nicht nur Terminalserver. Die vollständige Liste der betroffenen Systeme findest du weiter oben im Verlauf.

Betroffene Windows-Server-Updates vom 8. September 2026

Windows Server 2025: KB5122871 (Message ID: WI1470785)
Windows Server 2022: KB5122882 (Message ID: WI1470786)
Windows Server 2019: KB5122876 (Message ID: WI1470787)
Windows Server 2016: KB5123099 (Message ID: WI1470788)
Windows Server 2012 R2: KB5123066 (Message ID: WI1470789)
Windows Server 2012: KB5123065 (Message ID: WI1470790)

Betroffene Windows-Client-Updates vom 8. September 2026

Windows 11, Version 26H1: KB5124012 (Message ID: WI1470779)
Windows 11, Version 25H2: KB5124008 (Message ID: WI1470780)
Windows 11, Version 24H2: KB5124008 (Message ID: WI1470781)
Windows 11, Version 23H2: KB5122880 (Message ID: WI1470782)
Windows 10, Version 22H2: KB5122878 (Message ID: WI1470783)
Windows 10, Version 21H2: KB5122878 (Message ID: WI1470784)
Windows 10 Enterprise LTSC 2019: KB5122876 (Message ID: WI1470787)
Windows 10 Enterprise LTSC 2016: KB5123099 (Message ID: WI1470788)

Microsoft führt im öffentlichen Dashboard-Eintrag nur KB5122871 für Windows Server 2025 als auslösendes Update auf. Faktisch betrifft der Defekt sämtliche September-Updates, die Änderungen am Remote-Desktop-Dienst enthalten – die Liste der Known-Issue-Rollback-Pakete für alle Plattformen bestätigt das.

Wichtig für die Fehlereingrenzung: Verwechseln Sie dieses Problem nicht mit dem separaten Known-Issue-Eintrag zu WSUS-Fehlerdetails, der ebenfalls auf den KB-Seiten steht. Der WSUS-Punkt bezieht sich auf eine Änderung im Zusammenhang mit der älteren Mitigation zu CVE-2025-59287 und ist vom RDP-Hang unabhängig.

Woran erkenne ich RDS-Probleme nach dem Windows Update?

Bevor Sie eingreifen, verifizieren Sie, dass es sich tatsächlich um diesen Defekt handelt und nicht um eine andere Störung. Drei Signale genügen.

1. Installierten Build prüfen

$cv = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
"$($cv.CurrentBuild).$($cv.UBR)"

Für Windows Server 2022 ist Build 20348.5622 betroffen, für Windows Server 2025 Build 26100.33438.

2. Ereignisprotokolle auf die bekannten Signaturen prüfen

# Event 20498 - Timeout beim RDP-Verbindungsaufbau
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin'
    Id      = 20498
} -MaxEvents 5 -ErrorAction SilentlyContinue |
    Format-Table TimeCreated, Message -Wrap

# Event 6005 - SessionEnv reagiert verzoegert auf Disconnect
Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-Winlogon'
    Id           = 6005
} -MaxEvents 5 -ErrorAction SilentlyContinue |
    Format-Table TimeCreated, Message -Wrap

3. Status des Dienstes TermService prüfen

Get-Service -Name TermService | Select-Object Name, Status

Ein Status von StopPending ist ein starker Hinweis darauf, dass der Deadlock bereits aktiv ist. Sind die Ereignisprotokolle sauber und läuft TermService normal, hat der Host die Bedingung entweder noch nicht ausgelöst oder ist nicht betroffen.

Nehmen Sie diese drei Abfragen in Ihr Monitoring auf. Der Defekt tritt verzögert auf – eine Prüfung unmittelbar nach dem Patchfenster übersieht ihn zuverlässig.

Der offizielle Workaround – und warum er in der Praxis nicht genügt

Auf der öffentlichen Learn-Seite nennt Microsoft bis heute nur eine einzige Gegenmassnahme: Ist eine virtuelle Maschine über RDP nicht mehr erreichbar, lässt sich die Konnektivität unter Umständen vorübergehend wiederherstellen, indem die betroffene VM angehalten (deallokiert) und neu gestartet wird.

Das ist für den Betrieb aus drei Gründen unbefriedigend:

Es handelt sich um einen harten Stromzyklus, nicht um eine Behebung. Der Defekt tritt nach der nächsten Abmeldewelle erneut auf.
Auf physischen Servern greift der Vorschlag gar nicht. Wer seine Terminalserver auf Blech oder in einem lokalen Hyper-V-Cluster betreibt, steht ohne dokumentierte Option da.
Er erzeugt ein Kommunikationsproblem. Benutzer, die bereits angemeldet sind, arbeiten in der Regel störungsfrei weiter – ausgesperrt sind nur diejenigen, die sich neu anmelden wollen. Ein erzwungener Neustart trifft also genau die Gruppe, die keine Probleme hat, während die andere ohnehin wartet.

Die brauchbare Antwort steht nicht auf der Learn-Seite, sondern im Windows-Release-Health-Bereich des Microsoft 365 Admin Centers. Dort sind seit dem 12. September 2026 Known-Issue-Rollback-Pakete für alle betroffenen Plattformen hinterlegt (Message-IDs WI1470779 bis WI1470790). Öffentlich sichtbar war dieser Stand zunächst nicht – ein guter Grund, das Admin Center im Störungsfall parallel zur Learn-Seite zu prüfen.

Wie behebe ich die RDS-Probleme? Drei Optionen im Vergleich

Entscheidungsmatrix zu den RDS-Problemen nach dem Windows Update vom September 2026

Option 1: Known Issue Rollback aktivieren (empfohlen)

Ein Known Issue Rollback ist ein von Microsoft bereitgestellter Mechanismus, der eine einzelne fehlerhafte Codeänderung aus einem Update gezielt zurücknimmt, ohne die enthaltenen Sicherheitskorrekturen anzutasten. Er wird auf verwalteten Unternehmensgeräten über eine spezielle Gruppenrichtlinienvorlage aktiviert.

Die Pakete sind plattformspezifisch benannt:

Achten Sie darauf, exakt das Paket zur jeweiligen Betriebssystemversion zu verwenden. Ein für Server 2022 gedachtes Paket wirkt auf einem Server 2025 nicht.

Vorgehen in vier Schritten

MSI installieren. Das passende Paket aus dem Release-Health-Eintrag herunterladen und auf einem System mit der Gruppenrichtlinien-Verwaltungskonsole installieren. Das Paket liefert lediglich ADMX- und ADML-Dateien; es verändert selbst nichts an der Konfiguration.
Richtlinie konfigurieren. Die neue Richtlinie unter Computerkonfiguration > Administrative Vorlagen suchen und explizit konfigurieren – „Nicht konfiguriert“ hat keine Wirkung. Rückmeldungen aus produktiven RDS-Farmen deuten darauf hin, dass die Richtlinie auf „Deaktiviert“ gesetzt werden muss, damit der Rollback greift.
Verknüpfen und neu starten. Die Richtlinie auf die OU mit Ihren Session Hosts verknüpfen und einen Neustart der Zielsysteme einplanen. KIR-Richtlinien werden beim Systemstart ausgewertet; ein gpupdate /force allein genügt in der Regel nicht.
Verifizieren. Auf einem Pilot-Host 24 bis 48 Stunden gegen die Event-IDs 20498 und 6005 prüfen, bevor Sie breit ausrollen.

Option 2: Registry-Override des Feature-Flags (nicht empfohlen)

In der Microsoft Community kursiert ein Override, der das verantwortliche Feature-Flag direkt unter HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides deaktiviert. Der Ansatz hat die Lücke zwischen Bekanntwerden des Defekts und Microsofts Known Issue Rollback überbrückt und funktioniert nach Anwenderberichten.

Wir raten davon ab, solange der offizielle Known Issue Rollback verfügbar ist. Die Gründe:

Das Flag ist von Microsoft nicht dokumentiert. Ob es weitere, bislang unbeobachtete Codepfade steuert, lässt sich nicht verlässlich beurteilen – ein Einwand, den auch der Urheber der ursprünglichen Analyse erhoben hat.
Die Schlüssel unterliegen dem TrustedInstaller. Automatisierte Deployments laufen ohne zusätzliche Massnahmen in Berechtigungsfehler.
Zur korrekten Wertbelegung existieren widersprüchliche Angaben. Diskutiert wird insbesondere, ob EnabledState auf 1 oder auf 0 zu setzen ist. Eine falsch gesetzte Override lässt den Defekt bestehen, ohne dass dies sofort auffällt.
Der Vergleich mit den Registry-Schlüsseln, die der offizielle Known Issue Rollback setzt, deckt Abweichungen auf. Der kursierende Override bildet die von Microsoft vorgesehene Mitigation also nicht eins zu eins nach.

Falls Sie den Weg dennoch benötigen, exportieren Sie den bestehenden Overrides-Schlüssel vorab als Rollback-Basis und testen Sie auf einem einzelnen Host.

Option 3: Deinstallation des kumulativen Updates (letzte Instanz)

Diese Lösung wird aktuell häufig empfohlen, ist jedoch nur als letzter Ausweg gedacht. Sie stellt die Funktion von RDS in der Regel wieder her, entfernt aber auch die Sicherheitskorrekturen des Updates.

Wichtig: Die Deinstallation über wusa /uninstall funktioniert bei den September-Updates nicht, da diese zusammen mit dem Servicing Stack Update (SSU) ausgeliefert werden. Die Entfernung muss daher mittels DISM erfolgen. Der SSU-Anteil bleibt dabei bestehen, was normal ist.

Anschliessend sollte die betreffende KB in WSUS abgelehnt oder per Gruppenrichtlinie zurückgestellt werden. Andernfalls wird das Update beim nächsten Wartungsfenster erneut installiert.

Diese Variante sollte nur bei Systemen verwendet werden, die bereits festhängen oder nicht mehr remote erreichbar sind. In solchen Fällen bleibt oft keine Zeit mehr, um einen Known Issue Rollback (KIR) auszurollen.

Empfohlenes Vorgehen im Überblick

Inventarisieren. Alle Systeme mit installiertem September-CU und aktiviertem Remote Desktop erfassen – auch Einzelserver und Clients, nicht nur Session-Host-Farmen.
Known Issue Rollback ausrollen. Auf einem Pilot-Host verifizieren, danach flächendeckend auf alle RDS-Rollen inklusive Connection Broker und Gateway.
Verifizieren. Über 48 Stunden hinweg auf Event 20498, Winlogon 6005 und den Status von TermService prüfen, insbesondere rund um Abmeldezeiten am Feierabend.
Nachführen. Microsoft arbeitet an einer Korrektur in einem künftigen Windows-Update. Sobald diese verfügbar ist, KIR-Richtlinie wieder entfernen, sonst bleibt die zugrunde liegende Funktion dauerhaft deaktiviert.

Häufige Fragen zu den RDS-Problemen nach dem Windows Update

Sind auch Azure Virtual Desktop und Windows 365 betroffen?

Massgeblich ist das Gastbetriebssystem. Session Hosts mit einem betroffenen Windows-Build und installiertem September-2026-Update können denselben Defekt zeigen. Prüfen Sie Ihre Images und Host Pools mit denselben drei Signalen: Build-Nummer, Event 20498 und Status von TermService.

Reicht es, die Audioumleitung per Gruppenrichtlinie zu deaktivieren?

Der Gedanke liegt nahe, weil das September-Update genau an der Audioumleitung angesetzt hat. Auf reinen Anwendungs- oder Verwaltungsservern, auf denen Audio ohnehin keinen Zweck erfüllt, ist die Deaktivierung unbedenklich und einen Versuch wert. Auf Terminalservern ist Remote-Audio dagegen häufig fachlich erforderlich – etwa für Telefonie-Integrationen, Schulungsinhalte oder Warnsignale aus Fachanwendungen. Eine Bestätigung durch Microsoft gibt es nicht. Der Known Issue Rollback ist der belastbarere Weg, weil er die konkrete fehlerhafte Codeänderung zurücknimmt statt eine ganze Funktion abzuschalten.

Wie lange dauert es bis zum offiziellen Fix?

Microsoft nennt kein Datum und verweist auf ein künftiges Windows-Update. Planen Sie mit dem Oktober-Patchday 2026 und behalten Sie das Windows Release Health Dashboard im Blick.

Sollten wir das September-Update jetzt zurückstellen?

Nein. Rollen Sie es aus und aktivieren Sie den Known Issue Rollback im selben Wartungsfenster. Ein Zurückstellen belässt kritische, aktiv ausgenutzte Schwachstellen offen – darunter eine Remote-Code-Execution-Lücke in den Remote Desktop Services mit CVSS 9.8.

Betrifft das Problem nur Windows Server?

Nein. Microsoft listet auch Windows-10- und Windows-11-Clients als betroffen. Relevant wird das überall dort, wo Remote Desktop auf Arbeitsstationen für Support oder Fernzugriff aktiviert ist.

Was ist ein Known Issue Rollback?

Ein Known Issue Rollback ist ein Microsoft-Mechanismus, mit dem eine einzelne fehlerhafte Änderung aus einem Windows-Update zurückgenommen wird, während alle übrigen Korrekturen des Updates – insbesondere die Sicherheitsupdates – aktiv bleiben. Auf verwalteten Unternehmensgeräten erfolgt die Aktivierung über eine spezielle Gruppenrichtlinienvorlage, die Microsoft als MSI-Paket bereitstellt.

👉Unterstützung benötigt?

Die vistasys AG betreut Schweizer KMU und Enterprise-Kunden in den Bereichen Microsoft 365, Azure und Modern Workplace. Wir unterstützen Sie beim Ausrollen des Known Issue Rollback, bei der Absicherung Ihrer RDS-Umgebung und bei der Evaluation einer Migration nach Azure Virtual Desktop oder Windows 365.

Kontakt aufnehmen

Quellen

Microsoft, Windows Release Health: „Remote Desktop Services might stop responding after Sept. 2026 security update„, Status „Mitigated“, Stand 11. September 2026
Microsoft 365 Admin Center, Windows Release Health, Message-IDs WI1470779 bis WI1470790 (Known-Issue-Rollback-Gruppenrichtlinienpakete)
Microsoft Learn, „Known Issue Rollback„: Aktivierungsprozess für verwaltete Unternehmensgeräte
Microsoft Security Response Center: CVE-2026-69525, CVE-2026-81963, CVE-2026-85880
Borns IT- und Windows-Blog: „Windows: Remote Desktop Services (RDS)-Probleme durch Sept. 2026-Update bestätigt„, 12. September 2026
BleepingComputer, Berichterstattung vom 10. September 2026
Community-Analyse zur Deadlock-Ursache in RDPSERVERBASE!WDLIB_Close (r/sysadmin)