ToM-WP2K 0 Geschrieben 26. Januar 2013 Melden Teilen Geschrieben 26. Januar 2013 Hallo zusammen, nach dem ich hier im Forum schon viele hilfreiche Antworten gefunden hab' und nun vor einem Problem stehe, dessen Lösung ich bisher noch nicht gefunden hab', frag' ich einfach mal hier: Wir haben bei uns im Unternehmen eine Zentrale und eine Aussenstelle. Die zwei Standorte sind via VPN (wird zwischen zwei Watchguards aufgebaut) verbunden. In der Aussenstelle sind insgesamt 4 Clients (Win XP Prof SP3) welche über die VPN Verbindung auf einen Terminalserver (Windows Server 2008 R2) in der Zentrale zugreifen. Am Freitag vormittag hat noch alles problemlos funktioniert. Nun bin ich am Freitag, da die Filiale eine neue Verkabelung bekommen hat, zur Filiale gefahren und hab' endlich die Netzwerkkomponenten "umgebaut". Die Filiale hat einen neuen Switch (Netgear) bekommen, einen neuen AccessPoint (Cisco) und die Router und die Firewall sind endlich in den Netzwerkschrank im Keller gewandert. Ich schreib das mal etwas ausführlicher, damit man etwas besser versteht warum ich über das Ergebnis so verwundert bin: Ausstecken der 2 Router (ADSL- und SDSL-Leitung) und der Firewall (Watchguard). Anschließen der 2 Router und der Firewall im Keller im neuen Schrank und anschließen an den neuen Switch (inkl. Einschalten). Patchen der zu verwendenden Anschlüsse im Netzwerkschrank mit dem Switch. Umstecken der Clients von den alten Dosen auf die neuen Dosen. Das Ergebnis: PC 1: Ping auf die IP des TerminalServers: OK, Zugriff auf Shares des TS: OK, RDP: funktioniert nicht. PC 2: Ping auf die IP des TerminalServers: OK, Zugriff auf Shares des TS: OK, RDP: funktioniert nicht. PC 3: Ping auf die IP des TerminalServers: OK, Zugriff auf Shares des TS: OK, RDP: OK PC 4: Ping auf die IP des TerminalServers: OK, Zugriff auf Shares des TS: OK, RDP: OK An den PCs wurde nichts verändert. Ich habe vor dem Umbau gesehen das die Remote Desktop Verbindung einwandfrei funktioniert (direkt an PC 1 und an PC 2). Es wurden nur die Komponenten von einem Büro im Erdgeschoss in den Keller "verlagert". Die VPN-Strecke steht, da ja alle auf das Netz der Zentrale zugreifen können. Die Firewalls (Watchguards) sind korrekt konfiguriert, da sie ja die PCs 3 und 4 auch durchlassen (Es werden in den Logs der Firewall auch keine Blockierungen etc. angezeigt). Die Clients sind (zumindest theoretisch) auch korrekt konfiguriert, da sie ja vor dem "Umbau" problemlos funktioniert haben. Nach dem ich mich nun hier (und bei Google) verstärkt in dieses Thema eingelesen hab', hab' ich nun zur Vorsicht nochmals die aktuelle Version des Windows XP RDP Clients eingespielt, die Ports der Windows Firewall kontrolliert, das ganze mit angeschalteter und abgeschalteter Windows-Firewall probiert, die Einstellungen des RDP-Clients (mehrfach) überprüft, die Ereignisanzeige durchforstet (inkl. Löschen der Protokolle, Neustart des Rechners etc.), und und und ... und was ist das Ergebnis? Nach Klick auf "Verbinden" im RDP-Client erscheint letztendlich das Fenster mit dem Inhalt "Remotesitzung wird konfiguriert", dann läuft ca. zweieinhalb mal der blaue "Balken" durch, und anschließend bekommen ich die Meldung: "Dieser Computer kann keine Verbindung mit dem Remotecomputer herstellen." Nehm ich einen der anderen PCs klappt alles, nehm ich mein Notebook ... schwups ... und ich bin auf dem TS. Nur diese zwei verd*****n Rechner wollen sich nicht mit dem TS verbinden. Es ist auch egal, welcher Benutzer genutzt wird, egal ob ein User-Account, ein Admin-Account oder gar keine Angaben im Feld Benutzername des RDP-Clients hinterlegt werden - die Kisten brechen immer mit der obigen Meldung ab. Ich bin echt mit meinem Latein am Ende, da sich das Ganze schlicht und ergreifend meiner Logik entzieht (oder ich hab' was übersehen und seh' den Wald vor lauter Bäumen nicht). Über Hilfe und vernünftige Ansätze würd' ich mich echt freuen. ToM PS: Sollten noch weitere Angaben benötigt werden, einfach kurz Bescheid sagen. Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 27. Januar 2013 Melden Teilen Geschrieben 27. Januar 2013 Probier an den Clients ein anderes Benutzerprofil aus, alternativ auch die NIC aktualisieren bzw. tauschen. Zitieren Link zu diesem Kommentar
ToM-WP2K 0 Geschrieben 27. Januar 2013 Autor Melden Teilen Geschrieben 27. Januar 2013 (bearbeitet) Hallo Sunny61, war heut morgen per TeamViewer auf einem der fraglichen Clients und hab ein anderes Benutzerprofil (war bisher noch nicht auf dem Client vorhanden) ausprobiert: leider mit dem gleichen bisherigen Ergebnis. Momentan wird eine onboard Netzwerkkarte genutzt ... und da der Client in der Außenstelle steht wird da das Wechseln auch b***d. Wobei ... es hat ja morgens noch getan ... Klar kann auch mal ne NW-Karte abrauchen ... aber so zeitgleich? ToM bearbeitet 27. Januar 2013 von ToM-WP2K Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 27. Januar 2013 Melden Teilen Geschrieben 27. Januar 2013 Probier auf einem Problemclient ein Telnet IP-vom-TS 3389 abzusetzen, was bekommst Du als Antwort? Kannst Du dich von der Zentral per RDP auf diesen Client verbinden? Zitieren Link zu diesem Kommentar
ToM-WP2K 0 Geschrieben 27. Januar 2013 Autor Melden Teilen Geschrieben 27. Januar 2013 Hallo Sunny61, sowohl wenn ich auf einem Problemclient wie auch auf einem Testclient in der Zentrale (auf dem die TerminalServer Verbindung funktioniert) in der Eingabeaufforderung "telnet TS-Server-IP 3389" eingeb', wird das Fenster leer und es wird nur ein blinkender Cursor angezeigt (also keine Fehlermeldung). Die RDP-Verbindung test ich nachher noch. ToM Zitieren Link zu diesem Kommentar
ToM-WP2K 0 Geschrieben 27. Januar 2013 Autor Melden Teilen Geschrieben 27. Januar 2013 Hi Sunny61, mittlerweile ist der Treiber der Netzwerkkarte auch aktualisiert bzw. neu eingespielt -> Keine Veränderung - RDP geht immer noch nicht. Was allerdings seltsam ist: ich kann eine Telnetverbindung von der Zentrale auf den Problemrechner aufbauen (leeres Fenster, blinkender Cursor, keine Fehlermeldung), aber ich kann auch von der Zentrale auf den Problemclient keine RDP-Session aufbauen.Bei diesem Versuch kommt auch das kleine Fenster mit "Remotesitzung wird konfiguriert", es verschwindet und das "große" Fenster der RDP-Sitzung wird aufgebaut (mit blauem Hintergrund, ohne Icons). Dann passiert "ewig" nichts und die Session wird mit folgener Fehlermeldung beendet: "Die Sitzung von Remotedesktopdienste wurde bendet. Die Verbindung mit dem Remotecomputer wurde vermutlich aufgrund von Netzwerkkonnektivitätsproblemen getrennt." :( ToM Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 28. Januar 2013 Melden Teilen Geschrieben 28. Januar 2013 Nimm RDP in den Eigenschaften des System raus, neu starten und wieder eintragen. Was ist denn in MSCONFIG alles an Fremddiensten, bzw. Autostarteinträgen vorhanden? Im Eventlog gibt es keinerlei Fehlermeldungen? Zitieren Link zu diesem Kommentar
Dennis1Jung 0 Geschrieben 28. Januar 2013 Melden Teilen Geschrieben 28. Januar 2013 Mit was versuchst du dich den zu Verbinden? PC-Name? Oder direkt über die IP? Zitieren Link zu diesem Kommentar
ToM-WP2K 0 Geschrieben 28. Januar 2013 Autor Melden Teilen Geschrieben 28. Januar 2013 Mit was versuchst du dich den zu Verbinden? PC-Name? Oder direkt über die IP? Direkt über IP, da ich über die VPN-Strecke kein DNS-Forwarding hab'. Hi Sunny61, laut MSCONFIG wird folgendes beim Systemstart gestartet: rundll32 ftutil2.dll rundll32 ptipbmf.dll SOundman updaterui (gehört zu McAfee) SHSTAT (gehört zu McAfee) AdobeARM ctfmon Microsoft Office WinZIP Quick Pick ... zudem hab' ich vorher in der Aussenstelle noch jemanden den PC1 mit PC4 tauschen lassen (es wurde ja alles an eine neue Verkabelung angeschlossen ... und wenn es auch noch so unwahrscheinlich ist das es an der Verkabelung liegt, wenn alles andere funktioniert ... aber es kann dann zumindest ausgeschlossen werden) mit dem Ergebniss das es nicht an der Verkabelung liegt ... war ja auch nicht anders zu erwarten. :( ToM Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 28. Januar 2013 Melden Teilen Geschrieben 28. Januar 2013 Irgendeinen DNS-Server müssen die Clients doch eingetragen haben, oder wie finden die Clients sonst ihren DC? Hast Du den anderen Hinweis verfolgt? Welcher Netzwerktyp wird angezeigt? Zeig doch auch ein ipconfig /all von einem funktionierenden und einem Problemclient. Zitieren Link zu diesem Kommentar
ToM-WP2K 0 Geschrieben 28. Januar 2013 Autor Melden Teilen Geschrieben 28. Januar 2013 IP-Config von PC2 (nicht funktionierender PC) Windows-IP-Konfiguration Hostname. . . . . . . . . . . . . : GERService Primäres DNS-Suffix . . . . . . . : Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert. . . . . . . : Nein WINS-Proxy aktiviert. . . . . . . : Nein Ethernetadapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : ADMtek AN983 10/100Mbps PCI Adapter Physikalische Adresse . . . . . . : 00-30-05-BA-60-B9 DHCP aktiviert. . . . . . . . . . : Nein IP-Adresse. . . . . . . . . . . . : 192.168.20.12 Subnetzmaske. . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.20.220 DNS-Server. . . . . . . . . . . . : 194.25.2.129, 194.25.0.60 IP-Config von PC3 (funktionierender PC) Windows-IP-Konfiguration Hostname. . . . . . . . . . . . . : GEGREGER Primäres DNS-Suffix . . . . . . . : Knotentyp . . . . . . . . . . . . : Unbekannt IP-Routing aktiviert. . . . . . . : Nein WINS-Proxy aktiviert. . . . . . . : Nein Ethernetadapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Realtek RTL8168C(P)/8111C(P) Family PCI-E GBE NIC Physikalische Adresse . . . . . . : 00-24-1D-30-26-1E DHCP aktiviert. . . . . . . . . . : Nein IP-Adresse. . . . . . . . . . . . : 192.168.20.13 Subnetzmaske. . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.20.220 DNS-Server. . . . . . . . . . . . : 194.25.2.129, 194.25.0.60 Standardgateway in der Aussenstelle ist die Firewall. Diese leitet auch den ganzen Traffic der für die Zentrale ist über die VPN-Strecke via SDSL. Alles andere läuft über die ADSL-Leitung. Auch eine Änderung der DNS-Server-Einstellung auf: 192.168.20.220, 194.25.2.129, 194.25.0.60 brachte keine Änderung. Da die Clients, zumindest "lokal", produktiv genutzt werden, kann ich leider die Kisten grad' nicht neu starten, somit konnte ich dem anderen Hinweis noch nicht nachgehen. ToM Zitieren Link zu diesem Kommentar
Dennis1Jung 0 Geschrieben 28. Januar 2013 Melden Teilen Geschrieben 28. Januar 2013 Wieso nutzt der PC2 einen Hybridenknotentyp (NetBios) und der funktionierende nicht? Zitieren Link zu diesem Kommentar
ToM-WP2K 0 Geschrieben 28. Januar 2013 Autor Melden Teilen Geschrieben 28. Januar 2013 Wieso nutzt der PC2 einen Hybridenknotentyp (NetBios) und der funktionierende nicht? Hab' die Systeme vor über nem Jahr "übernommen" und frei nach dem Motto "Never touch a running system!" auch nicht geändert. Zitieren Link zu diesem Kommentar
ToM-WP2K 0 Geschrieben 30. Januar 2013 Autor Melden Teilen Geschrieben 30. Januar 2013 Hallo zusammen, hier noch ein kurzes Update zu obigem Problem: Da die zwei betroffenen Clients dieses Jahr eh für den Austausch vorgesehen waren, hab' ich parallel zur Lösungssuche die 2 neuen Clients vorbereitet. DIese wurden nun gestern getauscht. Somit läuft in der Aussenstelle nun wieder alles problem- und reibungslos. Es kann somit davon ausgegangen werden, das es weder mit der VPN-Strecke noch mit sonst einem physikalischen oder netzwerkbezogenen Problem zusammenhängt. Alleiniger Verursache dürfte also der Client selbst sein. Um dies noch zu überprüfen, werd ich nachher auch noch einen der Problemclients hier bei mir in der EDV ans Netz hängen - rein zu Testzwecken - und schauen ob ich zumindest firmenintern Zugriff auf den Terminal-Server hier im Haus bekomme (auch wenn ich es nicht glaub'). ToM Zitieren Link zu diesem Kommentar
Pyradur 0 Geschrieben 18. September 2013 Melden Teilen Geschrieben 18. September 2013 Ich hatte seit heute das gleiche Problem, nachdem ich vor 2-3 Tagen zwei PCs (den betroffenen Client und den betroffenen Host) umkonfiguriert hatte. Der PC-Name und die IP-Adresse waren geändert worden. Beim Client von Fixadresse. auf DHCP. Ich kann im Nachhinein leider nicht mehr ganz genau sagen ob obiges Problem sofort nach der Umstellung bestand, zumindest aber 2 Tage später. Der letzte Beitrag von Tom brachte mich auf die Idee die IP-Adresse des Clients zu verändern - denn das dürfte bei einem neu eingerichteten PC auch der Fall sein. Also habe ich dem aufrufenden PC (Client) wieder eine (neue) fixe Adresse verpasst und auch gleich TCP/IP Vers. 6 eingeschaltet/aktiviert, was bislang nicht der Fall war. Und sofort war alles gut... :-) Ich konnte wieder per Remotezugriff auf meinen zweiten lokalen PC zugreifen. Es war keine Portänderung/Portumleitung, wie mancherorts in anderen Foren beschrieben, auf dem Router nötig. 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.