Die RDP-Verbindung kommt zustande, bricht aber nach einigen Minuten ab? Oder der Zielrechner bleibt bei der Konfiguration der Remotedesktopdienste hängen? Nach den Windows-Sicherheitsupdates vom September 2026 ist ein entsprechender Fehler bestätigt. Es gibt bereits eine Korrektur. Entscheidend ist, den Updatefehler von anderen Ursachen zu unterscheiden.
Stand: 28. September 2026. Diese Anleitung behandelt klassische RDP-Verbindungen und Remotedesktopdienste. Die Diagnosebefehle lesen Einstellungen und Protokolle aus; sie verändern keine Konfiguration.
Was Microsoft zum September-Fehler bestätigt hat
Laut Windows Release Health können die Updates vom 8. September 2026 RDS instabil machen. Beschrieben werden Verbindungsabbrüche, Anmeldeprobleme und Systeme, die während der Remotedesktopkonfiguration nicht weiterkommen. Auch Verwaltungsprogramme und die Windows-Update-Oberfläche können hängen.
Für Windows 11 24H2 nennt Microsoft KB5124008 als auslösendes Update. Der Fehler betrifft außerdem weitere Windows-Client- und Serverversionen. Windows 365 und Azure Virtual Desktop sind von diesem konkreten RDS-Fehler ausdrücklich ausgenommen. Ein schwarzer Desktop in AVD muss deshalb gesondert untersucht werden.
Microsoft führt das Problem als behoben. Ein allgemeiner Fehlercode, mit dem sich jeder betroffene Rechner eindeutig erkennen ließe, ist in der Meldung nicht angegeben. Der zeitliche Zusammenhang mit einem Update allein beweist die Ursache daher nicht.
1. Zuerst die passende Korrektur installieren
Für Windows 11 24H2 und 25H2 behebt das außerplanmäßige Update KB5129195 vom 14. September 2026 das dokumentierte RDS-Problem. Es führt zu den Builds 26100.9457 beziehungsweise 26200.9457. Spätere kumulative Updates enthalten die Korrektur ebenfalls.
Prüfe am betroffenen Zielrechner mit winver die Version und den Build. Öffne anschließend Einstellungen → Windows Update → Updateverlauf. In verwalteten Umgebungen gehört zusätzlich die Freigabe beziehungsweise Installation im verwendeten Updateverwaltungssystem geprüft.
Installiere das für diese Windows-Version vorgesehene aktuelle kumulative Update und führe einen erforderlichen Neustart im Wartungsfenster durch. KB5129195 ist kein universelles Paket für sämtliche Windows-Serverversionen. Für andere Versionen verwende den zugehörigen Release-Health-Eintrag und dessen Updateverweis.
Die vorhandene Korrektur ist der sinnvollere erste Ansatz als eine pauschale Deinstallation des Sicherheitsupdates. Sichere vor einem Neustart den Konsolenzugang zum Host und informiere angemeldete Benutzer.
2. Fehlerbild eingrenzen: Verbindung, Anmeldung oder Sitzung?
Notiere zunächst, an welcher Stelle es scheitert. Folgende Unterscheidung hilft bei der weiteren Diagnose:
- Keine Verbindung: Zieladresse, VPN, Netzwerkpfad, Firewall und Listener prüfen.
- Verbindung vorhanden, Anmeldung abgelehnt: Exakten Meldungstext, Benutzerkonto und Anmeldeberechtigungen untersuchen.
- Sitzung startet und bricht später ab: Zeitpunkt, betroffene Benutzer, Hostzustand und Ereignisprotokolle vergleichen.
Teste nach Möglichkeit denselben Host von einem zweiten Client sowie einen anderen Host vom ursprünglichen Client aus. Ändere dabei jeweils nur eine Variable. So entsteht ein verwertbarer Vergleich statt einer Folge zufälliger Reparaturversuche.
3. TCP-Erreichbarkeit vom Client prüfen
Öffne auf dem verbindenden Windows-Rechner Windows PowerShell. Ersetze den Beispielnamen durch den tatsächlichen internen Hostnamen:
Test-NetConnection -ComputerName "rdsh01.example.local" -Port 3389 -InformationLevel DetailedTcpTestSucceeded : True bedeutet, dass der TCP-Verbindungsaufbau zum geprüften Port funktioniert. Das beweist weder eine erfolgreiche Anmeldung noch dauerhaft stabile RDP-Sitzungen. Auch UDP und ein gegebenenfalls eingesetztes Gateway sind damit nicht vollständig getestet.
Bei False kann der Host unerreichbar sein, ein Filter blockieren oder der Dienst nicht lauschen. Ein fehlgeschlagener Ping allein ist weniger aussagekräftig: ICMP kann gesperrt sein, obwohl der TCP-Port erreichbar ist. Microsoft dokumentiert die Ausgabe im Handbuch zu Test-NetConnection.
Bei einem abweichenden RDP-Port muss der Test diesen Port verwenden. Bei RD-Gateway-Verbindungen kann der direkte Zugriff auf Port 3389 vom externen Client absichtlich gesperrt sein. Prüfe den internen Pfad dann von einem dafür vorgesehenen Rechner aus.
4. DNS, Dienst und Listener kontrollieren
Vergleiche die im Test angezeigte Ziel-IP mit der erwarteten Adresse. Teste bei Verdacht den TCP-Port zusätzlich über die bekannte interne IP. Funktioniert nur dieser Test, ist die Namensauflösung ein Ansatzpunkt. Microsoft beschreibt diese Abgrenzung in der RDP-Verbindungsdiagnose.
Auf dem Zielrechner kannst du in einer administrativen Windows-PowerShell über den Konsolenzugang den Dienststatus und die vorhandenen Listener auslesen:
Get-Service -Name TermService
qwinsta
netstat -anoSuche bei qwinsta nach dem RDP-Listener und bei netstat nach dem konfigurierten TCP-Port im Zustand LISTENING beziehungsweise ABHÖREN. Ein laufender Dienst allein garantiert noch keinen funktionierenden Listener. Microsoft erläutert den Zusammenhang in der allgemeinen RDP-Fehlersuche.
Fehlt der Listener, prüfe die aktivierte Remotedesktopfunktion und die wirksamen Richtlinien. Starte TermService nicht unüberlegt über deine einzige Fernverbindung neu: Dabei können Sitzungen getrennt werden. Firewallregeln sollten gezielt für den vorgesehenen Zugriff geprüft werden; eine globale Abschaltung ist für diese Diagnose nicht erforderlich.
5. Ereignisprotokolle zum Abbruchzeitpunkt lesen
Öffne am Zielrechner die Ereignisanzeige und prüfe unter Anwendungs- und Dienstprotokolle → Microsoft → Windows das Protokoll TerminalServices-LocalSessionManager → Operational. Folgender PowerShell-Befehl liest bis zu 40 Einträge aus den letzten zwei Stunden:
Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational'
StartTime = (Get-Date).AddHours(-2)
} -MaxEvents 40 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-ListDer Zeitfilter ist bewusst begrenzt. Passe ihn an den dokumentierten Abbruch an. Gibt es keine passenden Einträge, ist das kein Beweis für eine fehlerfreie Verbindung. Kontrolliere ergänzend System- und Anwendungsprotokoll sowie die Protokolle weiterer beteiligter RDS-Komponenten.
Notiere Ereignis-ID, Quelle, Uhrzeit und Meldung gemeinsam. Eine einzelne ID ohne Kontext reicht selten zur Ursachenzuordnung. Die verwendete Filterung beschreibt Microsoft bei Get-WinEvent.
6. Nach der Korrektur belastbar testen
Melde dich nach Installation und Neustart erneut mit dem zuvor betroffenen Client an. Lass die Sitzung länger bestehen als bis zum bisherigen Abbruch und wiederhole die typischen Arbeitsschritte. Prüfe anschließend, ob im gleichen Zeitraum neue Fehler protokolliert wurden.
Bleibt das Problem bestehen, sammle Windows-Version und Build beider Rechner, Updateverlauf, exakten Fehlertext, Zeitpunkt und Verbindungspfad: direkt, über VPN oder über RD Gateway. Halte außerdem fest, ob alle Benutzer oder nur einzelne Konten betroffen sind. Damit lässt sich die weitere Untersuchung gezielt fortsetzen.
Fazit
Für den bestätigten September-2026-RDS-Fehler existiert bereits ein korrigierendes Update. Prüfe zuerst den Patchstand des Zielsystems. Bestehen die Abbrüche danach weiter, liefern Erreichbarkeit, Listener und zeitlich passende Ereignisse die nächste belastbare Spur.
0 Kommentare