Jump to content

ToM-WP2K

Members
  • Gesamte Inhalte

    8
  • Registriert seit

  • Letzter Besuch

Über ToM-WP2K

  • Geburtstag 2. April

Webseite

Fortschritt von ToM-WP2K

Apprentice

Apprentice (3/14)

  • Erste Antwort
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei
  • 1 Jahre dabei

Neueste Abzeichen

0

Reputation in der Community

  1. 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
  2. Hab' die Systeme vor über nem Jahr "übernommen" und frei nach dem Motto "Never touch a running system!" auch nicht geändert.
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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.
×
×
  • Neu erstellen...