Remotedesktop hängt
nach den September-Patches: der Fix

Aktualisiert am 14. Oktober 2026

Das Symptom

Der Sessionhost läuft einige Stunden normal, dann nimmt er keine neuen Verbindungen mehr an. Offene Sitzungen lassen sich nicht schließen, qwinsta antwortet nicht und die Verwaltungswerkzeuge bleiben hängen. Microsoft beschreibt dieselben Effekte: RDP-Verbindungen, die nach einigen Minuten fehlschlagen, Anmeldungen, die nicht zustande kommen, Server, die bei „Warten auf die Remotedesktopkonfiguration“ stehen bleiben, Microsoft Management Console, RDS Licensing Diagnoser und Explorer, die nicht mehr reagieren, sowie eine Windows-Update-Seite, die endlos lädt.

Das Detail, das für jeden Betreiber einer Produktionsumgebung zählt: Der Fehler wird durch das Schließen von Sitzungen ausgelöst. Er zeigt sich also während der Arbeitszeit, wenn sich Benutzer an- und abmelden, und nicht in Leerlaufphasen. Ein Server, der die Nacht ruhig übersteht, kann am selben Arbeitstag zweimal hängen bleiben.

Die Ursache und der zeitliche Ablauf

Es handelt sich um eine Regression, die die kumulativen Sicherheitsupdates vom 8. September 2026, dem Patchday des Monats, eingeführt haben. Betroffen sind alle unterstützten Windows-Server-Versionen sowie Windows-10- und Windows-11-Clients mit aktiviertem Remotedesktop. Die Abfolge der folgenden Tage erklärt, warum viele Administratoren fast eine Woche ohne saubere Lösung dastanden.

• 18. September. Die kumulativen Updates erscheinen. Innerhalb weniger Stunden bleiben die ersten Sessionhosts hängen.
• 211. September, abends. Microsoft eröffnet das bekannte Problem auf Windows release health mit dem Status „Mitigated“. Die genannte Abhilfe lautet: virtuelle Maschine freigeben und neu starten, keine Korrektur, sondern ein Weg, ein paar Stunden zu gewinnen. Am selben Tag wird der Known Issue Rollback paketiert, erkennbar am Zeitstempel im Dateinamen, aber weder auf der KB-Seite noch im Dashboard verlinkt. Wir haben ihn über das Citrix-Advisory CTX697101 gefunden.
• 314. September, 19:00 Uhr MESZ. Microsoft veröffentlicht die Out-of-Band-Updates und setzt das Problem auf „Resolved“. Für Windows Server nur im Microsoft Update Catalog verfügbar, für Windows 11 24H2, 25H2 und 26H1 auch über Windows Update und WSUS. Dasselbe Out-of-Band-Update behebt außerdem einen Hyper-V-Fehler bei für Linux-VMs freigegebenen Ordnern und, nur teilweise, einen bei mehrkanaligen USB-Audiogeräten.
• 422. September. Die optionalen Vorschau-Updates für Windows 11 erscheinen (KB5124010 für 24H2, 25H2 und 26H2, KB5124006 für 26H1): Sie sind kumulativ und enthalten die Korrektur bereits. Für Windows Server erscheint nichts Neues.
• 513. Oktober. Patchday im Oktober: Die kumulativen Updates KB5126646 (Server 2025), KB5126655 (Server 2022), KB5126651 (Server 2019) und KB5126868 (Server 2016) enthalten die Korrektur und kommen über Windows Update und WSUS; in den KB-Artikeln kein bekanntes Problem mit Remotedesktop. Für Windows Server 2022 ist es zugleich das letzte Update im allgemeinen Support.

Was heute zu tun ist

Der richtige Weg ist die Installation des kumulativen Updates vom 13. Oktober, das die Korrektur enthält und über Windows Update und WSUS kommt; wer nicht auf den Monatszyklus warten kann, installiert das Out-of-Band-Update für die eigene Version. Vier Punkte sind dabei zu beachten:

• Auf Servern muss es im Microsoft Update Catalog gesucht werden, mit der KB-Nummer aus der Tabelle oben: Windows Update bietet es nicht an und WSUS synchronisiert es nicht, in verwalteten Umgebungen muss es also von Hand in WSUS importiert oder per Configuration Manager oder Intune verteilt werden. Auf Windows-11-Clients 24H2, 25H2 und 26H1 kommt es wie jedes andere Update über Windows Update und WSUS; auf 23H2 muss es unter den optionalen Updates von Windows Update installiert oder aus dem Catalog importiert werden.
• Es ist kumulativ. Es enthält alle Sicherheitskorrekturen des September-Patchdays plus den aktualisierten Servicing Stack. Wer das Update vom 8. September noch nicht installiert hat, kann direkt das Out-of-Band-Update installieren und den fehlerhaften Schritt überspringen.
• Ist der Known Issue Rollback bereits aktiv, bestätigt Microsoft, dass vor der Installation nichts zu tun ist. Nach dem Neustart die Richtlinie auf Nicht konfiguriert zurücksetzen und das MSI entfernen: KIR-Definitionen haben eine begrenzte Lebensdauer und gehören nicht dauerhaft in die Richtlinien.
• Neu starten und mit echten Benutzern prüfen. Der Fehler wird durch das Schließen von Sitzungen ausgelöst: Auf einer ruhenden Maschine tritt er nicht auf, ein Server, der die Nacht durchhält, beweist also nichts. Es braucht einen vollen Arbeitstag.

Wenn der Server bereits hängt

Eine hängende Maschine nimmt nicht einmal Verbindungen von Administratoren an: Der Remotedesktopdienst antwortet niemandem, die administrative Sitzung eingeschlossen. Per RDP aus der Ferne lässt sich das nicht lösen.

• 1Über die Konsole anmelden. Die Konsole der virtuellen Maschine in Hyper-V, VMware oder Proxmox; die serielle Konsole oder ein Neustart über das Portal bei einer Maschine in Azure; die Fernwartungskonsole des Servers (iLO, iDRAC, IPMI) bei einem physischen Server.
• 2Die Maschine neu starten. Der Neustart entsperrt sie, behebt den Fehler aber nicht.
• 3Direkt danach den Patch installieren. Bevor die Benutzer sich wieder anmelden, das Out-of-Band-Update installieren oder, falls das nicht geht, den weiter unten beschriebenen Known Issue Rollback anwenden. Ohne Korrektur kommt der Hänger mit der ersten Reihe geschlossener Sitzungen zurück.

Wenn die Installation hängengeblieben wirkt

Auf Servern ist das Paket schwer: für Windows Server 2022 sind es rund 560 MB, weil es neben dem kumulativen Update das Servicing Stack Update KB5122881 enthält. Als MSU aus dem Catalog installiert arbeitet es lange, bevor es Fortschritte zeigt, und beim Neustart durchläuft es mehrere Phasen „Updates werden bearbeitet“, in denen die Prozentanzeige minutenlang stillsteht. Das ist das normale Verhalten eines Pakets aus Servicing Stack und kumulativem Update, kein Hänger.

Um zu erfahren, ob es noch arbeitet, öffnen Sie eine zweite Sitzung und verfolgen das Protokoll des Component Based Servicing: Schreibt es, läuft die Installation weiter.

Get-Content C:\Windows\Logs\CBS\CBS.log -Tail 20 -Wait

Ein zweites Signal ist die CPU-Last der Prozesse TiWorker und TrustedInstaller. Von einem echten Problem ist erst auszugehen, wenn das Protokoll eine halbe Stunde stillsteht und diese Prozesse bei null liegen. In der Zwischenzeit das Installationsfenster nicht schließen, keinen Neustart erzwingen und die Maschine nicht ausschalten: Ein Servicing Stack Update mitten in der Installation abzubrechen ist der schnellste Weg zu einem reparaturbedürftigen Component Store.

Nach dem Neustart prüfen, ob der richtige Build erreicht ist. Auf Windows Server 2022 müssen 20348 und 5631 zu lesen sein.

(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion') |
  Select-Object CurrentBuild, UBR

Wenn das Out-of-Band-Update nicht sofort geht: der Known Issue Rollback

Der Known Issue Rollback (KIR) ist der Mechanismus, mit dem Microsoft eine einzelne fehlerhafte Änderung abschaltet, ohne das Update zu deinstallieren, das mit all seinen Sicherheitskorrekturen produktiv bleibt. Für Unternehmen kommt er als MSI-Paket, das eine Gruppenrichtlinie hinzufügt. Er ist die richtige Wahl, wenn das Out-of-Band-Update ein Wartungsfenster oder einen Testzyklus durchlaufen muss und der Server in der Zwischenzeit laufen soll. Für Windows Server 2022 heißt das Paket KB5122882_260911_1847_1_KnownIssueRollback.msi.

• 1Paket für die eigene Version herunterladen und die Signatur prüfen, bevor es installiert wird. Das Ergebnis muss Valid mit dem Unterzeichner CN=Microsoft Corporation lauten; andernfalls nicht installieren.

Get-AuthenticodeSignature .\KB5122882_260911_1847_1_KnownIssueRollback.msi | fl Status, SignerCertificate

• 2Das MSI installieren. Es ändert nichts am System: Es kopiert lediglich die ADMX- und ADML-Dateien nach C:\Windows\PolicyDefinitions. Wer einen Central Store für Domänenrichtlinien nutzt, kopiert die beiden Dateien dorthin.
• 3Die Richtlinie auf Deaktiviert setzen. Den lokalen Gruppenrichtlinien-Editor öffnen oder das Domänen-GPO anlegen und unter Computerkonfiguration, Administrative Vorlagen den Eintrag des Known Issue Rollback mit der KB-Nummer suchen. Er muss auf Deaktiviert stehen, nicht auf Aktiviert: Die Richtlinie zu deaktivieren heißt, die fehlerhafte Änderung zu deaktivieren, also den Rollback auszuführen. Zu diesem Punkt kursieren falsche Anleitungen.
• 4Neu starten. Ohne Neustart wird die Änderung nicht wirksam.

Alternative ohne MSI, mit einer Warnung

Die Richtlinie schreibt lediglich einen DWORD-Wert in die Registrierung. Man kann ihn direkt schreiben, aber nur auf Windows Server 2022 Build 20348.5622, weil sich die numerische Kennung des Override von Build zu Build ändert:

$k = 'HKLM:\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides'
New-ItemProperty -Path $k -Name '1300465806' -Value 0 -PropertyType DWord -Force

Danach neu starten. Auf jedem anderen Build das MSI installieren und die Kennung in der passenden ADMX-Datei nachlesen, statt die hier gezeigte zu kopieren. Die in Foren kursierende Kennung 1501792398 ist nicht die von Server 2022.

Prüfung und Rollback

Nach dem Neustart muss der Wert unter dem Schlüssel FeatureManagement\Overrides vorhanden sein. Der Wirksamkeitstest ist aber ein anderer: Er verlangt einen vollen Arbeitstag mit echten Benutzern, die Sitzungen öffnen und schließen. Auf einer ruhenden Maschine wird der Fehler nicht ausgelöst und das Ergebnis sagt nichts aus.

Für den Rückweg genügt es, den Registrierungswert zu löschen oder die Richtlinie auf Nicht konfiguriert zurückzusetzen und neu zu starten. Das ist auch der Schritt, den man in Ruhe nach der Installation des Out-of-Band-Updates ausführt.

Weitere offene Probleme vom September

Die September-Updates haben weitere bekannte Probleme, die noch offen sind und die Microsoft auch in den Artikeln zu den Out-of-Band-Updates aufführt. Sie sind nicht der Remotedesktop-Hänger, können aber damit verwechselt werden:

• Schwarzer Bildschirm nach der Anmeldung auf Azure Virtual Desktop mit FSLogix. Betrifft Windows 11 24H2, 25H2, 26H1 und 26H2 ab der Vorschau vom 27. August (KB5120998); am 25. September eröffnet, von Microsoft mit einem eigenen Known Issue Rollback entschärft. Ein anderes Problem als dieses.
• USB-Audio. Seit dem 25. September betrachtet Microsoft den Fehler bei USB-Audio-Class-1.0-Geräten nur als teilweise behoben: Das Out-of-Band-Update hat mehrkanaliges Audio korrigiert, aber Code-10-Fehler, fehlender Ton und nicht reagierende Lautstärkeeinstellungen bleiben, auf Clients und Servern.
• Dateiversionsverlauf. Kann aufhören zu funktionieren und verlangt, das Laufwerk erneut zu verbinden. Eine Korrektur gibt es noch nicht.
• Credential Guard. Kann auf Windows 11 24H2 und neuer die Vertrauensstellung zur Domäne unterbrechen; Microsoft nennt eine Umgehung über Registrierung oder Richtlinien und die Reparatur des sicheren Kanals. Server sind nicht betroffen.

Aus der Praxis

Wir haben den Known Issue Rollback am 14. September um 15:02 Uhr auf einem Windows-Server-2022-Sessionhost angewendet, der zweimal täglich mitten in der Arbeitszeit hängen blieb. Stand 17. September, nach drei vollen Arbeitstagen mit Benutzern, die sich an- und abmelden, ist kein einziger Hänger mehr aufgetreten: Bei einer Maschine, die zweimal täglich stehen blieb, ist das ein belastbarer Befund, kein Eindruck. Vier Stunden nach der Anwendung hat Microsoft das Out-of-Band-Update veröffentlicht, das wir gerade auf den betroffenen Servern installieren: Wo die Richtlinie aktiv ist, wird zuerst das Update installiert und die Richtlinie nach dem Neustart entfernt.

Das Detail, das in keiner Anleitung steht: Das Paket arbeitet sehr lange, bevor es überhaupt Fortschritte zeigt, und das Protokoll des Component Based Servicing ist der einzige verlässliche Weg, eine langsame Installation von einer hängenden zu unterscheiden. Es lohnt sich, es zu öffnen, bevor man sich Sorgen macht.

Die Lehre für alle, die virtualisierte Server und Remotedesktop-Umgebungen betreiben, ist immer dieselbe: Der Patchday muss installiert werden, aber mit Beobachtungsfenster und vorab bereitem Rollback-Plan. Genau dafür gibt es den KIR, sofern man weiß, wo er zu finden ist und wie er aktiviert wird. Es ist die Art von Arbeit, die wir mit unserem Service Support und Operations abdecken.