firebb 10 Geschrieben 12. August 2015 Melden Teilen Geschrieben 12. August 2015 Hallo, ich habe bei einem Kunden ein Problem bei dem ich selbst nicht mehr weiter weiß. Es gibt einen Windows Server 2008 R2 Standard Server welcher als Arbeitsgruppenserver eingerichtet ist. Darauf ist RDS installiert mit mehreren Benutzern. Der Server besitzt zwei Netzwerkkarten welche zu einem Anschluss gebündelt sind. Das Problem, welches ich jetzt habe ist, dass ich keine RDP Verbindung mehr aufbauen kann wenn ich im RDP Fenster die IP Adresse des Servers eingebe. Gebe ich den Hostnamen, also in meinem Fall "Server", ein, funktioniert die Verbindung auf den Server. Allerdings auch nur wenn ich in dein Einstellungen der Netzwerkkarte IPv4 und IPv6 aktiviert habe. Deaktiviere ich IPv6 und lasse nur IPv4 funktioniert auch die Verbindung über den Hostnamen nicht mehr. Das ganze habe ich auch schon per Telnet getestet und versucht mittels Telnet eine Verbindung aufzubauen, da besteht das selbe Problem. Die Telnet- Verbindung wird nur mit dem Hostnamen und nicht über die IP Adresse aufgebaut. Für mich sieht es so aus, wie wenn der Server über die IP Adresse nicht gefunden werden würde. Die Windows Firewall habe ich derzeit schon komplett deaktiviert. lg. firebb Zitieren Link zu diesem Kommentar
pharao 5 Geschrieben 12. August 2015 Melden Teilen Geschrieben 12. August 2015 Was sagt denn nslookup, welche IP Adresse dem Hostnamen "Server" zugeordnet ist? Zitieren Link zu diesem Kommentar
firebb 10 Geschrieben 12. August 2015 Autor Melden Teilen Geschrieben 12. August 2015 (bearbeitet) nslookup zeigt folgendes an: C:\Users\Administrator>nslookup Standardserver: server Address: 192.168.40.9 > Hierbei handelt es sich genau um die IP welche der Server auch hat. IPConfig gibt folgendes aus: C:\Users\Administrator>ipconfig Windows-IP-Konfiguration Ethernet-Adapter LAN-Verbindung 3: Verbindungsspezifisches DNS-Suffix: Verbindungslokale IPv6-Adresse . : fe80::887d:4625:766d:cd4a%16 IPv4-Adresse . . . . . . . . . . : 192.168.40.9 Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.40.100 Tunneladapter isatap.{DE2B364E-044E-44C0-99A8-26C8F6E1A8C4}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Tunneladapter Teredo Tunneling Pseudo-Interface: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: C:\Users\Administrator>ipconfig /all Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : Server Primäres DNS-Suffix . . . . . . . : Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein Ethernet-Adapter LAN-Verbindung 3: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Gruppe: Gruppe #0 Physikalische Adresse . . . . . . : 00-19-99-E2-B5-18 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::887d:4625:766d:cd4a%16(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 192.168.40.9(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.40.100 DHCPv6-IAID . . . . . . . . . . . : 385882521 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-19-22-4E-8D-00-19-99-E2-B5-18 DNS-Server . . . . . . . . . . . : 192.168.40.9 NetBIOS über TCP/IP . . . . . . . : Aktiviert Tunneladapter isatap.{DE2B364E-044E-44C0-99A8-26C8F6E1A8C4}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter Teredo Tunneling Pseudo-Interface: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja C:\Users\Administrator> Ich habe RDS soeben neu installiert, allerdings besteht das Problem noch immer. Ich konnte mich auch nicht auf den Server verbinden als RDS nicht installiert war. Auch ein Ein- Ausschalten der RDP Verbindung in den Einstellungen, also zulassen oder verweigern, hat nichts gebracht. lg firebb bearbeitet 12. August 2015 von firebb Zitieren Link zu diesem Kommentar
pharao 5 Geschrieben 12. August 2015 Melden Teilen Geschrieben 12. August 2015 Was sagt ein "ping -a 192.168.40.9" von einem der Clients aus? Zitieren Link zu diesem Kommentar
firebb 10 Geschrieben 12. August 2015 Autor Melden Teilen Geschrieben 12. August 2015 Auf Ping Anforderungen wird ganz normal geantwortet. Ich kann ja auch auf die ganzen Netzlaufwerke zugreifen. Daher verstehe ich nicht, dass er keine RDP Sitzung aufbauen kann, wenn der Server eigentlich verfügbar ist. Zitieren Link zu diesem Kommentar
pharao 5 Geschrieben 12. August 2015 Melden Teilen Geschrieben 12. August 2015 (bearbeitet) Wie sind denn die Netzlaufwerke verbunden? Auch über den Hostnamen? Steht denn bei Ping "ping -a 192.168.40.9" in der Commandline als Antwort "Ping wird ausgeführt für Server.domain [192.168.40.9]" ...? Damit siehst du dann schon mal, ob die IP Adresse am Client auch richtig aufgelöst wird und dem "Server" gehört....und nicht etwa einem anderen Gerät im Netzwerk. Ist ne spontane Idee... EDIT: Hast du das Teaming eingerichtet bzw Änderungen an der Netzwerkkarte vorgenommen und seit dem geht es nicht mehr? LG Robert bearbeitet 12. August 2015 von pharao Zitieren Link zu diesem Kommentar
firebb 10 Geschrieben 12. August 2015 Autor Melden Teilen Geschrieben 12. August 2015 Die Netzlaufwerke sind über die IP Adresse Verbunden. Der Hostname wird Richtig aufgelöst. Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten. C:\Users\Administrator>ping -a 192.168.40.9 Ping wird ausgeführt für server [192.168.40.9] mit 32 Bytes Daten: Antwort von 192.168.40.9: Bytes=32 Zeit=31ms TTL=128 Antwort von 192.168.40.9: Bytes=32 Zeit=30ms TTL=128 Antwort von 192.168.40.9: Bytes=32 Zeit=30ms TTL=128 Antwort von 192.168.40.9: Bytes=32 Zeit=30ms TTL=128 Ping-Statistik für 192.168.40.9: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 30ms, Maximum = 31ms, Mittelwert = 30ms C:\Users\Administrator>ping -a server Ping wird ausgeführt für server [192.168.40.9] mit 32 Bytes Daten: Antwort von 192.168.40.9: Bytes=32 Zeit=30ms TTL=128 Antwort von 192.168.40.9: Bytes=32 Zeit=29ms TTL=128 Antwort von 192.168.40.9: Bytes=32 Zeit=111ms TTL=128 Antwort von 192.168.40.9: Bytes=32 Zeit=29ms TTL=128 Ping-Statistik für 192.168.40.9: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 29ms, Maximum = 111ms, Mittelwert = 49ms C:\Users\Administrator> lg. firebb Zitieren Link zu diesem Kommentar
zahni 559 Geschrieben 12. August 2015 Melden Teilen Geschrieben 12. August 2015 30ms oder länger im LAN sind viel zu lang. Ich denke, da sollte zuerst mal woanders angefangen werden. Erzähle mal ein wenig über das Netzwerk und die Hardware (Server/Client) Zitieren Link zu diesem Kommentar
firebb 10 Geschrieben 12. August 2015 Autor Melden Teilen Geschrieben 12. August 2015 In diesem Fall habe ich die Pings zwar in einem LAN gemacht allerdings handelt es sich hierbei um eine Zweigstelle welche über eine Sonicwall zu Sonicwall VPN Verbindung mit dem Netzwerk wo der Server steht verbunden ist. Dies spielt allerdings keine Rolle, da auch bei den PCs, welche im selben Netz wie der Server sind, keine Verbindung über die IP möglich ist. Zitieren Link zu diesem Kommentar
zahni 559 Geschrieben 12. August 2015 Melden Teilen Geschrieben 12. August 2015 Dann prüfe, ob der RDS-Dienste an IP4 gebunden sind. Zitieren Link zu diesem Kommentar
firebb 10 Geschrieben 12. August 2015 Autor Melden Teilen Geschrieben 12. August 2015 ok, wie mache ich das? Im Remotedesktop-Sitzungshost? Zitieren Link zu diesem Kommentar
sreiter 0 Geschrieben 12. August 2015 Melden Teilen Geschrieben 12. August 2015 (bearbeitet) Hallo! Ich habe so ein ähnliches Problem... http://www.mcseboard.de/topic/204369-windows-server-2008-r2-standard-terminalserver-rdp-funktioniert-nur-manchmal/ Hast du schon mal versucht mehrmals hintereinander mit telnet zu connecten??? CMD -> telnet 192.168.40.9 3389 Wenn "Verbindung fehlgeschlagen" kommt, dann einfach noch einmal versuchen und nocheinmal so lange bis ein schwarzes Fenster erschreint wo der Cursor links oben blinkt... dann wärest du theor. erfolgreich verbunden... Wenn das bei dir auch so ist, dann haben wir beide das selbe Problem.... das die Verbindung nur nach mehrmaligen Verbindungsaufbau korrekt funtkioniert.... Bitte probier das mal aus. LG EDIT: okay habe gerade gelesen, dass du es mit telnet eh auch schon versucht hast.... bei mir ist es nämlich so, dass es über hostname und IP nicht immer funktioniert.... also bei mir ist es egal ob IP oder hostname... naja schade bearbeitet 12. August 2015 von sreiter Zitieren Link zu diesem Kommentar
Light 12 Geschrieben 12. August 2015 Melden Teilen Geschrieben 12. August 2015 Ich hatte ein ähnliches Problem. Auch die hohen Antwortzeiten. Es lag am Teaming mit einer defekten Karte. Versuch mal das Teaming aufzulösen und einer einzelnen Karte die IP zu geben und führe den Test erneut durch. Light Zitieren Link zu diesem Kommentar
firebb 10 Geschrieben 12. August 2015 Autor Melden Teilen Geschrieben 12. August 2015 Hallo, Hallo! Ich habe so ein ähnliches Problem... http://www.mcseboard.de/topic/204369-windows-server-2008-r2-standard-terminalserver-rdp-funktioniert-nur-manchmal/ Hast du schon mal versucht mehrmals hintereinander mit telnet zu connecten??? CMD -> telnet 192.168.40.9 3389 Wenn "Verbindung fehlgeschlagen" kommt, dann einfach noch einmal versuchen und nocheinmal so lange bis ein schwarzes Fenster erschreint wo der Cursor links oben blinkt... dann wärest du theor. erfolgreich verbunden... Wenn das bei dir auch so ist, dann haben wir beide das selbe Problem.... das die Verbindung nur nach mehrmaligen Verbindungsaufbau korrekt funtkioniert.... Bitte probier das mal aus. LG EDIT: okay habe gerade gelesen, dass du es mit telnet eh auch schon versucht hast.... bei mir ist es nämlich so, dass es über hostname und IP nicht immer funktioniert.... also bei mir ist es egal ob IP oder hostname... naja schade Dieses Problem habe ich auch, allerdings bei einem anderen Kunden. Hierbei habe ich aber nicht das Problem, dass nicht gearbeitet werden kann, da dieses Phänomen erst in der Nacht auftritt. Habe dazu auch noch keine Lösung gefunden. Das selbe Problem wie Du schilderst tritt bei einem anderen Kunden täglich um ca. 23:50 auf und geht dann bis ca. 6 Uhr früh. Dort muss man auch mehrmals auch Verbinden klicken damit eine Verbindung zu Stande kommt. Ich hatte ein ähnliches Problem. Auch die hohen Antwortzeiten. Es lag am Teaming mit einer defekten Karte. Versuch mal das Teaming aufzulösen und einer einzelnen Karte die IP zu geben und führe den Test erneut durch. Light Ok, vielen Dank für den Hinweis. Das Teaming traue ich mich jetzt nicht gleich aufzulösen, da ich derzeit nur per Fernwartung auf den Server Zugriff habe und nicht beim Kunden vor Ort bin. Hatte aber auch schon diesen verdacht, dass es daran liegen könnte. Mittlerweile funktioniert die Verbindung auf den Server wieder Problemlos. Die Frage ist nur, wie lange? Kann es sein, dass es da ein Problem von Microsoft aus gibt? Es muss doch schon ein großer Zufall sein, dass zwei unserer Kunden und jemand Hier aus dem Forum mit dem selben OS fast zur selben Zeit den gleichen Fehler haben. lg. firebb Zitieren Link zu diesem Kommentar
Beste Lösung sreiter 0 Geschrieben 12. August 2015 Beste Lösung Melden Teilen Geschrieben 12. August 2015 (bearbeitet) Ich habe kein Teaming auf dem Server... nur eine einzelner Switchport von einer HP 4Gbit Lan Karte... Was ich nicht verstehe, dass wenn die Netzwerkkarte oder Kabel ein Problem haben, warum geht dann Ping, Windows-Freigaben usw. ohne Probleme? Hast du vl. auch zufällig Microsoft Security Essentials installiert??? Ich glaube echt schon langsam, dass es ein Definitionsupdate gewesen ist... Update vom 09.08.2015 oder 10.08.2015 bearbeitet 12. August 2015 von sreiter Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.