axelK77

Das Problem wurde soeben damit gelöst, das ich nochmals den RRAS konfiguriert habe - benutzerdefiniert - und neben der Funktion "Wählen bei Bedarf (Zweigstellenrouting)" auch noch NAT aktiviert habe. Anschließend habe ich unter NAT im RRAS noch die Schnittstelle konfiguriert, die die VPN-Verbindung zur Zentrale aufbaut und siehe da, ping funktioniert von allen Servern und Clients aus der Zweigstelle in Richtung Zentrale. So wollte ich das... Danke fürs Lesen und Antworten und bis neulich, axel

Hi unst, ja, prinzipiell schon. Aber eben mit Boardmitteln, die mir der RRAS bietet. Muss doch auch gehen!? Von welcher FW sprecht Ihr? Ich habe in den Netzen jeweils einen Lc 821 und 821+, die vom Hause aus kein eigenes VPN unterstützen. Gibt es noch ein Statement zu meinem letzten Beitrag bzgl des Routings? Hat noch niemand eine Standort-zu-Standort-VPN-Vernetzung mit RRAS gebaut? Im aktuellen Buch zur Technischen Referenz Networking... gibt es das 13. Kapitel, wo das beschrieben ist. Habs nur leider nicht vorliegen. Noch nicht... Hier mal meine Routing-Tabelle, wenn die VPN-Verbindung zur Zentrale hergestellt ist (sortiert nach Metrik): Ziel Netzwerkmaske Gateway Schnittstelle Metrik Protokoll x7.x23.x84.x25 255.255.255.255 192.168.10.1 LAN-Verbindung 4 6 Netzwerkverwaltung 192.168.100.0 255.255.255.0 192.168.100.70 Zentrale-VPN 6 Statisch 192.168.100.70 255.255.255.255 192.168.100.79 Zentrale-VPN 6 Netzwerkverwaltung 127.0.0.0 255.0.0.0 127.0.0.1 Loopback 51 Lokal 0.0.0.0 0.0.0.0 192.168.10.1 LAN-Verbindung 4 261 Netzwerkverwaltung 192.168.10.0 255.255.255.0 0.0.0.0 LAN-Verbindung extern VPN 261 Netzwerkverwaltung 192.168.10.34 255.255.255.255 0.0.0.0 LAN-Verbindung 4 261 Netzwerkverwaltung 192.168.10.40 255.255.255.255 0.0.0.0 LAN-Verbindung extern VPN 261 Netzwerkverwaltung 192.168.10.255 255.255.255.255 0.0.0.0 LAN-Verbindung 4 261 Netzwerkverwaltung 224.0.0.0 240.0.0.0 0.0.0.0 LAN-Verbindung extern VPN 261 Netzwerkverwaltung 255.255.255.255 255.255.255.255 0.0.0.0 LAN-Verbindung extern VPN 261 Netzwerkverwaltung 127.0.0.1 255.255.255.255 127.0.0.1 Loopback 306 Lokal

Ist das richtig, dass die im RRAS unter IPv4 eingetragene Statische Route NICHT unter "route print" angezeigt wird? Alle Server u Clients haben als Standard-Gateway den RRAS-Server eingetragen. Dieser hat im Netzwerkgerät das lokale Gateway .10.1 konfiguriert und eben diese Statische Route im RRAS. Hmmm, weiß nicht weiter, wieso das Netzwerk nicht ins Remotenetz pingen kann/darf.

Würde wie aussehen? Ich möchte das so haben, weil mir der RRAS nun mal die Möglichkeit bietet, Zwei private Netzwerke miteinander zu verbinden. Es ist ein Test, möchte es aber dann auch produktiv einsetzen, wenn es denn dann funktioniert.

Hallo, sitze gerade an der Problematik, das VPN-Routing einer Zweigstelle zur Zentrale nicht hinzubekommen. Die Zweigstelle besitzt drei 2008 Standard- Server und Clients. In der Zentrale läuft der RRAS auf 2003 SBS. Die normale VPN-Einwahl funktionert und der verbundene Server, srv03 in der Zweigstelle kann pingen, Namen auflösen etc. Auf srv03 ist ein Gerät Namens "Zentrale" als Wählen bei Bedarf eingerichtet (bzw persistent) und eine statische Route nach 192.168.100.0/24. Auf dem DHCP-Server srv02 (Zweigstelle), ist die Router-Bereichsoption für das Standard-Gateway 192.168.10.1 (Zweigstellen-Gateway zum Internet) und 192.168.10.34 (IP des srv03 als VPN-Router) eingerichtet. Ich habe es auch an srv02/04 mit ständigen Routen versucht, aber ich bekomme die Server nicht dazu bewegt, in das entfernte VPN-Netz (Zentrale) zu pingen. Firewalls stehen sicher nicht im Weg. Also das Ziel ist, dass alle Rechner in der Zweigstelle über das lokale Gateway 192.168.10.1 ins Internet kommen, ebenso wie über den VPN-Router ins entfernte Netz 192.168.100.0/24 über den VPN-Router 192.168.10.34. Zweigstelle: Gateway Internet 192.168.10.1 srv02 .10.33 AD/DNS/DHCP W2k8 srv03 .10.34 AD-Zertifikat./RRAS W2k8R2 srv04 .10.35 W2k8R2 Clients >= .10.70 Zentrale: Gateway Internet 192.168.100.1 srv01 .100.11 SBS2003 Clients >= .100.50 Wenn ich jetzt Infos vergessen habe, reiche ich die gerne nach. Danke fürs Lesen und Tipps hinterlassen schon im Voraus!! Viele Grüße, axel

Hallo Stephan, vielen Dank für Deine Antwort! Dieser Tipp war ein Volltreffer. Ich denke, dass mir diese Grundlage gerade fehlte. Allerdings ist mir das bis dato auch noch nicht passiert und ich werde es im Büro ebenfalls mit dem Rücksetzen probieren. Das NAS habe ich auch einmal durchgestartet und jetzt ist alles wieder von allen Seiten erreichbar. Das sieht gut aus und ich werde es weiter testen, ob das jetzt stabil bleibt. Wovon ich erstmal ausgehen. Nochmals recht herzlichen Dank! Jetzt kann ich mal ne Pause machen :) Grüße axel

Hallo User, möchte hier mal meine aktuellen Probleme schildern, da ich bisher noch auf keine Antwort gestoßen bin. Habe hier eine Workstation mit Vista 64Ultimate. Die läuft seit Ewigkeiten fehlerfrei (...) Ich habe den aktuellen Patchstand seit einigen Tagen und gestern passierte auf einmal, dass ich übers Netzwerk nicht mehr auf den Rechner zugreifen kann. Die Firewall ist deaktiviert, das AV-Programm habe ich die ganze Nacht laufen lassen, keine Viren, keine Trojaner, nix... Ich erinner mich nur, gestern und vorgestern mal ordentlich Defragmentierung mit O&O Pro gemacht zu haben. Warum ich die Frage stellen muss, ob es an Defrag liegen kann, dass es kein "richtiges" Netzwerk mehr gibt, liegt daran, dass ich im Büro ebenfalls mit einem Laptop mehrfach Defrag gemacht habe und das Laptop übers Netzwerk nicht mehr per Datei- und Druckerfreigabe zu erreichen ist, allerdings immer noch per ping oder RDP. Alles sehr merkwürdig. Sämtliche Software von O&O habe ich bereits deinstalliert, weil es einfach die letzte Software war, die ich installiert hatte. Aber nun? Die Diagnose von MS sagt mir auch nichts, außer "unbekannter Fehler". Von der Workstation selbst komme ich fast überall hin. Außer auf eine NAS die hier im Netzwerk rotiert, aber ansonsten funktioniert der Netzwerkzugriff. Ich habe im Augenblick keinen Ansatz, wo ich weiter nach Fehlern suchen könnte. Any suggestions? Grüße axel

Hallo zusammen, "Der Vorgang kann nicht ausgeführt werden"... im IE oder "HTTP Error 400 - Request is badly formed. (HTTP-Fehler 400 - Ungültige Anforderung.)" im Firefox sind die Fehlermeldungen, wenn ich Anlagen zu einem Posting hinzufügen möchte. Allerdings tritt der Fehler nicht überall in den ÖO auf. An sporadischen Stellen. Und in der Ereignisanzeige (Anwendung) bekomme ich folgenden Fehler: Da hilft mir eventid leider nicht wirklich weiter, oder ich steh aufm Schlauch. Das System wurde nicht speziell verändert, lediglich ein 2. Exchange wurde der Site hinzugefügt. Replikationen etc. funktionieren alle. Softwarestand ist letzter Patchstand (W2k3 Server 2003 Std SP2 und ExchEnt 2003 SP2). Mit ADSI Edit habe ich die Rechte der CN=Folder Hierarchies/ CN=Public Folders überprüft und sie scheinen dem Standard zu entsprechen. Im Moment komme ich hier nicht wirklich weiter, bzw. kann mir erklären, wieso es zu diesen Fehlern kommt. Hat hier jemand Ideen woran es liegen kann, dass Anlagen sich nicht mehr hinzufügen lassen? Auf dem 2. neuen Exchange funktioniert das Anlagen problemlos... Vielen Dank fürs Lesen, axel

Hallo zusammen, folgendes Problem versuche ich mal zu schildern: Ich habe zwei Exchange Server 2003 (SP2, gleiche Updates etc.) in einer Routinggruppe. Zweck soll sein, die Daten "von links nach rechts" zu verschieben, um auf einem Server später Srv2008/Exch2007 einzurichten. Dann sollen die Daten wieder verschoben werden und der "Übergangs-Exchange" wird wieder deinstalliert. Soweit klar... Die Replikation der ÖO scheitert mit den Fehlern auf dem Zielserver 3079 und 3089. Mit den Hinweisen auf Eventid komme ich nicht ganz zurecht und weiterführende Links beziehen sich meistens auf Exch5.5 oder 2000. Ich habe auch bereits neue DBs angelegt auf dem Zielserver, die Berechtigungen überprüft und auch Vollzugriffe vergeben, aber die Replikate kommen nicht an. Wieso werden die Replikationsvorgänge hier überhaupt über den Connector/Smarthost geschickt, wo es doch so sein sollte, dass sich die Server direkt unterhalten können per SMTP!? Oder muss ich noch einen weiteren Connector einrichten? In einer anderen Exchange-Migrations-Umgebung mit selben Aufbau, hatte es einwandfrei geklappt. Macht mich ein wenig stutzig, aber vllt. komme ich nun hier weiter... Danke fürs Lesen und im Voraus für Antworten, axel

Hallo! Das Thema wurde hier im Januar schon mal besprochen, aber eine wirkliche Lösung blieb wohl aus. Ich habe hier einen Rechner mit Vista64. Habe verschiedene VPN-Verbindungen eingerichtet. In einem Netzwerk kann ich per UNC auf Netzwerkfreigaben zugreifen, in einem anderen nicht. Der einzige Unterschied ist, dass ein Server (in dem Netz, wo es nicht geht) ein SBE2003R2 ist. Sonst sind es reine 2003er-Server. Von XP her ging es immer einwandfrei in alle Netze. Was könnte das Problem in Vista sein? Umgekehrt kann ich von dem SBE2003R2 auf Vista per UNC zugreifen... merkwürdig!? Grüße axel

Ja genau, das sollte nicht sein. Der ursprüngliche Servername sollte auch da nicht stehen. Hatte gehofft, dass so trennen zu können. Eigener Exchange für die 2. Domain wäre dann noch ne Alternative?

Hi Guenther, jetzt kann ich Dir nicht ganz folgen. Wir wollen doch nach aussen hin gar nicht mit nur einer Maildomain auftreten!? Sondern mit zweien... Habe ich DIch jetzt falsch verstanden? Der zweite Ansatz leuchtet mir ein. Gruß Axel

Hallo Leser, in der Tat wurde dieses Thema hier schon oft erfragt und erklärt. Heute stand ich auch vor der Frage, konnte sie mir aber beantworten, weil mir das Vorgehen bekannt war. Aber, ich habe hier zwei DomainPolicies bei den Empfängerrichtlinien. Dom1 und Dom2. Kann ich meinem Exchange auch mitteilen, was ja eigentlich im virtuellen SMTP deklariert ist, wie er nach aussen hin auftritt? Der virtuelle SMTP-Server ist auf Dom1 eingestellt und wenn ich mit Dom2 sende, steht im Header dennoch Dom1 als ausgehender Server. Heisst das, dass ich einen 2. MTA bräuchte? Ist das mit Exchange zu bewältigen? Zwei virtuelle Server auf Port 25 geht natürlich nicht... :) Hmm, aber ich habe ja zwei öffentliche IP-Adressen über... Dann siehts schon wieder anders aus?! Dann könnte ich den Richtlinien mitteilen, dass die eine Dom über den jeweiligen SMTP-Server senden soll und v.v.?!?? Gruß Axel

ES GEHT! Na endlich..... Unter diesem Link gibt es diese Datei. Problem erledigt. Danke Euch für Eure Beiträge!!! Bis dahin, Gruß Axel

:) ich kann dem auch langsam nicht mehr folgen, Robert... Ja, alle Dateien vorhanden und überall hinkopiert, auch ins Temp-Verzeichnis... (nein, Scherz) Nur ein Netzwerk-Chip onboard. Ich habe aktuell noch diesen Link gefunden. Mal sehen, ob der mich weiterbringt...

So, habe noch mal ein wenig getestet. Zunächst habe ich den Rechner manuell installiert und die Original-Treiber-CD von ASUS zum Board genutzt. Damit lies sich natürlich alles installieren. Auf dieser CD gibt es unter Drivers\Ethernet NUR das Verzeichnis Marvell, also dachte ich mir, aktualisierst du mal gleich mit den neuen Treibern von der Herstellerseite. Is aber nicht. Diese Treiber werden nicht akzeptiert?!?! :shock: Wie kann das denn sein? Nun ja, anschliessend habe ich dann die aktuellen Treiber von nvidia installiert, da das Board ja nun nen nForce4 Chip hat und die Netzwerkkarte Onboard im Gerätemanager "NVIDIA nForce Networking Controller" heisst und das hat funktioniert. Klar, denkt man sich. Kopiere ich aber diese Treiber zum RIS (ins Flat-Image, usw. nach \Drivers\Nic, \i386.....), funktioniert die Installation per RIS nach wie vor nicht. Angeblich keine Treiber im Image, bla bla bla... Eben wie gehabt. Also nun fällt mir nichts mehr dazu ein. Euch? In diesem Sinne, Gruß Axel

Ja Robert, hatte ich ebenfalls kopiert. Enzo, werde ich auch gleich testen... Danke Euch bis weilen...

Hat leider auch nichts beracht. Ich vermute also, ein grundlegendes Problem und sollte vllt. doch eine Neuinstallation des RIS in Betracht ziehen!? Auch wenn es mit den anderen Images klappt. Die anderen Images funktionieren auf dieser Workstation auch nicht. Also die, wo ich jetzt auch noch die Marvell-Treiber hingepackt hatte...

Sehr interessant: bei mir wird lediglich der Eintrag aus der install.osc angezeigt, nicht aber das, was man Variabel nennt. Sprich, es erscheint lediglich das hier: %SYSPREPDRIVERS% Kein Pfad o.a.. Werde die Treiber nun aber auch noch mal in die anderen Images legen......

Ich habe selbstverständlich nach jeder Änderung den Remoteinstall-Dienst neugestartet. Die Änderung an der install.osc habe ich vorgenommen, den Dienst neugestartet und dann die Workstation. Selber Fehler wie oben bereits erwähnt. Es geht nicht. Hatte vorher auch noch mal den RIS-Treiber eingepflegt, weil zwischenzeitlich noch der Nicht-RIS-Treiber von Marvell aktuell war (von anderen Tests vorher). Leider kein Erfolg bisher...

Genau die obige Fehlermeldung ist es. Und den RIS-Treiber hatte ich bereits bei Marvell gefunden und eingebunden. Er liegt in \Drivers\Nic und \i386... Aber das wird ignoriert. Dennoch die Fehlermeldung... Hmm....

Guten Morgen Robert, ich kann von der Netzwerkkarte booten und den RIS erreichen. Dort melde ich mich mit dem Admin an, wähle das Image aus, wo ich nachträglich versuche die Treiber hinzuzufügen... Dann wird mit der Rechnername zugewiesen und ich möchte die Installation starten. Das System wird nach Hardware untersucht und direkt da kommt der Hinweis, dass in dem Betriebssystemabbild keine Netzwerktreiber vorhanden sind. So siehts aus... Den anderen Images habe ich auch nachträglich noch diesen und jenen Treiber hinzugegeben und es gab keine Probleme. Deswegen wunderts mich schon, wieso diese Treiber nicht wollen. Gruß Axel

Hallo zusammen, ok, dass Ding ist mehrfach bereits besprochen worden. Ich habe sechs laufende Images auf dem RIS gespeichert und kann wunderbar unsere Laptops etc. bespielen. Ich würde behaupten, dass soweit alles rund läuft. Nur die drei Rechner mit den A8N-E-Boards eingebaut (und dem Marvell Yukon GBit-Chip und nForce4-Chip drauf) wollen nicht. Ich habe einige Artikel hier und bei MS gelesen... auf marvell.com mir die aktuellsten Treiber besorgt, wo es ja auch einen "spziellen" RIS- Treiber gibt. Ins i386- sowie ins $OEM$\$1\Drivers\Nic-Verzeichnis kopiert (auch mal die pnf-Dateien "entsorgt") und in den *.sif's den OEMPnPDriverPath auf drivers\nic eingestellt. So, wie eben auch bei den anderen Images, wo es auch noch Ordner für VGA, Audio usw. gibt. Bei diesem einen Image gibt es eben nur noch \Nic. Es geht nicht. Er findet nichts, gar nichts. Was ist an diesem Chip so besonders? Was braucht er noch? Habe hier irgendwo was von einem Textmode-Treiber gelesen!? Finde ich bei Marvell nicht. Ich habe auch mal sämtliche nv-Treiber reingeladen ins Image, aber ebenso wenig Erfolg. Ists einfacher, neue Netzwerkkarten zu kaufen, oder? Aber wenn doch der Hersteller einen RIS-Treiber anbietet, "MUSS ICH" ja irgendwo nen Fehler haben, denke ich. Nur wieso funktionieren die anderen Images....... Würde mich sehr auf Resonanz freuen. Danke!! Gruß Axel

Einen Proxy nach draußen gibt es schon. Aber ich habe Ausnahmen deklariert und es funktioniert ja auch nur bei zwei Clients nicht. Diese wurden aber identisch der Anderen installiert und konfiguriert. Und wie gesagt, laut gpresult ist auch alles in Ordnung...

Ich habe es vorhin ausprobiert und muss wohl abwarten. Bisher tauchen die Rechner nicht im WSUS auf...