Dein Patchtest hat die Sitzung offen gelassen

Der Testserver lief drei Tage mit dem kumulativen Windows-Update von Microsoft vom 8. September 2026. Keine Auffälligkeit. Also ging das Update in die Fläche.

Vier Stunden später nahmen die Session-Hosts keine Verbindungen mehr an.

Das ist keine erfundene Geschichte, das war im September 2026 und es ist in sehr vielen Umgebungen sehr ähnlich abgelaufen. Der reflexartige Ruf danach lautet fast immer: „Wir brauchen eine bessere Testumgebung“ oder „Wir brauchen saubere Stages oder eine DTAP-Umgebung.“

Beides hätte nicht geholfen.

Was wirklich schiefging

Betroffen waren die kumulativen Updates vom 8. September 2026 für Windows Server 2016 bis 2025, etwa KB5122882 für Windows Server 2022. Der Fehler saß in den Remotedesktopdiensten von Windows, nicht in Citrix. Microsoft hat am 14. September mit Out-of-Band-Updates nachgeliefert. Für Windows Server 2022 war es KB5129237.

Der Fehler ließ beim Abbau einer Sitzung einen Thread unbegrenzt warten. Weil alle Sitzungswechsel eines Hosts durch einen einzigen Engpass laufen, den Local Session Manager, stand ab diesem Moment alles: Neue Anmeldungen, Abmeldungen, jede Anfrage des Brokers. (Ursachenanalyse aus der Fachpresse, von Microsoft nicht bestätigt.) Alle KB-Nummern je Windows-Version stehen im Beitrag Windows-Update September 2026: RDS hängt, „Citrix bleibt schwarz“.

Entscheidend ist die Bedingung: Der Fehler brauchte eine getrennte Sitzung, um sich zu zeigen.

Und jetzt schauen wir uns einmal an, wie ein Patchtest üblicherweise abläuft:

1. Update auf den Testserver
2. Neustart
3. Per RDP verbinden
4. Schauen, ob die Anwendung startet
5. Fenster stehen lassen und mit anderen Dingen weitermachen
6. Am nächsten Tag: läuft noch, also freigeben

Schritt 5 ist der Punkt. Die Sitzung blieb offen. Es gab nie einen Abbau. Der Fehler konnte gar nicht auftreten.

Das war keine Nachlässigkeit. Das ist genau das Verhalten, das man von einem sorgfältigen Test erwartet, denn er hat den Server ja tagelang beobachtet.

Der Test hat den Zustand geprüft, nicht den Übergang.

Und der Fehler saß im Übergang.

Der allgemeine Fall

Die mit dem September-Update aufgetretenen Probleme sind ein Beispiel, aber leider kein Sonderfall. Die Regel dahinter ist älter und trifft immer wieder:

Eine Testumgebung bildet die Konfiguration ab. Sie bildet die Nutzung nicht ab.

Konfiguration ist einfach zu kopieren: dieselbe Betriebssystemversion, dieselben Rollen, dieselben Richtlinien, dieselbe Software. Das machen die meisten gut.

Nutzung ist schwer zu kopieren und wird deshalb übersprungen:

In Produktion passiert	In der Testumgebung meist nicht
Sitzungen werden getrennt und wiederaufgenommen	eine Sitzung bleibt offen oder wird einfach geschlossen (fire and forget).
Nutzer melden sich ab	niemand meldet sich ab, wenn doch, prüft niemand eine Neuanmeldung
Dienste werden neu gestartet	läuft seit dem Neustart durch
Profile werden geladen und zurückgeschrieben	Profile werden geladen und zurückgeschrieben, selten das Ergebnis überprüft
Hunderte Anmeldungen gleichzeitig morgens um 8	eine Anmeldung, irgendwann im Laufe des Tages
Zertifikate laufen ab, Tickets werden erneuert	alles frisch
Nach Tagen Speicherfragmentierung	nach Stunden freigegeben

Fehler, die im Dauerbetrieb sichtbar werden, findet ein Test, der nur den Dauerbetrieb prüft. Fehler, die beim Zustandswechsel sichtbar werden, findet nur ein Test, der Zustände wechselt.

Und die zweite Sorte ist die gefährlichere, weil sie sich im Test so zuverlässig versteckt.

Warum eine weitere Stage das nicht löst

Jetzt zum verbreitetsten Missverständnis.

DTAP ist richtig. Development, Test, Acceptance, Production: Jede Stage fängt ab, was die vorige durchgelassen hat, und wenn etwas schiefgeht, trifft es weniger Leute.

Stages begrenzen den Schaden. Sie erhöhen nicht die Entdeckungswahrscheinlichkeit.

Das ist der Punkt, der gern übersehen wird. Wenn in T und A auf dieselbe Weise gearbeitet wird wie vorher, hat Acceptance denselben blinden Fleck wie Test. Du findest den Fehler nicht früher, du findest ihn später und mit mehr Maschinen.

	Was Stages leisten	Was sie nicht leisten
Schadensbegrenzung	✅ weniger Systeme betroffen
Zeitgewinn	✅ Abstand zwischen den Wellen
Entdeckung		❌ nur, wenn in T und A anders gearbeitet wird als in D

Bei vielen von euch ist das Testsystem ein Server ohne Nutzer, vielleicht mit wenigen, und Acceptance besteht daraus, dass zwei Administratoren kurz hineingeschaut haben. Beide hatten denselben blinden Fleck. Die erste Stelle, an der es auffiel, war die erste mit echten Nutzern, die abends nach Hause gingen, es am nächsten Morgen nochmals probieren und das war in vielen Umgebungen schon die Produktion.

Acceptance ohne echte Abmeldungen ist keine Acceptance. Es ist eine zweite Testumgebung mit einem anderen Namen.

Daraus folgt eine unbequeme Empfehlung: Acceptance gehört nicht in ein Labor, sondern zu Menschen. Eine kleine, gutmütige Abteilung, die morgens anmeldet und abends abmeldet, findet mehr als ein perfekt nachgebauter Server, an dem niemand arbeitet.

Die Zustandswechsel-Prüfung

Was stattdessen hilft, kostet fünfzehn Minuten und braucht keine neue Infrastruktur. Statt den Server zu beobachten, zwingst du ihn durch die Übergänge, die in Produktion vorkommen.

Für Sitzungshosts mit Microsoft RDS oder Citrix Virtual Apps and Desktops, aus dem September-Update-Fall abgeleitet:

#	Schritt	Warum
1	Update einspielen, neu starten	Ausgangszustand
2	Sitzung A aufbauen	der übliche Test, bis hierhin kommen alle
3	Sitzung A trennen (nicht abmelden!)	der Übergang, der im September fehlte
4	Sitzung B aufbauen	prüft, ob der Host nach dem Trennen noch annimmt
5	Sitzung A wiederaufnehmen	prüft den Rückweg
6	Sitzung A sauber abmelden	ein anderer Übergang als Trennen
7	30 bis 60 Minuten warten, dann Sitzung C	zeigt schleichende Blockaden
8	Protokolle durchsehen	das Vorzeichen steht dort vor dem Vollbild

Schritt 3 und Schritt 7 sind die, die etwas finden. Alles andere ist Beiwerk.

Und Schritt 8 ist der, den man sich schenkt, weil ja alles läuft. Genau da steht der Hinweis zuerst. Der Fehler kündigte sich lange im Systemprotokoll an, bevor jemand etwas merkte: Winlogon, Ereignis 6005, Abonnent SessionEnv, Ereignis Disconnect.

Das Prinzip ohne Terminalserver

Dieselbe Frage lässt sich für jede Rolle stellen. Sie lautet immer:

Welcher Übergang passiert in Produktion ständig, und in meinem Test kein einziges Mal?

Rolle	Der Übergang, der im Test fehlt
Sitzungshosts	Sitzung trennen, wiederaufnehmen, abmelden
Dateidienste	Profil zurückschreiben, Sperre freigeben
Reverse Proxy / Gateway	Sitzung läuft ab, Wiederanmeldung, Neuaushandlung
Datenbanken	Sicherung läuft, Protokoll wird abgeschnitten
Alles mit Zertifikaten	Erneuerung, Sperrprüfung, abgelaufene Kette

Man braucht die Liste nicht vollständig. Es reicht, sie einmal für die bekannten Stellen aufzuschreiben und daraus eine Teststrategie abzuleiten. Das ist eine langfristige Geschichte.

Womit du das automatisierst

Ungefähr acht Schritte von Hand sind der Einstieg. Wer sie vor jedem Patchday braucht, automatisiert sie. Die Werkzeugklasse dafür heißt Logon-Simulation oder synthetisches Monitoring: Ein künstlicher Nutzer meldet sich an, arbeitet, trennt und meldet sich wieder ab. Das geht nach Zeitplan und mit Messwerten.

Bei der Auswahl gibt es genau eine Frage, die zählt:

Meldet sich der künstliche Nutzer wirklich wieder ab oder prüft das Werkzeug nur, ob eine Anmeldung klappt?

Ein Werkzeug, das nur anmeldet, hat denselben blinden Fleck wie dein Test. Es kostet dann Geld und findet den Fehler trotzdem nicht.

Diese Frage trennt das Feld sauber, und zwar quer durch alle Preisklassen.

Wo das im DTAP-Ablauf sitzt

Die Simulation gehört nach Test und vor Acceptance, und sie läuft danach in Production weiter. Dann hast du zweierlei: Eine Freigabeentscheidung mit Messwerten statt mit Bauchgefühl und eine Baseline, gegen die sich der nächste Patchday vergleichen lässt.

Was davon passt, hängt weniger am Funktionsumfang als daran, was schon im Haus verfügbar ist. Wer eine Überwachungslösung betreibt, prüft zuerst, ob sie Logon-Simulation kann, bevor er ein zweites Werkzeug einkauft.

Der Unterschied, auf den es ankommt: Überwachung sagt dir, dass der Host läuft. Eine Logon-Simulation sagt dir, dass sich jemand anmelden und wieder abmelden kann. Nur das zweite hätte den September gefunden.

Was das nicht heißt

Es heißt nicht, dass man nicht patchen soll. Die Microsoft-Updates vom September schlossen eine Use-after-free-Lücke in den Remotedesktopdiensten, also in genau den Diensten, die dann ausfielen: Codeausführung über das Netz, ohne Anmeldung. Wer aus Vorsicht nicht patcht, tauscht einen möglichen Ausfall gegen eine sichere Lücke.

Es heißt auch nicht, dass DTAP schlecht ist. Der Aufbau ist richtig. Er löst nur ein anderes Problem als das, für das er oft ins Feld geführt wird.

Was du dir besser merken solltest

Stages begrenzen den Schaden. Sie finden den Fehler nicht.

Gefunden wird er von einem Test, der die Zustandswechsel durchläuft, die in Produktion ständig passieren: Sitzung trennen, wiederaufnehmen, abmelden, warten, erneut anmelden. Ein Server, den man nur beobachtet, bestätigt nur, dass er läuft.

Automatisieren lässt sich das mit Logon-Simulation. Der Prüfstein bei jedem dieser Werkzeuge ist derselbe: Meldet sich der künstliche Nutzer auch wieder ab?

Und wenn du für Acceptance wählen musst zwischen einem perfekt nachgebauten Labor und einer kleinen Abteilung mit echten Menschen: nimm die Menschen. Sie melden sich abends ab, und genau das ist der Test.

Quellen

• CTX697101: Issues with Microsoft Windows September 2026 Update, Citrix: betroffene Updates, Ereignis 6005 mit SessionEnv/Disconnect, Out-of-Band-Pakete
• KB5122882: Sicherheitsupdate für Windows Server 2022 vom 08.09.2026, Microsoft: bekanntes Problem mit den Remotedesktopdiensten
• KB5129237: Out-of-Band-Update für Windows Server 2022 vom 14.09.2026, Microsoft: behebt das Problem mit den Remotedesktopdiensten
• CVE-2026-69525, Microsoft Security Response Center: die mit den September-Updates geschlossene Lücke in den Remotedesktopdiensten