4
Verbindungsprobleme mit W2k8 R2 SP1 Remote Desktop Session Host
Hallo,
ich habe ein Problem mit einem Server der Remote-Desktop bereitstellen soll.
Der Server ist ein Windows 2008 R2 SP1 Enterprise, voll gepatcht mittels WindowsUpdate.
Auf dem Server soll nur SAPGui für ThinClients (Siemens) bereit gestellt werden.
Das funktioniert auch wunderbar, aber nun zu dem Problem:
Seit dem umstellen der RD Lizenzen von Trial auf Lizenzserver (Device CALs) funktioniert das Reconnecten der ThinClients nicht mehr.
Das heißt es funktionierte alles, die ThinClients konnten Verbinden, SAPGui starten, und bei einem Verbindungsverlust durch z.B. Netzwerkunterbrechung haben sie sich direkt neu mit dem Server verbunden.
Nach dem aktivieren der Lizenzen funktioniert aber dieses neu Verbinden nicht mehr.
D.h. nach einer Netzwerkunterbrechung (oder auch einem Neustart des Servers oder einem händischen Disconnect per Taskmanager) können die ThinClients nicht mehr verbinden, sie versuchen es permanent, werden aber vom Server abgewiesen.
Eine Fehlermeldung in den Server-Logs dazu gibt es nicht, da ist schweigen im Walde.
Die Fehlermeldung auf den ThinClients besagt nur "Host closed Session, Check Server Licenses".
Was kann man da machen?
Es kann doch nicht sein das erst alles problemlos funktioniert, und dann nach einem aktivieren der 100 Lizenzen nicht mehr.
Ich habe das ganze auch noch einmal verifiziert, also neuen Server als Trial aufgesetzt, alles funktioniert. Auch das neu Verbinden nach einem Verbindungsverlust.
Dann aktiviert man die Lizenzen --> Vorbei, geht nicht mehr.
Am meisten nervt mich momentan das es keine Logeinträge dazu gibt, nichts was man untersuchen könnte. Weder auf dem RD Server, noch auf dem Lizenzserver. Gar nichts.
Irgendein Tipp?
ich habe ein Problem mit einem Server der Remote-Desktop bereitstellen soll.
Der Server ist ein Windows 2008 R2 SP1 Enterprise, voll gepatcht mittels WindowsUpdate.
Auf dem Server soll nur SAPGui für ThinClients (Siemens) bereit gestellt werden.
Das funktioniert auch wunderbar, aber nun zu dem Problem:
Seit dem umstellen der RD Lizenzen von Trial auf Lizenzserver (Device CALs) funktioniert das Reconnecten der ThinClients nicht mehr.
Das heißt es funktionierte alles, die ThinClients konnten Verbinden, SAPGui starten, und bei einem Verbindungsverlust durch z.B. Netzwerkunterbrechung haben sie sich direkt neu mit dem Server verbunden.
Nach dem aktivieren der Lizenzen funktioniert aber dieses neu Verbinden nicht mehr.
D.h. nach einer Netzwerkunterbrechung (oder auch einem Neustart des Servers oder einem händischen Disconnect per Taskmanager) können die ThinClients nicht mehr verbinden, sie versuchen es permanent, werden aber vom Server abgewiesen.
Eine Fehlermeldung in den Server-Logs dazu gibt es nicht, da ist schweigen im Walde.
Die Fehlermeldung auf den ThinClients besagt nur "Host closed Session, Check Server Licenses".
Was kann man da machen?
Es kann doch nicht sein das erst alles problemlos funktioniert, und dann nach einem aktivieren der 100 Lizenzen nicht mehr.
Ich habe das ganze auch noch einmal verifiziert, also neuen Server als Trial aufgesetzt, alles funktioniert. Auch das neu Verbinden nach einem Verbindungsverlust.
Dann aktiviert man die Lizenzen --> Vorbei, geht nicht mehr.
Am meisten nervt mich momentan das es keine Logeinträge dazu gibt, nichts was man untersuchen könnte. Weder auf dem RD Server, noch auf dem Lizenzserver. Gar nichts.
Irgendein Tipp?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 189109
Url: https://administrator.de/forum/verbindungsprobleme-mit-w2k8-r2-sp1-remote-desktop-session-host-189109.html
Ausgedruckt am: 22.04.2025 um 00:04 Uhr
4 Kommentare
Neuester Kommentar
Moin moin,
der allererste Tipp wäre: Reboot. Den RD-Host ebenso wie den Lizenzserver (der sollte ja eh nich auf dem RD-Host laufen).
Dann würde ich mal Richtung Namensauflösung gehen: Kann der RD-Host den Lizenzserver finden, also DNS-technisch auflösen? Was ist mit WINS?
Cheers,
jsysde
der allererste Tipp wäre: Reboot. Den RD-Host ebenso wie den Lizenzserver (der sollte ja eh nich auf dem RD-Host laufen).
Dann würde ich mal Richtung Namensauflösung gehen: Kann der RD-Host den Lizenzserver finden, also DNS-technisch auflösen? Was ist mit WINS?
Cheers,
jsysde
Hallo,
das habe ich leider bereits probiert.
Der Lizenzserver läuft problemlos, und wie gesagt, einmal Verbinden geht - nach einem Verbindungsverlust aber nicht mehr - bis man den Terminalclient neu startet.
das habe ich leider bereits probiert.
Der Lizenzserver läuft problemlos, und wie gesagt, einmal Verbinden geht - nach einem Verbindungsverlust aber nicht mehr - bis man den Terminalclient neu startet.
Moin,
ist denn der Lizenzserver eine eigene Maschine oder läuft der Dienst direkt auf dem RD-Host?
Was sagt denn der Lizenzmanager?
Cheers,
jsysde
ist denn der Lizenzserver eine eigene Maschine oder läuft der Dienst direkt auf dem RD-Host?
Was sagt denn der Lizenzmanager?
Cheers,
jsysde
Läuft auf einem anderen Server.
Habe diesen auch schon gewechselt, brachte aber nichts. Auch hier gibt es keinerlei Log-Einträge warum die Verbindung fehl schlägt.
Schade das MS keinen Debug-Modus kennt ...
Nach langem Probieren lassen wir es nun erstmal ohne Failover laufen die Terminals werden bei einem Serverausfall manuell neu gestartet - dann ziehen sie sich per RoundRobin den 2. Server und gut ist.
Blöd nur das so ein Fehler erst NACH dem Kauf der Lizenzen auftritt und ohne aktivieren alles läuft, sonst hätten wir uns für eine andere Lösung entschieden.
Habe diesen auch schon gewechselt, brachte aber nichts. Auch hier gibt es keinerlei Log-Einträge warum die Verbindung fehl schlägt.
Schade das MS keinen Debug-Modus kennt ...
Nach langem Probieren lassen wir es nun erstmal ohne Failover laufen die Terminals werden bei einem Serverausfall manuell neu gestartet - dann ziehen sie sich per RoundRobin den 2. Server und gut ist.
Blöd nur das so ein Fehler erst NACH dem Kauf der Lizenzen auftritt und ohne aktivieren alles läuft, sonst hätten wir uns für eine andere Lösung entschieden.
