Woran Sie erkennen, dass es dieser Fall ist
- Die Remotedesktopverbindung wurde unterbrochen, da ein Netzwerkfehler aufgetreten ist.
- Es wird versucht, die Verbindung wiederherzustellen … Verbindungsversuch 1 von 20
- Die Remotesitzung wurde getrennt, da das Zeitlimit für die Verbindung überschritten wurde.
- Ihre Remotedesktopdienste-Sitzung wurde beendet.
- Die Verbindung mit dem Remotecomputer wurde unterbrochen. Die Verbindung mit dem Remotecomputer kann nicht hergestellt werden.
Zugehörige Fehlercodes
- 0x4
- 0x204
- 0x904
- 0x1104
- Fehlercode 0x3
- TerminalServices-LocalSessionManager 40
Die schnelle Hilfe, in dieser Reihenfolge
Alle oder einer?
Fragen Sie zwei andere Nutzer. Trifft es alle gleichzeitig, ist es Server, Rechenzentrumsanbindung oder Firewall – dann ab zu Schritt 5. Trifft es einen, ist es seine Leitung, sein WLAN, sein VPN-Client oder sein Gerät. Die meisten Stunden werden damit verloren, dass ein Einzelfall am Server gesucht wird.
Damit wissen Sie: Sie wissen, ob Sie am Server oder am Arbeitsplatz suchen.
WLAN gegen Kabel tauschen
Remotedesktop verträgt kurze Aussetzer schlecht: Jede Lücke von einigen Sekunden löst die Wiederverbindung aus. Ein Notebook im WLAN mit schwachem Signal oder ein Repeater erzeugt genau solche Lücken. Mit Kabel testen – oder am Mobilfunk-Hotspot; bleibt der Abbruch aus, war es das WLAN.
Damit wissen Sie: Die Übertragungsstrecke am Arbeitsplatz ist als Ursache ein- oder ausgeschlossen.
Leitung messen: Paketverlust und Schwankung
Nicht die Bandbreite zählt, sondern Verlust und Schwankung. Unser Ping-Test zeigt fünfundzwanzig Einzelmessungen als Balken; ein einzelner Ausreißer ist harmlos, regelmäßige Lücken sind es nicht. Über VPN dieselbe Messung zum Terminalserver – ein VPN, das Pakete verliert, lässt RDP einfrieren, bevor es abbricht.
Damit wissen Sie: Verlust und Schwankung der Strecke sind bekannt – mit Zahl.
RDP auf TCP zwingen
Seit Windows 8 nutzt Remotedesktop zusätzlich UDP, was auf guten Leitungen flüssiger ist und auf manchen VPN-Verbindungen und Firewalls Abbrüche erzeugt. Auf dem Client lässt sich UDP abschalten (Gruppenrichtlinie oder Registrierung, Befehle unten); bleibt der Abbruch danach aus, ist die Ursache gefunden – und die Firewall oder der VPN-Tunnel bekommt die Aufgabe, UDP 3389 sauber durchzulassen oder dauerhaft wegzulassen.
Damit wissen Sie: Der UDP-Transport ist als Ursache bestätigt oder ausgeschlossen.
Am Server: Protokoll, Sitzungsgrenzen, Last
Das Betriebsprotokoll des lokalen Sitzungs-Managers zeigt je Trennung Uhrzeit und Grund; die Sitzungssammlung zeigt Zeitlimits für getrennte und inaktive Sitzungen; die Auslastung zeigt, ob der Host beim Abbruch am Anschlag war. Ein Abbruch zur selben Minute jeden Tag ist ein Zeitplan: Sicherung, Virenscan, Neustart, Zeitlimit.
Damit wissen Sie: Die serverseitige Ursache steht im Protokoll – oder ist ausgeschlossen.
Dasselbe in PowerShell
Für alle, die mehr als einen Rechner betreuen
Die ersten beiden Blöcke laufen am Arbeitsplatz des betroffenen Nutzers, die übrigen auf dem Sitzungshost. Der UDP-Schalter ist die einzige Änderung – und er lässt sich mit demselben Befehl zurücknehmen.
PowerShell mit erweiterten Rechten starten – so geht es
- Windows 11
- Rechtsklick auf das Startsymbol – oder die Tastenkombination Windows + X – und dann Terminal (Administrator) wählen.
- Windows 10
- Dieselbe Tastenkombination, der Eintrag heißt dort Windows PowerShell (Administrator). Steht dort stattdessen die Eingabeaufforderung, lässt sich das in den Taskleisteneinstellungen umstellen – oder Sie nehmen den Weg darunter.
- Auf jedem Windows
- Startmenü öffnen, powershell tippen und den Treffer mit Strg + Umschalt + Eingabe öffnen. Das ist der Weg, der überall funktioniert.
- Woran Sie erkennen, dass es geklappt hat
- In der Titelleiste des Fensters steht Administrator, und die Eingabeaufforderung beginnt in C:\Windows\System32 statt in Ihrem Benutzerordner. Vorher bestätigen Sie die Abfrage der Benutzerkontensteuerung mit Ja.
- Wenn nach Zugangsdaten gefragt wird
- Dann sind Sie auf diesem Rechner kein Administrator. Im Firmennetz ist das der Regelfall und Absicht: Wer täglich mit erhöhten Rechten arbeitet, gibt einer Schadsoftware dieselben Rechte. Der richtige Weg ist die Zuarbeit durch die Administration – nicht das dauerhafte Hochstufen des eigenen Kontos.
Ein Hinweis, der wichtiger ist als er klingt: Führen Sie keinen Befehl aus, dessen Wirkung Sie nicht benennen können – auch keinen von uns. Die Blöcke unten sagen jeweils dazu, was sie tun; die, die etwas verändern, sind gekennzeichnet.
Am Arbeitsplatz: Strecke zum Terminalserver messen
Verlust und Schwankung sind die Zahlen, die einen Abbruch erklären – nicht die Bandbreite. Dreißig Pings mit Statistik, dazu die Prüfung, ob der RDP-Port überhaupt erreichbar ist.
PS C:\> Test-NetConnection -ComputerName ts01.firma.de -Port 3389 | Select-Object ComputerName, RemotePort, TcpTestSucceeded, PingSucceededPS C:\> ping ts01.firma.de -n 30Ping-Statistik für 10.20.0.15: Pakete: Gesendet = 30, Empfangen = 28, Verloren = 2 (6% Verlust)Zeitangaben in Millisek.: Minimum = 18ms, Maximum = 412ms, Mittelwert = 41ms# 6 % Verlust und ein Maximum beim Zehnfachen des Mittelwerts: das reicht für Einfrieren und Abbruch# Welcher Transport läuft gerade? Im Verbindungsinfo-Fenster des RDP-Clients (Signalsymbol) steht UDP oder TCPAm Arbeitsplatz: RDP auf TCP zwingen (UDP abschalten)
Der Test mit der höchsten Trefferquote bei Einzelfällen über VPN und WLAN. Wirkt für alle Verbindungen dieses Clients; danach den Remotedesktop-Client neu starten.
PS C:\> New-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client' -Force | Out-NullPS C:\> Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client' -Name 'fClientDisableUDP' -Type DWord -Value 1# Entspricht der Gruppenrichtlinie: Remotedesktopdienste > Remotedesktopverbindungs-Client > UDP auf Client deaktivieren# Rückgängig:PS C:\> Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client' -Name 'fClientDisableUDP' -Value 0Das verändert etwas: Ändert die Richtlinie des Clients für alle Nutzer dieses Geräts. Auf verlustfreien Leitungen ist UDP das flüssigere Verfahren – der Schalter ist ein Test und eine Abhilfe für schlechte Strecken, keine Standardeinstellung für alle.
Am Sitzungshost: Wer wurde wann getrennt – und warum?
Das Betriebsprotokoll des lokalen Sitzungs-Managers nennt je Ereignis Nutzer, Sitzung, Uhrzeit und Grund. Ereignis 24 = getrennt, 25 = wieder verbunden, 40 = getrennt mit Grundcode, 23 = abgemeldet.
PS C:\> Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational' -MaxEvents 200 | Where-Object Id -in 23, 24, 25, 40 | Select-Object TimeCreated, Id, @{ n = 'Text'; e = { ($_.Message -split "`n")[0] } } | Format-Table -AutoSize# Grundcodes bei Ereignis 40: 0 = unbekannt, 5 = Admin hat getrennt, 11 = Nutzer hat getrennt, 12 = Zeitlimit, 0x3/0x4 = Netzwerk# Wer ist gerade angemeldet, und seit wann getrennt?PS C:\> qwinsta SITZUNGSNAME BENUTZERNAME ID STATUS rdp-tcp#3 m.mustermann 4 Aktiv s.beispiel 5 Getr.# Mit RDS-Rolle: Sitzungen mit LeerlaufzeitPS C:\> Get-RDUserSession | Select-Object UserName, SessionState, IdleTime, CreateTimeAm Sitzungshost: Sitzungsgrenzen und Auslastung
Die Zeitlimits trennen gewollt – nur muss man sie kennen. Danach die Frage, ob der Host zum Zeitpunkt des Abbruchs am Anschlag war.
# Zeitlimits der Sitzungssammlung (RDS-Rolle), Minuten; 0 = niePS C:\> Get-RDSessionCollectionConfiguration -CollectionName 'Arbeitsplatz' -Connection | Select-Object DisconnectedSessionLimitMin, IdleSessionLimitMin, ActiveSessionLimitMin, BrokenConnectionAction# Beispiel: getrennte Sitzungen nach 60 min beenden, inaktive nach 180 min trennenPS C:\> Set-RDSessionCollectionConfiguration -CollectionName 'Arbeitsplatz' -DisconnectedSessionLimitMin 60 -IdleSessionLimitMin 180# Ohne RDS-Rolle: dieselben Werte in der Gruppenrichtlinie unter Remotedesktopdienste > Sitzungszeitlimits# Auslastung jetzt – und die sechs größten VerbraucherPS C:\> Get-Counter '\Processor(_Total)\% Processor Time', '\Memory\Available MBytes' -SampleInterval 2 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path, CookedValuePS C:\> Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 6 Name, @{ n = 'MB'; e = { [math]::Round($_.WorkingSet64 / 1MB) } }, @{ n = 'Sitzung'; e = { $_.SessionId } }Das verändert etwas: Zeitlimits gelten für alle Nutzer der Sammlung. Ein zu kurzes Limit für getrennte Sitzungen beendet Programme mit ungespeicherter Arbeit – vorher die Nutzer informieren, und Werte unter 30 Minuten vermeiden.
Warum friert das Bild ein, bevor die Verbindung abbricht?
Weil Remotedesktop bei Paketverlust nicht sofort aufgibt. Der Client wartet auf fehlende Pakete, zeigt das letzte vollständige Bild und versucht im Hintergrund, die Verbindung zu halten – erst nach einer Weile erscheint die Meldung mit den Verbindungsversuchen. Das Einfrieren ist also das Symptom einer Leitung mit Verlust, nicht eines Servers, der steht. Wer in diesem Moment auf dem Server nachsieht, findet meist eine Sitzung, die ganz normal weiterläuft.
Der UDP-Transport verstärkt das: Er ist für verlustarme Leitungen gebaut und reagiert auf verlorene Pakete anders als TCP. Über VPN-Tunnel, die UDP in UDP kapseln, über Firewalls mit kurzen Zustandstabellen und über Mobilfunk mit wechselnder Qualität kommt es zu genau den Lücken, die das Bild einfrieren lassen. Deshalb ist „RDP auf TCP zwingen“ der Test mit der höchsten Trefferquote bei Einzelfällen.
Die Gegenprobe ist einfach: Ein Nutzer, bei dem es über das Büro-Kabel nie einfriert und über das Heim-WLAN jeden Tag, hat kein Serverproblem. Die Lösung liegt dann im Homeoffice – Kabel statt WLAN, ein anderer Router, im Zweifel eine zweite Leitung – und nicht im Rechenzentrum.
Was sind Sitzungsgrenzen, und warum trennen sie gewollt?
Ein Sitzungshost unterscheidet aktive, inaktive und getrennte Sitzungen. Getrennt heißt: Der Nutzer hat das Fenster geschlossen oder die Verbindung verloren, seine Programme laufen weiter. Das ist gewollt, damit nach einem Leitungsabbruch alles noch da ist. Es kostet aber Arbeitsspeicher, und deshalb setzt der Administrator Grenzen: getrennte Sitzungen nach einer Stunde beenden, inaktive nach drei, zum Beispiel.
Wer diese Grenzen nicht kennt, erlebt sie als Störung: Mittags geht die Verbindung verloren, nach der Pause ist die Sitzung weg und die ungespeicherte Arbeit auch. Die Grenzen stehen in der Sitzungssammlung oder in der Gruppenrichtlinie, und die richtigen Werte sind eine Abwägung zwischen Speicher und Komfort – nicht ein Fehler, den es zu beheben gilt. Was es zu beheben gilt, ist, dass niemand sie kennt.
Eine Grenze, die regelmäßig Ärger macht, ist die für inaktive Sitzungen bei Nutzern, die lange lesen oder telefonieren, ohne Tastatur und Maus zu bewegen. Drei Stunden sind dort ein vernünftiger Wert; eine Stunde ist es nicht.
Wann liegt es wirklich am Server?
Wenn alle Nutzer gleichzeitig betroffen sind, und das Protokoll des Sitzungs-Managers für denselben Zeitpunkt Trennungen zeigt. Dann gibt es drei Kandidaten: Der Host war ausgelastet – ein Prozess hat den Arbeitsspeicher oder die Prozessoren gebunden, meist ein Virenscan, ein Index, eine Sicherung, ein Nutzer mit einem Browser voller Tabs –, die Anbindung des Rechenzentrums hatte einen Aussetzer, oder ein Zeitplan hat zugeschlagen: Neustart nach Updates, Dienstneustart der Sicherung.
Die Auslastung lässt sich nachträglich nur sehen, wenn sie aufgezeichnet wurde – im Betrieb läuft dafür eine Überwachung, die je Minute Speicher, Prozessor und Sitzungszahl festhält. Ohne sie bleibt die Vermutung. Das ist einer der Gründe, warum ein Terminalserver in den Betrieb gehört und nicht in den Keller: Die Frage „Was war gestern um 11:42?“ muss eine Antwort haben.
Im Rechenzentrum unseres Partners TERRA CLOUD sind die virtuellen Server nach Herstellerangabe mit 99,95 Prozent Verfügbarkeit zugesichert und mehrfach redundant angebunden; ein Abbruch für alle Nutzer ist dort selten das Rechenzentrum und häufig die Leitung des Büros. Deshalb gehört für Standorte, die nicht stehen dürfen, eine zweite Leitung an die Firewall.
Im Betrieb
Ein Terminalserver, der abbricht, ist ein Terminalserver ohne Aufzeichnung.
Jede Störung auf dieser Seite hat eine Zahl, die sie erklärt: Paketverlust in Prozent, Schwankung in Millisekunden, Speicher in Prozent, eine Uhrzeit im Protokoll. Keine davon ist nachträglich zu bekommen, wenn sie nicht aufgezeichnet wurde. Deshalb beginnt der Betrieb eines Terminalservers bei uns mit der Überwachung – Leitung, Host, Sitzungen – und nicht mit dem ersten Anruf.
Die zweite Hälfte ist die Leitung der Nutzer. Ein Sitzungshost im Rechenzentrum ist nur so stabil wie die Strecke dorthin, und die läuft durch Router, WLAN und VPN-Clients, die niemand im Rechenzentrum sieht. Wir messen sie deshalb vom Standort aus, bevor der erste Nutzer umzieht – und für Homeoffice-Arbeitsplätze mit wiederkehrenden Abbrüchen gibt es eine kurze Liste: Kabel, Router, zweiter Anschluss.
Und die dritte: Sitzungsgrenzen, Updatefenster und Sicherungszeiten stehen bei uns in der Betriebsdokumentation, die Nutzer kennen sie. Eine Trennung um 20 Uhr, die alle erwartet haben, ist keine Störung.
Wann Sie aufhören sollten zu probieren
Alles bis zum Protokoll des Sitzungs-Managers gehört in die Hand des Administrators; das Abschalten von UDP am Client darf jeder Nutzer selbst testen. Die Grenze ist die Firewall und der VPN-Tunnel: Wer dort UDP-Regeln oder Zustandszeiten ändert, ändert sie für alle – das gehört in ein Wartungsfenster mit vorheriger Sicherung der Konfiguration.
Häufige Anschlussfragen
Hilft eine schnellere Leitung?
Meist nicht. Remotedesktop braucht wenig Bandbreite – Büroanwendungen kommen mit einem Bruchteil eines Megabits je Sitzung aus –, aber eine Leitung ohne Paketverlust und ohne Schwankung. Eine 50-MBit-Leitung mit stabiler Antwortzeit ist besser als eine 500-MBit-Leitung, die alle zwei Minuten einen Aussetzer hat. Messen, nicht kaufen.
Warum läuft es im Büro und nicht im Homeoffice?
Weil im Homeoffice drei Dinge dazukommen, die das Büro nicht hat: WLAN, ein Heimrouter und ein VPN-Client. Jedes davon kann Pakete verlieren oder UDP schlecht behandeln. Die Reihenfolge der Prüfung: Kabel statt WLAN, RDP auf TCP, dann der VPN-Client. In neun von zehn Fällen ist es nach dem zweiten Schritt vorbei.
Der Drucker verschwindet nach jedem Abbruch – gehört das dazu?
Ja, derselbe Mechanismus: Die Druckerumleitung wird beim Verbindungsaufbau eingerichtet und bei einer Wiederverbindung manchmal nicht sauber neu aufgebaut. Ab- und wieder anmelden statt nur neu verbinden hilft im Einzelfall; dauerhaft hilft ein Druckserver im Netz, der die Umleitung überflüssig macht.
Was bedeutet „Verbindungsversuch 1 von 20“?
Der Client hat die Verbindung verloren und versucht, sie innerhalb eines Zeitfensters wiederherzustellen, ohne dass die Sitzung auf dem Server beendet wird. Gelingt es, läuft alles weiter, als wäre nichts gewesen. Gelingt es nicht, bleibt die Sitzung getrennt auf dem Server – und ist bei der nächsten Anmeldung noch da, solange die Sitzungsgrenze sie nicht beendet hat.
Dazu passt