Der Terminalserver hängt nach dem Update — und der Rollback ist die teurere Hälfte der Wahl

/01Was seit dem 8. September passiert

Am 8. September 2026 hat Microsoft seinen bislang größten Patchday ausgeliefert. Je nach Zählweise stecken darin 964 Schwachstellen (Tenable) oder 966 (BleepingComputer), darunter zwei bereits aktiv ausgenutzte Rechteausweitungen, die die US-Behörde CISA umgehend in ihren KEV-Katalog aufgenommen hat. Für die meisten Windows Server-Landschaften war das ein Pflichtupdate ohne Diskussionsspielraum.

Zwei Tage später, am 10. September, häuften sich in Foren und auf Reddit Meldungen mit auffällig ähnlichem Wortlaut. Ein Administrator fasste es so zusammen: „Alle Terminalserver in unserer Umgebung fallen innerhalb eines Tages aus — Sitzungen brechen ab, neue Verbindungen sind nicht mehr möglich, hilft nur ein harter Neustart." Betroffen sind Sitzungshosts unter Windows Server 2019, 2022 und 2025; vereinzelt berichten Administratoren dasselbe von Server 2016.

Das Muster ist bemerkenswert gleichförmig:

• Verzögerter Beginn. Der Host läuft nach dem Neustart mehrere Stunden normal. Der Fehler zeigt sich erst, wenn Benutzer sich abzumelden beginnen.
• Neue Verbindungen bleiben hängen. Der Client zeigt „Verbindung wird hergestellt" und läuft schließlich in einen Zeitablauf.
• Bestehende Sitzungen kommen nicht heraus. Abmelden und Trennen quittieren nicht mehr.
• Die Verwaltung blockiert mit. Task-Manager, quser und die Einstellungen hängen auf der Konsole ebenfalls.
• Nur der harte Neustart hilft. Ein geordnetes Herunterfahren scheitert in vielen Fällen an genau den Sitzungen, die sich nicht beenden lassen.

Eine Fehlersuche, die BleepingComputer von einem Server-2022-Administrator zitiert, deutet auf eine Verklemmung: „Der Dienst hängt in RDPSERVERBASE!WDLIB_Close, dort scheint kein Zeitablauf gesetzt zu sein. Das Ergebnis ist ein Deadlock zwischen RDP und LSM." Der Local Session Manager ist der Dienst, der Sitzungen aufbaut, trennt und abräumt — hängt er, hängt alles, was eine Sitzungsliste braucht. Das erklärt, warum auch der Task-Manager stehen bleibt.

/02Die drei Updates — und die Zeile, die stutzig macht

Im Verdacht stehen drei kumulative Sicherheitsupdates vom selben Tag. Prüfen Sie zuerst, ob die Buildnummer Ihres Hosts überhaupt in diese Liste fällt — die Hälfte der Verdachtsfälle, die uns erreichen, liegt an etwas anderem.

Interessant wird es beim Blick in die Änderungsliste der KB-Artikel. Unter „Verbesserungen" steht in den Fassungen für Server 2022 und Server 2025 wortgleich: „This update improves Remote Desktop audio redirection, helping audio from remote sessions play correctly on the local device." Das Update, das die Remotedesktopdienste aus dem Tritt bringt, ist ausgerechnet dasjenige, das an der Audioumleitung der Remotedesktopdienste gearbeitet hat.

Das ist ein Indiz, kein Beweis. Es erklärt aber, warum in Foren als erste Gegenmaßnahme die Audioumleitung per Gruppenrichtlinie abgeschaltet wird (Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → Remotedesktopdienste → Remotedesktopsitzungs-Host → Geräte- und Ressourcenumleitung). Berichte darüber, ob das genügt, gehen auseinander. Ebenfalls im Umlauf ist ein Registrierungsschlüssel unterhalb von FeatureManagement, der den verdächtigen Codepfad abschalten soll. Solche Schlüssel sind nicht dokumentiert, nicht von Microsoft freigegeben und ändern Verhalten, das mit dem nächsten Update wieder anders aussehen kann — auf einem Produktionssystem ohne Momentaufnahme hat das nichts zu suchen.

Was in den KB-Artikeln nicht steht, ist ebenso wichtig: Der Abschnitt „Known issues in this update" nennt bei allen dreien nur einen unverbundenen WSUS-Fehler. Auch das Windows-Release-Health-Dashboard führte am 10.09.2026 um 17:02 PT für Server 2022 und Server 2025 lediglich eine irreführende Defender-Meldung. Microsoft bestätigt gegenüber der Presse, dem Thema nachzugehen, hat aber weder Ursache noch Abhilfe veröffentlicht.

/03Deinstallieren heißt: eine 9,8er-Lücke offenlassen

Der naheliegende Reflex — Update runter, Ruhe im Haus — hat einen Preis, der in den meisten Berichten untergeht. Der September-Patchday hat in den Remotedesktopdiensten mehrere Schwachstellen geschlossen. Die schwerste ist CVE-2026-69525: eine Codeausführung aus der Ferne über eine Speicherfehlnutzung nach dem Freigeben, CVSS 9,8, ohne vorherige Anmeldung ausnutzbar. Microsoft stuft sie als „Exploitation More Likely" ein. Daneben stehen vier weitere RDS-Schwachstellen mit CVSS 7,1 bis 7,5.

Wer das Sammelupdate entfernt, entfernt genau diese Korrekturen mit. Das ist keine theoretische Größe: Remotedesktopdienste sind seit Jahren eines der beliebtesten Einfallstore für Ransomware, gerade weil so viele Sitzungshosts direkt aus dem Internet erreichbar sind. Eine unauthentifizierte Codeausführung im genau dafür zuständigen Dienst ist die Sorte Lücke, um die sich Zugangsmakler innerhalb von Tagen kümmern.

Diese Frage lässt sich schnell beantworten. Steht der Sitzungshost hinter VPN oder einem Remotedesktopgateway mit Mehrfaktor-Anmeldung, ist die Lücke praktisch nur aus dem internen Netz erreichbar; ein befristeter Rückbau ist dann vertretbar. Antwortet Port 3389 dagegen aus dem offenen Internet, ist der Rückbau die schlechtere Wahl — und der eigentliche Befund ist ohnehin, dass dieser Port dort nichts zu suchen hat.

/04Known Issue Rollback greift hier nicht

An dieser Stelle hoffen erfahrene Administratoren auf Known Issue Rollback (KIR). Das Verfahren steckt seit Windows 10 2004 in den Updates selbst: Jede Änderung trägt einen Laufzeitschalter, und Microsoft kann einzelne Änderungen zurücknehmen, ohne das ganze Update zu entfernen. Für verwaltete Umgebungen erscheint dann eine Gruppenrichtlinienvorlage als MSI-Datei, die man verteilt, mit gpupdate /force zieht und mit einem Neustart scharf schaltet.

Für diesen Fall ist die Hoffnung aber unbegründet. Microsofts eigene Dokumentation stellt es unmissverständlich fest: „KIR only affects non-security updates and fixes. Security updates and fixes don't use KIR." Die Änderung an der Audioumleitung ist zwar für sich genommen eine Verbesserung, sie wird aber in einem Sicherheitsupdate ausgeliefert — und damit fällt der bequeme Schalter aus.

Praktisch heißt das: Die Abhilfe wird ein Update sein, kein Schalter. Ein Blick auf den letzten vergleichbaren Fall gibt die Größenordnung. Im Februar 2025 ließ KB5051987 Remotedesktopsitzungen unter Windows Server 2025 kurz nach dem Verbinden einfrieren; Maus und Tastatur reagierten nicht mehr. Für Windows 11 24H2 kam die Korrektur am 25. Februar 2025 mit KB5052093 — nach zwei Wochen. Für Windows Server 2025 dauerte es bis in den April und KB5055523. Wer heute plant, sollte mit mindestens zwei Wochen rechnen und sich nicht darauf verlassen, dass es beim Sitzungshost genauso schnell geht wie beim Arbeitsplatz.

/05Vier Ausgangslagen, vier Antworten

Eine allgemeingültige Empfehlung gibt es nicht — die richtige Entscheidung hängt an zwei Größen: wie erreichbar der Host ist und ob es einen zweiten gibt. Daraus ergeben sich vier Lagen.

Für alle vier Lagen gilt dasselbe Kleingedruckte: Halten Sie schriftlich fest, was Sie entschieden haben und warum. Wer unter NIS2 oder ISO 27001 fällt, braucht für ein bewusst zurückgehaltenes Sicherheitsupdate ohnehin eine Risikoabwägung mit Datum, Verantwortlichem und Wiedervorlage — und wer nicht darunter fällt, ist im Schadensfall gegenüber dem Versicherer trotzdem froh darüber.

/06Deinstallieren, aber sauber

Kumulative Updates lassen sich nicht mehr mit wusa /uninstall entfernen. Microsoft schreibt es in jedem KB-Artikel selbst: Das Paket enthält den Wartungsstapel mit, und der lässt sich nach der Installation nicht mehr zurücknehmen. Der unterstützte Weg führt über DISM — und über den Paketnamen, nicht über die KB-Nummer.

# 1) Aktuellen Stand festhalten, bevor irgendetwas passiert
systeminfo | findstr /B /C:"OS Version"
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5

# 2) Paketnamen zur KB-Nummer suchen (Beispiel Server 2022)
dism /online /get-packages /format:table | findstr 5122882

# 3) Sitzungen sauber leeren: keine neuen Anmeldungen, bestehende laufen weiter
change logon /drain
query user

# 4) Paket entfernen, Neustart selbst steuern
dism /online /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.5622.1.10 /norestart
shutdown /r /t 300 /c "RDS-Wartung: Rueckbau KB5122882"

# 5) Nach dem Neustart: Build gegenpruefen und Anmeldungen wieder freigeben
[System.Environment]::OSVersion.Version
change logon /enable

Drei Fallstricke, die in der Hektik regelmäßig zuschlagen:

• Der Paketname ändert sich je Build. Die Zeichenkette oben ist ein Beispiel, kein Rezept — nehmen Sie den Namen, den Schritt 2 auf Ihrem Host ausgibt.
• Ohne Sperre kommt das Update am nächsten Tag zurück. Bei WSUS ziehen Sie die Genehmigung zurück und setzen sie auf „Nicht genehmigt", in Intune pausieren Sie den Qualitätsupdate-Ring, und auf einem freistehenden Server hält sconfig die Updates an. Ein Host, der nachts erneut patcht, produziert denselben Ausfall noch einmal — nur diesmal ohne Ansage.
• Der Rückbau braucht ein Ablaufdatum. Tragen Sie den Termin ein, an dem Sie den Stand neu bewerten. Zwei Wochen sind ein realistischer erster Prüfpunkt.

Und der Hinweis, der alles einfacher macht, wenn er vorher befolgt wurde: Läuft der Sitzungshost als virtuelle Maschine unter Proxmox, Hyper-V oder VMware, ist die Momentaufnahme vor dem Patchen der schnellere Rückweg als jede DISM-Zeile — Minuten statt einer Stunde, und ohne die Frage, ob der Paketname stimmt.

/07Update behalten: Betrieb ohne Nachtschicht

Wenn der Rückbau ausscheidet — etwa weil der Host erreichbar ist oder weil die Änderung erst freigegeben werden müsste —, lässt sich der Betrieb trotzdem stabilisieren. Nicht schön, aber tragfähig, bis die Korrektur da ist.

• Geplanter Neustart, bevor es klemmt. Der Fehler zeigt sich Stunden nach dem Hochfahren. Ein nächtlicher Neustart um 03:00 Uhr verlegt den Ausfall in eine Zeit, in der er niemanden trifft. Bei starker Nutzung kann ein zweiter Neustart in der Mittagspause nötig sein — hässlich, aber besser als ein Vormittag ohne Arbeitsfähigkeit.
• Abmeldungen reduzieren. Berichte deuten darauf hin, dass die Verklemmung im Zusammenhang mit Abmeldevorgängen auftritt. Sitzungsgrenzwerte, die getrennte Sitzungen nach kurzer Zeit abräumen, erhöhen die Zahl der Abmeldungen — in dieser Lage ist es sinnvoller, getrennte Sitzungen länger stehen zu lassen und Sammelabmeldungen zu vermeiden.
• Audioumleitung abschalten. Der naheliegendste Verdacht lässt sich per Gruppenrichtlinie zentral ausschalten. Ob es reicht, ist offen; für eine Umgebung ohne Telefonie in der Sitzung kostet der Versuch nichts.
• Sitzungshost leeren statt abwürgen. change logon /drain hält neue Anmeldungen fern, lässt bestehende aber weiterarbeiten. In einer Farm nimmt der Verbindungsbroker den Host damit geordnet aus dem Verkehr — Nutzer landen beim nächsten Anmelden auf dem gesunden Host.
• Den harten Neustart vorbereiten, nicht improvisieren. Wer per iLO, iDRAC oder über die Oberfläche des Hypervisors ohnehin Zugriff hat, spart im Ernstfall zwanzig Minuten. Wer diesen Zugang erst sucht, während das Telefon klingelt, verliert sie.

/08Merken, bevor der erste Anruf kommt

Dieser Ausfall hat eine Eigenschaft, die klassische Überwachung aushebelt: Der Host bleibt scheinbar gesund. Er antwortet auf Ping, der Dienst lauscht weiter, der TCP-Handshake auf Port 3389 gelingt. Eine Prüfung, die nur fragt „ist der Port offen", meldet grün, während im Haus niemand mehr arbeiten kann. Genau dieser blinde Fleck sorgt dafür, dass der Ausfall in der Regel vom ersten Anrufer entdeckt wird und nicht vom Monitoring.

Was stattdessen trägt:

• Synthetische Anmeldung. Ein Dienstkonto meldet sich alle fünf Minuten tatsächlich an, prüft, dass eine Sitzung entsteht, und meldet sich wieder ab. Das ist der einzige Test, der genau den Vorgang prüft, der hier versagt.
• Sitzungsliste beobachten. query user beziehungsweise qwinsta über eine Abfrage, die nicht auf dem Host selbst läuft. Bleibt die Abfrage hängen oder wächst die Zahl der Sitzungen im Zustand „Getrennt" über Stunden an, ohne dass jemand abmeldet, ist das Muster da.
• Ereignisprotokoll auswerten. Die Kanäle Microsoft-Windows-TerminalServices-LocalSessionManager und -RemoteConnectionManager zeigen Verbindungsaufbau und Abmeldung. Das Ausbleiben erfolgreicher Anmeldungen während der Kernarbeitszeit ist ein besserer Alarm als jede Schwellwertmeldung auf Prozessorlast. Ein SIEM, das die RDS-Kanäle ohnehin einsammelt, braucht dafür nur eine zusätzliche Regel.
• Buildnummern im Bestand führen. Wenn die nächste Meldung dieser Art kommt, wollen Sie in zwei Minuten wissen, welche Hosts betroffen sind — nicht in zwei Stunden.

/09Damit der nächste Patchday kein Notfall wird

Dieser Vorfall ist kein Einzelfall: Seit Anfang 2025 sind allein zwei weitere Regressionen in den Remotedesktopdiensten dokumentiert — Februar 2025 das Einfrieren unter Server 2025, Januar bis März 2025 die Trennung nach 65 Sekunden bei UDP-Verbindungen von Windows 11 24H2 auf ältere Sitzungshosts. Wer einen Terminalserver betreibt, sollte Patch-Management nicht als monatliche Pflicht begreifen, sondern als Verfahren mit eingebautem Rückweg.

Vier Bausteine, die den Unterschied machen — keiner davon teuer:

• Ringe statt Stichtag. Ein Kanarienvogel-Host bekommt das Update am Patchday, der Rest drei bis sieben Tage später. Genau in diesem Fenster wurde der aktuelle Fehler öffentlich. Ein Ring hätte gereicht.
• Momentaufnahme vor dem Patchen. Bei virtualisierten Sitzungshosts ist der Rückweg damit eine Frage von Minuten. Die Aufnahme wird nach 48 Stunden ohne Befund wieder verworfen, damit keine Kette entsteht.
• N+1 bei den Sitzungshosts. Zwei kleinere Hosts hinter einem Verbindungsbroker sind in der Beschaffung kaum teurer als einer und ändern die Lage grundlegend: Ein defekter Host wird geleert, nicht diskutiert. Für die Bemessung von RTO ist das der wirksamste Hebel überhaupt.
• Rückweg aufschreiben. Ein Runbook mit den DISM-Schritten, dem Weg zur Fernkonsole und den Ansprechpartnern, gepflegt bevor es brennt. Der Unterschied zwischen zwanzig Minuten und drei Stunden MTTR liegt fast nie an der Technik.

Und die unbequeme Architekturfrage dahinter: Ein einzelner Terminalserver, an dem der gesamte Betrieb hängt, ist ein Einzelpunkt des Versagens — ganz gleich, wie gut gepflegt er ist. Microsoft kann ihn jeden zweiten Dienstag im Monat anfassen, und Sie erfahren es erst hinterher. Wer das nicht hinnehmen will, hat drei Wege: die Last auf mehrere Sitzungshosts verteilen, Arbeitsplätze in Gruppen mit unterschiedlichen Patchständen schneiden, oder den Weg über DaaS gehen, bei dem der Betreiber diese Staffelung mitbringt. Alle drei kosten Geld. Ein Tag Stillstand für dreißig Mitarbeiter kostet auch welches — nur unangekündigt.

/10Häufige Fragen