IThome

Wahrscheinlich eine nicht für den Serverbetrieb freigegebene Fritzkarte ? Der Aussage, dass sie (wenn es eine Fritzkarte ist) tadellos funktioniert, kann ich nur widersprechen. Ganz besonders im Einsatz mit RRAS habe ich sie schon oft Probleme verursachen sehen, so ähnlich wie das, welches Du schilderst. Und genau aus solchen Gründen setze ich nur für Server geeignete ISDN-Karten ein (Dialogic) ...

Nein, es hat bewirkt, dass es nur noch eine Null-Route gibt und spielt für die Funktion keine Rolle, wenn nur ein Gateway gesetzt ist ... Ob das für Dich die optimale Einstellung ist, hängt davon ab, womit Du hauptsächlich kommunizierst, mit dem LAN oder mit dem Internet. Du hast also jetzt das falsche Gateway entfernt und die Metrik wieder auf "Automatisch" gestellt ?

Warum entfernst Du nicht einfach das vollkommen nutzlose Gateway der LAN-Karte ? Das erfüllt den gleichen Zweck, ohne die Metrikeinstellungen verändern zu müssen. Du hast durch das Verändern der Metrik einfach die Wertigkeit der LAN-Karte bzw. der Route über diese Karte verschlechtert, so dass die andere Default-Route (die funktionierende) bevorzugt wird. Das "Verschlechtern" kannst Du Dir sparen, da diese Default-Route sinnlos ist (das Gateway kann gar nicht erreicht werden) und nicht benötigt wird. Durch die Funktionsweise der automatischen Metrik bekommt die WLAN-Karte aufgrund ihrer geringeren Geschwindigkeit eine höhere Metrik als die LAN-Karte. Da Du 2 Gateways definiert hast, werden 2 Null-Routen in der Routingtabelle eingetragen. Von diesen beiden Routen, die sehr wahrscheinlich eine unterschiedliche Metrik haben, wird die "bessere" benutzt und das ist die Route über die LAN-Karte ... und die ist falsch ... In dem Falle, dass beide Karten durch die automatische Metrik den gleichen Wert bekommen haben, ist die Bindungsreihenfolge der Karten bei der Wahl der Route entscheidend. Um eine "vernünftige" Konfiguration zu haben, solltest Du die Metrik wieder auf "Automatisch" stellen und das Default Gateway der LAN-Karte entfernen. Mit ROUTE PRINT kannst Du Dir übrigens die Routen anschauen ...

Naja, Raptor und dann auch noch Softwarespiegelung ...

Was für eine ISDN-Karte ist das ?

Überprüfe mal in der Terminadienstekonfiguration die Eigenschaften des RDP-TCP Objektes. Setze dort explizit die jetzige Karte als Abhörer und starte den Server neu ...

Das Gateway bei der ersten Karte muss raus, dann klappt das. Diese Karte mit dieser Adresse könnte dieses Gateway auch gar nicht erreichen, denn es befindet sich in einem anderen Netzwerk. Wenn das Gateway vom DHCP-Server vergeben wird, musst Du dessen Optionen anpassen. In der Regel konfiguriert konfiguriert man auf einem Multihomed Host nur ein Default Gateway, es sei denn, man benötigt Fehlertoleranz (und die greift auch nur unter ganz bestimmten Umständen) ...

Poste bitte mal IPCONFIG /ALL des Rechners, wenn beide Karten aktiv sind ...

Das ist insgesamt für meinen Geschmack etwas zu viel Gewurstel. Aber ich muss das ja auch nicht verwalten ... :D

Das wär´s dann, denke ich. Allerdings sind eventuelle Auswirkungen auf den Active Directory Betrieb durch die diversen Umbiegereien nicht getestet ... ;)

... und auf dem ServerB den Regkey, sonst lässt er sich nicht ansprechen (doppelter Name im Netzwerk ...). Ich würde im Falle eines zweiten DNS ServerB als A-Eintrag und ServerA als Alias eintragen. Sind die Rechner in Subnetz 3 eigentlich auch Domänenmitglieder ?

Schau mal hier ... http://www.mcseboard.de/windows-forum-allgemein-28/2k3-auditing-110455.html Du musst am DC und den Fileservern das Auditing anschalten ...

Nö, das geht nicht, das müssen dann schon verschiedene FQDNs sein ... Das habe ich dann ja wohl missverstanden :rolleyes: Ein Name und zwei Adressen klappt nicht wegen Round Robin, Subnetmaskordering fällt auch aus ... Nä, da fällt mir nur ein weiterer DNS-Server (z.B. über Alias) ein oder verschiedene FQDNs bei gleichem Hostnamen (ist ja dann aber auch ein anderer Aufruf und sicher nicht gewünscht) ... Ich frage mich nur, warum für einen Test unbedingt der gleiche Name benutzt werden soll ...

Auch wenn es über ein Script passiert, muss derjenige, der den Key setzen will, Berechtigungen dazu haben ...

Naja, A-Einträge zufügen, den Regkey setzen, Serverdienst neu starten und dann kann ich den Server mit dem anderen Namen via \\<neuer Name> ansprechen ...

Oben ist ein kleiner Fehler in der Befehlszeile. Es muss heissen ... REG.EXE ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion" /v RegisteredOwner /t REG_SZ /d %USERNAME% /f Wie gesagt, ich habe das gerade genau so gemacht und es funktioniert ...

Hab ich auch gerade gemacht, bei mir steht dann dort der User ... Von welchem Betriebssystem reden wir denn eigentlich ?

Händisch geht das schon, aber wozu ?

Den kann man mit REG.EXE setzen, sofern der angemeldete Benutzer die Berechtigungen hat, in diesem Registry-Teil zu schreiben ... z.B. REG.EXE HKLM\Software\Microsoft\WindowsNT\CurrentVersion /v RegisteredOwner /t REG_SZ /d %USERNAME% Wenn es nicht das ist, was Du meinst, dann schildere das Problem ausführlicher ...

Denke auch daran (wichtig) ... Name resolution and connectivity issues on a Routing and Remote Access Server that also runs DNS or WINS Das mit dem RRAS ist ein ganz entscheidender Punkt, den Du uns bei der Schilderung des Problems vorenthalten hast. Wir können leider nicht hellsehen ...

Naja, nur weil der Name via DNS aufgelöst wird, heisst ja noch lange nicht, dass Du auch mit diesem Namen zugreifen kannst. Du kannst Dir zusätzliche A-Einträge erzeugen, musst dann aber auch "DisableStrictNameChecking" auf 1 setzen. Ich sehe irgendwie keinen Sinn in diesem Vorhaben ...

Einen weiteren A-Eintrag erzeugen ?! Und zusätzlich in der entsprechenden Reverse Lookup Zone eintragen. Durch das standardmässig angeschaltete Subnetmask Ordering des DNS-Servers werden dann die richtigen Ergebnisse an erster Stelle an die anfragenden Clients der verschiedenen Subnetze geliefert. Oder was genau meinst Du ?

Setz´ beim SBS mal den anderen DC als ersten und sich selbst als zweiten DNS. Beim anderen DC den SBS als ersten, sich selbst als zweiten. Mach´ den zweiten DC ebenfalls zum GC. Prüfe mit NETDIAG auf beiden DCs, ob die DNS-Einträge vollstandig sind. Probiere es dann noch mal ...

Sorge dafür, dass per VPN neben der IP-Adresse auch ein Domänensuffix verteilt wird. Entscheidend für Feststellung, ob man sich im verwalteten Netzwerk befindet oder nicht, ist der Verbindungssuffix, der bei Erstanwendung der Richtlinie gültig war. Wird kein Verbindungssuffix verteilt, wird das bei der Erstanwendung gültige Subnetz zur Feststellung herangezogen. Eventuell hast Du auch ein Problem, dass beim Starten diese Computerrichtlinie gar nicht angewendet wird, sondern erst später, nachdem die Verbindung hergestellt wurde. Mach doch einfach nach dem Herstellen der Verbindung ein RSOP.MSC, dann ein GPUPDATE und wieder ein RSOP.MSC ...

Würde mich auch interessieren ...