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

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“. Verfügbar nur im Microsoft Update Catalog.

Was heute zu tun ist

Der richtige Weg ist die Installation des Out-of-Band-Updates für die eigene Version. Vier Punkte sind dabei zu beachten:

• Es muss 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 von Hand in WSUS importiert oder per Configuration Manager oder Intune verteilt 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 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.

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. Seitdem kein Vorfall, aber der Beobachtungszeitraum ist noch zu kurz, um die Sache als erledigt zu betrachten. Vier Stunden später hat Microsoft das Out-of-Band-Update veröffentlicht: Der nächste Schritt ist, es im nächsten Wartungsfenster zu installieren und die Richtlinie zu entfernen.

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.