IThome

Ähm, nein, so war das nicht gemeint. Wenn von aussen zugegriffen wird, nattet der Bintec es rein. Über ihn muss es zurückgehen. Ich weiss jetzt nicht, was man bei dem Ken einstellen kann und speziell was Datevnet dazu sagt (das ist ja ein VPN, so weit ich weiss). Das Gateway des Servers muss reinnatten, dann klappt es. Oder der Server muss einen anderen Weg ins Internet gehen ...

Sicherung inklusiv Systemstatus, ADPREP /FORESTPREP, ADPREP /DOMAINPREP (wenn es ein 2003 R2 ist, von der 2. CD), dann den 2003 mit DCPROMO zum DC machen. Wenn Du genauere Lösungen möchtest, dann musst Du auch genauere Angaben machen, was Du machen möchtest ... ;)

Genau das ist das Problem, er schickt die Pakete über sein Standardgateway zurück und nicht über den Bintec, von dem sie gekommen sind. Eine Route eintragen klappt auch nicht, da die Verbindung von jeder unbekannten IP initiiert werden kann. Also eine Portumleitung auf dem eingetragenen Gateway machen und alles ist gut. Davon abhängig, wohin das eingetragene Gateway führt, könnte man auch den Bintec als Gateway eintragen und auf dem Server eine statische Route zu dem Ziel konfigurieren, zu dem das ursprüngliche Gateway führt ...

Jo, das ist Remoteunterstützung, welche bei entsprechender Konfiguration auch angeboten werden kann ...

Haben die sich mal ab- und wieder angemeldet ? Sie müssen in die Remotedesktopbenutzer auf dem Server, den sie verwalten sollen, nicht in die Gruppe Remotedesktopbenutzer auf dem DC ... Bei einem 2000 Server, der die Terminaldienste im Remoteverwaltungsmodus ausführt, gibt es das Benutzerrecht "Anmelden über Terminaldienste zulassen" nicht. Dort wird es über die Richtlinie "Lokale Anmeldung zulassen" geregelt. Bei beiden Servern muss auch im RDP-TCP Objekt in der Terminaldienstekonfiguration die entsprechende Berechtigung vergeben werden bzw. vergeben sein ...

Achso, aber bei den anderen des 129er Netzes klappt es jetzt auch ohne statische Route ?

Ist die Iseries die 17.1 ? Oder hat die Iseries die 17.1 als Gateway (dann braucht sie eigentlich keine Route, sofern diese auf der 17.1 eingetragen ist) ?

Dann sollte die Zugehörigkeit zu den Remotedesktopbenutzer ausreichen, die haben das Benutzerrecht "Anmelden über Terminaldienste zulassen". Du kannst aber mal auf diesem Server mit GPEDIT.MSC kontrollieren, ob sie dieses Recht haben oder ob Ihnen dieses Recht explizit verweigert wird ... Welche Fehlermeldung bekommst Du eigentlich ? Sind das 2000 oder 2003 Server ?

Outlook Express auch nicht ? Auch auf einem anderen Rechner nicht ?

Dann ist das ein DC, auf dem sich die Leute anmelden sollen ? Da reicht die Zugehörigkeit zu den Remotedesktopbenutzern nicht, da denen ein Benutzerrecht fehlt ...

Musst Du ja nicht ... Wenn die Clients im 129er Netz alle die 17.1 als Default Gateway haben und alle keine Route über die 23.1 in das 192.168.0.0 Netz haben, dann klappt das erstmal nicht. Ist auf dem 17.1 allerdings eine statische Route in das 192.168.0.0/24 konfiguriert, schicken die Clients das Paket erstmal zu ihrem Default Gateway. Das Default Gateway hat eine Route in das betreffenden Netz und das Paket wird ausgeliefert. Keiner dieser Clients benötigt eine statische Route, das Default Gateway (auch wenn es nicht der Router ist, der in das Zielnetzwerk routet) reicht. Auf der 192.168.0.0 Seite natürlich genauso. Entweder haben sie die Adresse des XP-Routers als Gateway eingetragen oder eine Route in das Zielnetz, beides macht keinen Sinn. Haben diese Clients ein anderes Gateway eingetragen, also nicht den XP-Router, musst Du entweder auf jedem Client eine statische Route setzen oder diese Route auf dem anderen Default Gateway (ohne auf jedem Client eine Route setzen zu müssen) ... Was ist der 17.1 eigentlich für ein Router ?

Bitte IPCONFIG /ALL und ROUTE PRINT vom 17.2 :) Oder hat der 17.2 ne Firewall an ? Da musst Du auch konfigurieren, wenn die Windows-Firewall an ist. Wenn AUsnahmen definiert sind, z.B. Datei- und Druckfreigabe, dann gilt das erstmal nur für das eigene Subnetz ...

Script ? Was für ein Script ? Wie wird es ausgeführt ? Von wem wird es ausgeführt ? Was macht es ?

Füge auf dem Gateway 129.47.17.1 eine statische Route mit dem Ziel 192.168.0.0/24, erreichbar über 129.47.23.1 zu und probiere noch mal ... Wenn das klappt, können alle im 129er Netz das 17.1 Gateway einsetzen und müssen weder das 23.1 haben, noch eine statische Route dorthin ...

Das bedeutet ja, dass das Routing grundsätzlich funktioniert. Wie sieht denn IPCONFIG /ALL und Route Print eines Clients des 129er Netzes aus, bei dem es nicht funktioniert ?

Auch die 23.1 nicht ?

Von wo aus, aus dem 192.168.0.0/24 Netz ?

Bitte noch mal ein aktuelles ROUTE PRINT vom XP-Router ...

4 Default Gateways ? Nimm erstmal alle Gateways raus und starte das Gerät danach neu ......

Hm, die Maske der Route stimmt auch nicht . Wenn das Gateway ein anderes als der XP-Router ist, muss da eine Route gesetzt werden (oder ein Schreibfehler, wie die Maske ?)

Auf dem XP-Router überhaupt keine ROUTE ADD Befehle, dort nur IpEnableRouter auf 1 setzen. ROUTE ADD Befehle oder Gatewayeinträge auf den Clients, die über den Router in das andere Netz gelangen. Also auf Client 1 : route add -p 192.168.0.0 MASK 255.255.255.0 129.47.23.1 , wenn die 129.47.23.1 als Default Gateway eingetragen ist, benötigst Du diese Route nicht. Und auf Client 2: route add -p 129.47.16.0 MASK 255.255.240.0 192.168.0.1, auch hier benötigst Du keine statische Route, wenn das eingetragene Default Gateway das Zielnet kennt . Poste mal IPCONFIG /ALL des Routers und der Clients ROUTE PRINT der Clients ...

route add -p 192.168.0.0 MASK 255.255.240 129.47.23.1 ? route add -p 192.168.0.0 MASK 255.255.255.0 129.47.23.1 ! Die permanenten Routen auf dem XP-Router solltest Du entfernen, er kennt beide angeschlossenen Netzwerke ...

Super Harry, reife Leistung und verdient, würde ich sagen, so wie Du Dich da rein hängst ... :thumb1:

Sorry, \\<FQDN des Servers> ... Lade Dir mal die Support Tools SP1 herunter und poste die Ausgabe von NETDIAG. Eventuell läuft aber auch Dein WLAN nicht richtig. Poste auch mal IPCONFIG /ALL des Servers ...

Ich nehme an, dass Du keine Reverse Lookupzone hast oder der Server keinen PTR registriert hat und die Ausgabe von NSLOOKUP deswegen so ist, wie sie ist. NETDIAG ist in den Support Tools enthalten. Kann der WLAN-Client auf den den Server via \\<Servername> zugreifen ?