IThome

Schau mal in die Bereichsoptionen des konfigurierten Bereiches im DHCP-Manager ...

Und Rayman´s Raving Rabbits oder Mario & Sonic bei den Olympischen Spielen ? Noch 4 Wochen intensives Spielen und ich brauche keinen Wagenheber mehr zum Reifenwechseln :D

Der eigentliche Updatevorgang dauert vielleicht 15 Minuten, der Test, ob alles funktioniert, ungleich länger ...

Eigentlich beim Zugriff ...

Hi Mcseboard, oh Mann, hätte ich meinem Sohn bloss nicht die Wii-Spiele zu Weihnachten geschenkt. Das Schenken alleine ist zwar noch nicht schmerzhaft, aber ich musste ja unbedingt stundenlang mitmachen. Jetzt hab´ ich den wahrscheinlich schlimmsten Muskelkater meines Lebens :D Gruss Sven

Das Standardgateway ist falsch, die Clients bräuchten ein Gateway, um zum konfigurierten Gateway zu gelangen. Die SUbnetzmaske stimmt auch nicht, es muss eine 24er Maske sein und keine 8er. Sonst sieht es okay aus ... edit: das mit dem Gateway zum Gateway stimmt mit dieser Maske nicht, da die Netze 192.168.1.0/8 (eigentlich 24) und 192.168.2.0/8 (eigentlich 24) sich im gleichen Bereich befinden. Ändere also Default Gateway auf 192.168.1.1 und die Maske auf 255.255.255.0 ...

Sieht erstmal gut aus. Der Server kann ja in´s Internet, also ist es auch nicht verwunderlich, dass er die Namen für den Client auflösen kann. Was hast Du verstellt und wieder zurück gestellt ? Die Basisfirewall des Servers ist wahrscheinlich nicht das Problem, da sie nur auf der externen Schnittstelle wirkt. Hast Du eventuell Paketfilter im RRAS definiert ? NAT oder nicht ?

Kenne ich nur von NT 4 ...

Wie ist der Server denn konfiguriert ? Als NAT-Router ? Stellt er selbst die PPPoE-Verbindung her oder ist er direkt mit einem Router verbunden ? Poste bitte mal IPCONFIG /ALL des Servers bei bestehender Verbindung ... "Server unknown" lässt auf eine nicht vorhandene Reverse Lookupzone schliessen ...

Die Standardrichtlinien kannst (und solltest) Du mit DCGPOFIX neu erstellen. Schaue Dir die Parameter dieses Befehls an und erzeuge nur die neu, die Du neu erstellt hast (Default Domain Policy und/oder Default Domain Controllers Policy). Danach musst Du noch das Exchange-Setup mit dem Parameter /Domainprep ausführen ...

Da hast Du recht, Edgar ... Und frohe Weihnachten ... :)

Es ist nicht nur besser, sondern es funktioniert anders nicht. Gruppenrichtlinien wirken nicht auf Gruppen, sondern auf Benutzer- und Computerobjekte. Diese Objekte müssen sich dort befinden, wo die GPOs gelinkt sind oder darunter (Benutzerobjekte, wenn im Benutzerteil konfiguriert wird und Computerobjekte, wenn im Computerteil konfiguriert wird). Eine Ausnahme ist hierbei die Loopbackverarbeitung. Gruppen werden zur Sicherheitsfilterung eingesetzt ... Also eine OU-Struktur erstellen, die entsprechenden Richtlinien für Benutzer/Computer, Benutzer und Computer in die entsprechenden OUs verschieben und die GPOs linken. Eine zweite Möglichkeit wäre, eine Richtlinie "hoch" zu platzieren und sie dann sicherheitsfiltern (mit den Gruppen, die angelegt wurden) ...

Verstehe ich nicht ... Gruppe Server, Gruppe Rechner, Gruppe Mitglieder ? Richtlinien Container ? Beschreibe, wie Deine OU-Struktur aussieht, welche Objekte sich in welcher OU befinden, wo die GPOs gelinkt sind und ob sie sicherheitsgefiltert sind ... Ach übrigens ... Gruppenrichtlinien beziehen sich NICHT auf Gruppen (es erscheint zumindest so, als hättest Du das Konzept missverstanden) ...

Dann sollte es mit der Namensauflösung kein Problem geben. Kannst Du die Server mit PING <FQDN> erreichen ?

Die Einträge sind fast identisch, aha, und wie sind die Einträge ? Wie sind die Clients gecloned worden ?

Welchen DNS-Suffix haben die VPN-Clients ?

Was hast Du denn alles in die HOSTS geschrieben ? Du musst in Deiner Konstellation auch den Exchange und alle anderen, internen Server in die HOSTS schreiben. Wie werden die Server angesprochen (mit dem FQDN ?) und welche DNS-Suffixe haben die Clients ?

Warum hat der RRAS 2 Default Gateways ? Wer hat die 149.247.151.230 und 149.247.151.231 ? Wo soll der VPN-Client überhaupt hin (in das 192.168.1.0 oder 192.168.100.0 Netz) ? Kommt der RRAS selbst da hin, wo der VPN-Client hin soll ? Kommt der Client auf einen anderen Host im 149er Netz ? Wenn der Client in eines der 192er Netze soll, hat der RRAS keine Route dorthin, sofern sie nicht statisch zugefügt wurde ...

Weil bei JEDER Einwahl auf JEDEM RRAS-Server ein Client solch eine Subnetzmaske bekommt (es sind wie schon gesagt PPP-Verbindungen) ... Also , schildere die Gegebenheiten mit allen, eventuell nützlichen Angaben (muss ja nicht Deine gegenwärtig vergebene Adressierung sein, dann aber sinngemäss), dann können wir besser helfen. IPCONFIG /ALL der beteiligten Rechner (RRAS und VPN-Client bei bestehender Verbindung und einer der Hosts, der erreicht werden soll) hilft sehr ...

Die 32er-Maske ist sicher nicht das Problem, da es eine PPP-Verbindung ist, die aufgebaut wird. Ich denke da eher an ein Routing-Problem. Schildere also möglichst genau, wer wohin soll, wer welches Gateway hat, am besten mit der Ausgabe von IPCONFIG /ALL des RRAS und eines VPN-Clients bei bestehender Verbindung und eines Rechners, der vom VPN-Client erreicht werden soll ...

Damit wird das Caching eingestellt, stelle es also so ein, dass für Netzwerkanwendungen optimiert wird (kleiner Dateicache) ...

Poste doch einfach mal IPCONFIG /ALL der Server und eines fehlerhaften Clients. Was ergibt NETDIAG und DCDIAG auf den DCs ? Du hast von Images gesprochen, sind die Rechner oder Server gecloned worden ?

Die Regkeys haste ja, da die NTUSER.DAT immer übertragen wird. Entscheidend ist, ob Du z.B. Anwendungen hast, die etwas in "Lokale Einstellungen" ablegen, wie z.B. Outlook Express oder Outlook ohne Exchange ...

Das wird schwierig, da das UMTS Interface dynamisch ist ...

Serverbasierte Profile ?!