Terminalserver RDP-Verbindungsfehler

16. Juli 2013 · 3 min Lesezeit · von Jan Weis

Kurz & knapp: Kommt nach Windows-Updates oder einem Netzwerkkarten-Wechsel (z. B. Migration auf eine VM) keine RDP-Verbindung mehr zustande und zeigt netstat -a -o den Port 3389 nicht, ist der RDP-Listener an einen nicht mehr vorhandenen Adapter gebunden. Lösung: im RDP-Tcp-Listener alle Adapter freigeben (DWORD auf 0) und die Remotedesktopdienste neu starten.

Heute bin ich wieder auf ein interessantes Problem gestoßen: Auf einem Terminalserver (Remote Desktop Sitzungshost) lässt sich nach der Installation von Sicherheitsupdates keine RDP-Verbindung mehr aufbauen. Das Tückische daran – kein Eintrag in den Eventlogs weist auf die Ursache hin.

Symptom#

• Keine RDP-Verbindung zum Server möglich.
• Keine passenden Fehler in den Eventlogs.
• Trat unmittelbar nach der Installation von Sicherheitsupdates auf.

Erste Troubleshooting-Schritte (ohne Erfolg)#

Diese naheliegenden Prüfungen brachten keine Besserung:

• Remotedesktopdienste untersucht, gestartet und neu gestartet → Problem weiterhin vorhanden.
• Remotedesktopeinstellungen kontrolliert (auch testweise auf „Keine Verbindung mit diesem Computer zulassen") → Problem weiterhin vorhanden.
• Windows Firewall geprüft: aktiviertes Netzwerkprofil und Freigabe von Port 3389 → Problem weiterhin vorhanden.

Vor den Windows-Updates war alles funktionstüchtig.

Diagnose: Lauscht der Port 3389?#

Den Dienst etwas näher in der Kommandozeile untersucht:

netstat -a -o

In der Ausgabe fehlte der Port 3389 komplett. Es stimmt also etwas mit der Bindung des Ports an die IP bzw. den Netzwerkadapter nicht.

Ein Blick in die Konfiguration des Remotedesktop-Sitzungshosts → Eigenschaften von RDP-TCP → Tab Netzwerkadapter bestätigt das Problem:

Ursache: Dieses Problem tritt häufig auf, wenn Netzwerkkarten gewechselt werden – typischerweise bei Migrationen von Hardware zu einer VM (VMware vSphere oder Microsoft Hyper-V). Der RDP-Listener ist dann noch an einen nicht mehr vorhandenen Adapter gebunden.

Lösung: Bindung in der Registry korrigieren#

Achtung: Die folgenden Schritte greifen in die Registry ein. Nur für geübte Anwender – vorab eine Sicherung anlegen.

1. Richtige Netzwerkkarte ermitteln#

Den Namen der gewünschten Verbindung direkt in der Registry auslesen. Die GUID steht für die Geräteklasse der Netzwerkkarte:

HKLM\SYSTEM\CurrentControlSet\Control\Network\{4d36e972-e325-11ce-bfc1-08002be10318}

Die vorhandenen Schlüssel öffnen und unter Connection den Namen der gewünschten Verbindung auslesen.

2. Prüfen, ob die Netzwerkkarte noch vorhanden ist#

Mit der GUID oberhalb von Connection kontrollieren, ob die Netzwerkkarte auf dem Terminalserver überhaupt noch existiert.

3. LanaID notieren#

Falls wir später die Netzwerkkarte direkt anbinden möchten, hier die LanaID notieren. Mit diesen gesammelten Informationen kommen wir unserem Ziel näher – als Nächstes sehen wir uns die Zuordnung an:

4. Alle Adapter freigeben (DWORD auf 0)#

Um ALLE Adapter ansprechen zu können, stellen wir den DWORD-Eintrag auf 0.

5. Dienst neu starten#

Die Konsole Konfiguration des Remotedesktop-Sitzungshosts schließen und den Dienst Remotedesktopdienste neu starten.

6. Ergebnis kontrollieren#

Die Konsole erneut öffnen → Eigenschaften von RDP-TCP → Tab Netzwerkadapter: Der Fehler ist verschwunden.

Abschließend in der Kommandozeile prüfen, ob Port 3389 wieder abgehört wird:

netstat -a -o

Nun kann wieder gearbeitet werden. ;-)

Weiterführend#

Microsoft führt hierzu sogar einen KB-Artikel – leider etwas unverständlich geschrieben und über Google schlecht zu finden (Microsoft KB 555382).

Verwandt: RemoteApp ignoriert Autostart – ein weiteres Remote-Desktop-Services-Troubleshooting.

Kategorien: Remote Desktop Services

Tags: RDP