17
Kein RDP auf Server möglich
Obwohl der Server im Netz erreichbar ist
Hallo Ihr Lieben,
folgender Aufbau
1 Server: Windows Server 2003 32bit, AD, DNS 192.168.111.1 (fest)
1 Client: Windows 7 192.168.111.221 (dynamisch)
1 ESXi Server 192.168.111.4 (fest)
in diesem läuft ein
1 Server: Windows Server 2003 R2 64bit, AD, DNS 192.168.111.5 (fest)
Problem: Ich kann per RDP Session nicht mehr auf den Server mit der Ip 192.168.111.5 zugreifen.
Fehlermeldung:
Der Remotezugriff kann aus einem der folgenden Gründe keine Verbindung mit dem Remotecomputer herstellen:
1) Der Remotezugriff auf dem Server ist nicht aktiviert (ist er aber siehe Screenshot 1)
2) Der Remotecomputer ist ausgeschaltet (kann ihn ja anpingen und nslookup geht auch Screenshot 2)
3) Der Remotecomputer ist im Netzwerk nicht verfügbar (doch, sonst würde ich Ihn ja nicht anpingen können und zusätzlich noch ein Screenshot 3 der Anmeldemaske)
Screenshot 1:
Screenshot 2:
Screenshot 3:
Den Server habe ich bereits auch schon neu gestartet.
Da auch andere virtuelle maschinen im ESXi laufen auf die ich problemlos zugreifen kann, schließe dort den Fehler schon mal aus.
Wer hat einen Tip?
Vielen Dank für Eure Mühe...
Gruß Kuli
folgender Aufbau
1 Server: Windows Server 2003 32bit, AD, DNS 192.168.111.1 (fest)
1 Client: Windows 7 192.168.111.221 (dynamisch)
1 ESXi Server 192.168.111.4 (fest)
in diesem läuft ein
1 Server: Windows Server 2003 R2 64bit, AD, DNS 192.168.111.5 (fest)
Problem: Ich kann per RDP Session nicht mehr auf den Server mit der Ip 192.168.111.5 zugreifen.
Fehlermeldung:
Der Remotezugriff kann aus einem der folgenden Gründe keine Verbindung mit dem Remotecomputer herstellen:
1) Der Remotezugriff auf dem Server ist nicht aktiviert (ist er aber siehe Screenshot 1)
2) Der Remotecomputer ist ausgeschaltet (kann ihn ja anpingen und nslookup geht auch Screenshot 2)
3) Der Remotecomputer ist im Netzwerk nicht verfügbar (doch, sonst würde ich Ihn ja nicht anpingen können und zusätzlich noch ein Screenshot 3 der Anmeldemaske)
Screenshot 1:
Screenshot 2:
Screenshot 3:
Den Server habe ich bereits auch schon neu gestartet.
Da auch andere virtuelle maschinen im ESXi laufen auf die ich problemlos zugreifen kann, schließe dort den Fehler schon mal aus.
Wer hat einen Tip?
Vielen Dank für Eure Mühe...
Gruß Kuli
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 137020
Url: https://administrator.de/contentid/137020
Printed on: April 19, 2024 at 07:04 o'clock
17 Comments
Latest comment
Moin Kuli,
hast Du schon auf dem Server mit der IP 192.168.111.5 überprüft, ob er tatsächlich diese IP hat? Dein Client hat die relativ hohe IP 221; ich weiß zwar nicht, wie der Rest Deines Netzwerkes aussieht, aber diese IP deutet darauf hin, daß es weitere Hosts gibt. Denkbar wäre es, daß der Server kurz off war (zum Beispiel nach einem Update), und sich ein anderer Host die IP via DHCP gegriffen hat, der Server würde sich dann automatisch eine andere IP zulegen (aber dies eigentlich auch melden). Einfach mal ipconfig ausführen?
Gruß
Peter
hast Du schon auf dem Server mit der IP 192.168.111.5 überprüft, ob er tatsächlich diese IP hat? Dein Client hat die relativ hohe IP 221; ich weiß zwar nicht, wie der Rest Deines Netzwerkes aussieht, aber diese IP deutet darauf hin, daß es weitere Hosts gibt. Denkbar wäre es, daß der Server kurz off war (zum Beispiel nach einem Update), und sich ein anderer Host die IP via DHCP gegriffen hat, der Server würde sich dann automatisch eine andere IP zulegen (aber dies eigentlich auch melden). Einfach mal ipconfig ausführen?
Gruß
Peter
Jo hat er, da diese statisch ist und der DHCP erst ab .20 vergibt.
Nächster Schritt:
Remotedesktop für Verwaltung lässt maximal zwei gleichzeitige RDP-Sessions zu: sind schon zwei User eingeloggt?
Remotedesktop für Verwaltung lässt maximal zwei gleichzeitige RDP-Sessions zu: sind schon zwei User eingeloggt?
Es ist Samstag Abend, und ich möchte heute noch was anderes machen, daher noch kurz hinterher zwei Möglichkeiten:
a) Port 3389 wird irgendwo im Netzwerk nicht durchgeschliffen
b) Auf dem Client ist Win7 installiert; damit habe ich noch keine Erfahrung. Kann es sein, daß Win7 im DHCP-Betrieb eine höher-bittige Subnetzmaske als /24 generiert und daher IPs unterhalb der *.*.*.20, die vom DHCP-Server vorgegeben ist, nicht erkennt?
So, noch einen schönen Samstag-Abend, ich geh' jetzt mal ein paar Mädels aufreissen
Peter
a) Port 3389 wird irgendwo im Netzwerk nicht durchgeschliffen
b) Auf dem Client ist Win7 installiert; damit habe ich noch keine Erfahrung. Kann es sein, daß Win7 im DHCP-Betrieb eine höher-bittige Subnetzmaske als /24 generiert und daher IPs unterhalb der *.*.*.20, die vom DHCP-Server vorgegeben ist, nicht erkennt?
So, noch einen schönen Samstag-Abend, ich geh' jetzt mal ein paar Mädels aufreissen
Peter
Moin,
ist der Default Gateway überhaupt richtig?
Gruß
24
ist der Default Gateway überhaupt richtig?
Gruß
24
Hallo 24,
einerseits: Guter Einwurf, denn im C-Klasse-Netz wird die Gateway- bzw. Router-IP im letzten Oktett üblicherweise eine "1" sein; muß aber nicht sein, und zudem ist in diesem falle die 1 an einen Server vergeben -der aber auch das Gateway sein könnte.
Andererseits: spielt das Gateway für den RDP-Betrieb überhaupt eine Rolle?
So, und nu' geh' ich endgültig ein paar Bierchen aufreissen und ein paar Mädels vernaschen -oder andersrum.
Gruß
Peter
einerseits: Guter Einwurf, denn im C-Klasse-Netz wird die Gateway- bzw. Router-IP im letzten Oktett üblicherweise eine "1" sein; muß aber nicht sein, und zudem ist in diesem falle die 1 an einen Server vergeben -der aber auch das Gateway sein könnte.
Andererseits: spielt das Gateway für den RDP-Betrieb überhaupt eine Rolle?
So, und nu' geh' ich endgültig ein paar Bierchen aufreissen und ein paar Mädels vernaschen -oder andersrum.
Gruß
Peter
Versuchst du die RDP Verbindung über die IP oder den Servernamen? Wenn du den Namen eingibst überprüfe mal deinen DNS-Server.
Ansonsten mal in die Terminaldiensteverwaltung gehen und alle Verbindungen zurücksetzen auch wenn sie als nicht aktiv angezeigt werden.
Das sollte dann funtzen.
Ansonsten mal in die Terminaldiensteverwaltung gehen und alle Verbindungen zurücksetzen auch wenn sie als nicht aktiv angezeigt werden.
Das sollte dann funtzen.
Hallo,
Ist dein Benutzer als "Remote Benutzer" eingetragen? Schon mal probiert den Dienst neu zu starten, resp. Server neu zu starten? Firewalls auf dem Client/Server aus (oder richtig konfiguriert)?
mfG
Ist dein Benutzer als "Remote Benutzer" eingetragen? Schon mal probiert den Dienst neu zu starten, resp. Server neu zu starten? Firewalls auf dem Client/Server aus (oder richtig konfiguriert)?
mfG
Start > Ausführen > cmd >
Das bitte auf Client und auf dem Server selbst ausführen und Ergebnis posten (ja, wenn das Fenster schwarz wird ist das ein Ergebnis).
telnet 192.168.111.5 3389Das bitte auf Client und auf dem Server selbst ausführen und Ergebnis posten (ja, wenn das Fenster schwarz wird ist das ein Ergebnis).
Kann nicht sein, da ich ja einen anderen Rechner (virtuelle Maschine auf dem selben ESXi Server) erreiche auch über PORT 3389
Wäre auch egal, weil ich andere Server auf dem ESXi erreiche. Hat also mit dem Client nichts zu tun. Somal ich den Server bereits mit dieser Konstellation erreicht habe
Ja ist er...
Gruß Kuli
Wäre auch egal, weil ich andere Server auf dem ESXi erreiche. Hat also mit dem Client nichts zu tun. Somal ich den Server bereits mit dieser Konstellation erreicht habe
Zitat von @Kreuzpeter:
So, noch einen schönen Samstag-Abend, ich geh' jetzt mal ein paar Mädels aufreissen
Viel GlückSo, noch einen schönen Samstag-Abend, ich geh' jetzt mal ein paar Mädels aufreissen
Ja ist er...
Gruß Kuli
Zitat von @dbackhaus:
Versuchst du die RDP Verbindung über die IP oder den Servernamen? Wenn du den Namen eingibst überprüfe mal deinen
DNS-Server.
Ansonsten mal in die Terminaldiensteverwaltung gehen und alle Verbindungen zurücksetzen auch wenn sie als nicht aktiv
angezeigt werden.
Das sollte dann funtzen.
Versuchst du die RDP Verbindung über die IP oder den Servernamen? Wenn du den Namen eingibst überprüfe mal deinen
DNS-Server.
Ansonsten mal in die Terminaldiensteverwaltung gehen und alle Verbindungen zurücksetzen auch wenn sie als nicht aktiv
angezeigt werden.
Das sollte dann funtzen.
Beide Namen löst der DNS SERVER am CLIENTEN und auch am SERVER selbst richtig auf.
Bin Administrator...
Schon mal probiert den Dienst neu zu starten, resp. Server neu zu starten?
Beides schon probiert.
Firewalls auf dem Client/Server aus (oder richtig konfiguriert)?
Beide schon mal ausgeschaltet
Da hab' ich dann nur noch eine Idee:
Hast Du die Windows-Firewall Deines Server 2003 R2 schon überprüft? Normalerweise stellt der Server sie automatisch ein, wenn Remotedesktop angeschaltet wird. Vielleicht hat's in Deinem Netzwerk Unregelmäßigkeiten gegeben, und die Firewall hat Port 3389 abgeriegelt. Ansonsten weiss ich auch nicht weiter und werde den Thread weiter gespannt beobachten.
Gruß
Peter
Hast Du die Windows-Firewall Deines Server 2003 R2 schon überprüft? Normalerweise stellt der Server sie automatisch ein, wenn Remotedesktop angeschaltet wird. Vielleicht hat's in Deinem Netzwerk Unregelmäßigkeiten gegeben, und die Firewall hat Port 3389 abgeriegelt. Ansonsten weiss ich auch nicht weiter und werde den Thread weiter gespannt beobachten.
Gruß
Peter
Noch 'ne Frage: Dein Screenshot 3 ist die Anzeige des Clients bei der Remotedesktopverbindung? Dann war der ganze Thread bis jetzt umsonst, denn dann ist es garantiert kein Netzwerk-Problem, sondern irgendwas im Server, zum Beispiel eine Firewall-Reaktion.
Zitat von @Kreuzpeter:
Noch 'ne Frage: Dein Screenshot 3 ist die Anzeige des Clients bei der Remotedesktopverbindung? Dann war der ganze Thread bis
jetzt umsonst, denn dann ist es garantiert kein Netzwerk-Problem, sondern irgendwas im Server, zum Beispiel eine
Firewall-Reaktion.
Noch 'ne Frage: Dein Screenshot 3 ist die Anzeige des Clients bei der Remotedesktopverbindung? Dann war der ganze Thread bis
jetzt umsonst, denn dann ist es garantiert kein Netzwerk-Problem, sondern irgendwas im Server, zum Beispiel eine
Firewall-Reaktion.
Sorry, für die späte Antwort, aber der Screenshot kommt vom vSphereClient aus dem ESXi Server in der der Server 2003 R2 läuft.
Zitat von @dog:
Start > Ausführen > cmd >
Das bitte auf Client und auf dem Server selbst ausführen und Ergebnis posten (ja, wenn das Fenster schwarz wird ist das ein
Ergebnis).
Start > Ausführen > cmd >
telnet 192.168.111.5 3389Das bitte auf Client und auf dem Server selbst ausführen und Ergebnis posten (ja, wenn das Fenster schwarz wird ist das ein
Ergebnis).
Hallo Dog,
danke für den hinweis.
Folgende Screens sind entstanden:
Am Client:
Am Server über Konsole des vSphereClient
Sieht nicht gut aus, oder?
Gruß Kuli
Hallo Ihr Lieben,
nach endloser Suche nach dem Fehler habe ich nun endlich die Lösung gefunden.
Es hatte ein alter Administrator warscheinlich in einem alten, nicht mehr verwendetetn Router ein Port-Forwarding von WAN IP Port:3388 nach 192.168.111.5:3388 gehabt. Denn ich habe durch einen Schreibfehler in der Kommandozeile
/* telnet 192.168.111.5 3388 */ (statt der eigentlichen 9 am Ende)
herausgefunden, dass der Rechner auf den Port 3388 hört nicht auf 3389.
Demnach bin ich in die Registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp) und habe dort den Port wieder auf die 3389 gestellt und Schwupps die Wupps alles geht jetzt wie gewollt.
Dennoch danke für Eure Mühe.
Gruß Ronny
nach endloser Suche nach dem Fehler habe ich nun endlich die Lösung gefunden.
Es hatte ein alter Administrator warscheinlich in einem alten, nicht mehr verwendetetn Router ein Port-Forwarding von WAN IP Port:3388 nach 192.168.111.5:3388 gehabt. Denn ich habe durch einen Schreibfehler in der Kommandozeile
/* telnet 192.168.111.5 3388 */ (statt der eigentlichen 9 am Ende)
herausgefunden, dass der Rechner auf den Port 3388 hört nicht auf 3389.
Demnach bin ich in die Registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp) und habe dort den Port wieder auf die 3389 gestellt und Schwupps die Wupps alles geht jetzt wie gewollt.
Dennoch danke für Eure Mühe.
Gruß Ronny
