none
Domäne über 2 Standorte RRS feed

  • Frage

  • Hallo,

    wir sind gerade dabei die Erweiterung einer bestehenden Domäne (2008R2 Schema) auf einen 2. Standort zu erweitern.

    Die Grundkonfiguration stellt soweit kein Problem dar. Diese würden wir wie folgt setzen:

    Domäne auf 2012 anheben

    1. Standort ein physikalischer DC mit DNS globaler Katalog und ein virtueller DC mit DNS, WINS läuft ebenfalls auf beiden DC

    2. Standort ein physikalischer DC mit DNS globaler Katalog und WINS

    Standorte sind über site2site VPN verbunden (UTM Cluster)

    Im AD wird ein neuer Standort angelegt und der neue DC von Standort 2 hinzugefügt

    Am 2. Standort arbeiten bis 20 MA. Zusätzlich dient der 2. Standort als Reserve falls Standort 1 ausfällt. Anschließend werden die Server am Standort 2 zur Verfügung gestellt. Am Standort 2 stehen die gleichen Server wie an Standort 1, jedoch nur als Reserve, nicht produktiv! Einzig ein DC ist produktiv.

    Die User am Standort 2 melden sich am 2. Standort an der Domäne an, anschließend per Remote Desktop auf den Servern am Standort 1. Wenn nun Standort 1 ausfällt, dann wandern die virtuellen Server nach Standort 2 und User von Standort 1 (ca. 100 MA) melden sich an der Domäne an (DC an Standort 1 noch verfügbar) und arbeiten per Remote Desktop an Standort 2 auf den Servern.

    Nun habe ich ein Problem mit meinen servergespeicherten Profilen, Ordnerumleitungen. Ich komme einfach nicht auf die Idee wie ich dies am Besten umsetze, denn wir gehen nun von 4 Hosts aus, deren Gäste im Fehlerfall den Standort wechseln. Das Ganze ohne Replikation, Cluster. Die Gastmaschinen sind auf einer SAN, die Standorte 2 Min von einander entfernt. Im Fehlerfall wird die SAN von Standort 1 nach Standort 2 gebracht, an die HOSTS angeschlossen und die Gastmaschinen wieder gestartet. Nun zu meinem Gedankenproblem:

    Normalzustand:

    User am Standort 2 melden sich an einem DC am Standort 2 an, Userprofile liegen am Standort 1: Nicht OK! ?

    User am Standort 1 melden sich an einem DC am Standort 1 an, Userprofile liegen am Standort 1: OK.

    Fehlerzustand:

    Server wandern nach Standort 2

    User am Standort 1 melden sich am Standort 1 an einem DC an, Userprofile liegen nun am Standort 2: Nicht OK! ?

    User am Standort 2 melden sich am Standort an einem DC an, Userprofile liegen am Standort 2: OK.

    Userprofile, Ordnerumleitungen, Homeverzeichnisse liegen auf einer Gastmaschine

    Da die HOSTS an Standort 2 lediglich eine Reserve darstellen, kann ich dort keine Server aufsetzen, die die Profildaten der User von Standort 2 hosten. Sonst wäre das kein Problem. Ich stelle mir nun die Frage wie man das Ganze vom Design löst und hoffe Jemand stand schon einmal vor einem ähnlichen Problem.

    Meine bisherigen Überlegungen:

    2. physikalischen Server pro Standort für die Profildaten. Problem hierbei wäre: Wenn ein User den Standort wechselt, dann hat man wieder das gleiche Problem.

    Profildaten spiegeln (über Nacht, wenn Niemand mehr arbeitet). Birgt aber die Tatsache eines asynchronen Spiegels.

    Die User nur noch über TS arbeiten lassen, dann hätte man das Problem nicht, jedoch ist das nicht gewünscht, da das Design der Landschaft nicht dafür ausgelegt wurde.

    Die Daten wandern lassen aber nach welchen Schema wohin?

    Zur Zeit gehe ich davon aus, dass man das Problem nicht lösen kann, eine der beiden Seiten hat immer das Problem von langen Anmeldezeiten. Außer ich würde die Servergespeicherten Profile und Ordnerumleitungen deaktivieren (leider nicht gewünscht). Jedoch glaube ich ist das größte Problem die Ordnerumleitung, jedoch nicht die servergespeicherten Profile, da die am Client doch auch noch lokal liegen.

    Mittwoch, 3. Juni 2015 16:00

Antworten

  • Moin,

    1. Die Grenze für Broadcast (dhcp) ist das Netzsegment.
      Soll der DHCP an Standort 1 genutzt werden, benötigst Du an Standort 2 ein DHCP Relay.
      Ich würde in so einem einfachen Szenario je Standort einen dhcp Server installieren.
    2. Ich würde immer die Server am Standort an die Clients verteilen. Ist am Standort nur ein DNS/WINS Server vorhanden, würde ich als zweiten Eintrag den Server eines anderen Standorts nutzen.
    3. Ja
    4. Nicht ganz egal. DNS differenziert nicht nach Standort. Beim DNS wird der erste Eintrag am Client zuerst gefragt - egal wo der erste DNS Server steht. Erst wenn der erste nicht Antwortet, wird der zweite gefragt usw.
      Die Standort-Logik greift erst bei der Verarbeitung von AD relevanten Dingen. (Anmeldung, Gruppenrichtlinien, Logonskripte, DFS usw.).

    This posting is provided AS IS with no warranties.

    • Als Antwort markiert SADFR Montag, 15. Juni 2015 16:31
    Samstag, 13. Juni 2015 05:53

Alle Antworten

  • soweit alles guter Ansatz. du musst nur ein subnetz einrichten und dem 2. Standort zuordnen. dann erkennen Clients anhand ihrer bezogenen ip an welchem Standort sie sind und melden sich dann an entsprechendem Server an.

    die user Profile koennten dann auf einem dfs Share liegen.

    Ich bin viel mobil unterwegs. Verzeiht die manchmal mangelnde Rechtschreibung. :-)

    Mittwoch, 3. Juni 2015 18:47
  • Das mit den Subnetzen wird so eine Sache für sich. Denn der 2. Standort soll ja im Fehlerfall auch der Produktivstandort werden. Im Fehlerfall müsste ich das ganze Netz wieder ändern.

    Vielleicht über DHCP lösen? Den Clients an Standort 2 auch nur die DNS Server vom Standort 2 zur Verfügung stellen?

    User Profile über DFS Share? Das ist doch nicht von Microsoft empfohlen, oder liege ich da etwa falsch? In dem Fall müsste ich doch am Standort 2 ebenfalls einen Fileserver zur Verfügung stellen. Am Besten an jedem Standort 2 physikalische Fileserver oder was meinst du? War ja eigentlich eine Überlegung von mir jedoch ohne DFS.

    Würde DFS wirklich funktionieren, habe etwas anderes gehört, wenn ich mich da nicht täusche.


    • Bearbeitet SADFR Donnerstag, 4. Juni 2015 07:02
    Donnerstag, 4. Juni 2015 07:02
  • Du kannst via Active Directory Sites+Services KEINEN neuen Standort ohne eigenes Subnetz hinzufügen.

    Aber genau das ist ja was du möchtest. Priorisiert die lokalen Ressourcen ansprechen.

    Zum Thema Profile und Ordnerweiterleitungen replizieren:

    http://blogs.technet.com/b/askds/archive/2010/09/01/microsoft-s-support-statement-around-replicated-user-profile-data.aspx


    Ich bin viel mobil unterwegs. Verzeiht die manchmal mangelnde Rechtschreibung. :-)

    Donnerstag, 4. Juni 2015 07:30
  • Du kannst via Active Directory Sites+Services KEINEN neuen Standort ohne eigenes Subnetz hinzufügen.

    Aber genau das ist ja was du möchtest. Priorisiert die lokalen Ressourcen ansprechen.

    Zum Thema Profile und Ordnerweiterleitungen replizieren:

    http://blogs.technet.com/b/askds/archive/2010/09/01/microsoft-s-support-statement-around-replicated-user-profile-data.aspx


    Ich bin viel mobil unterwegs. Verzeiht die manchmal mangelnde Rechtschreibung. :-)

    Genau, es macht ja Sinn, dass User sich standortbezogen anmelden.

    Die Replikation der Userprofile schaue ich mir mal an. Hinzu kommen noch die Homeverzeichnisse.


    Macht es denn Sinn die Userdaten direkt auf dem DC mit abzulegen, dann bräuchte ich keine weitere Hardware für die Daten?
    • Bearbeitet SADFR Donnerstag, 4. Juni 2015 07:59
    Donnerstag, 4. Juni 2015 07:58
  • Noch die eine oder andere Frage zu DHCP und WINS. Ein Subnetz wird für den 2. Standort eingerichtet, so wie du es empfohlen hast oder es auch notwendig ist. Den DC vom Standort 2 verschiebe ich in den neuen Standort im AD.

    DC am 2. Standort wird globaler Katalogserver mit DNS, DHCP und WINS. Außer es spricht etwas dagegen. Installiere ungern zu viele Services auf dem DC.

    Der WINS Server vom Standort 2 repliziert sich mit denen von Standort 1 als Replikationspartner, richtig? zu mindestens wollte ich es so einstellen. Am Standort 1 sind 2 WINS Server aktiv, die jeweils den anderen als Replikationspartner kennen.

    Wie funktioniert das mit DHCP am 2. Standort? Ich muss ja nun sicherstellen, dass alle Clients am 2. Standort auch eine IP vom DHCP am 2. Standort erhalten. Oder ich benutze den DHCP Server am 1. Standort, unsere UTM unterstützt DHCP Requests. Wie stelle ich sicher, dass die Clients am 2. Standort auch die richtigen IP's für Standort 2 erhalten? Funktioniert dies automatisch durch die AD? Wie muss ich mir das vorstellen?

    Freitag, 5. Juni 2015 07:52
  • Nun bin ich ein wenig schlauer als vorher und entschuldige mich für meine Fragen. Ich fasse noch einmal zusammen und würde gerne noch einmal ein Statement bekommen.

    Standort 1: 2 DC's mit DNS und WINS, beide GC, DHCP läuft auf einem anderen Server, Clients erhalten via DHCP Gateway, als erstes die beiden DNS und WINS von Standort 1 anschließend die von Standort 2.

    Standort 2: 1 DC mit DNS und WINS, GC. Vorab habe ich in der AD ein Subnetz und ein neuen Standort hinzugefügt, anschließend im Subnetz den Standort eingetragen. DC heraufgestuft am Standort 2.

    1. Nun überlege ich, ob ich am Standort 1 einen neuen Bereich im DHCP konfiguriere oder am Standort 2 einen eigenen DHCP aufsetze. Was würdet ihr empfehlen?

    2. Sollte ich im DHCP alle DNS Server und WINS per DHCP an die Clients weitergeben oder nur die am jeweiligen Standort?

    3. Sollte ich ebenfalls bei den WINS Servern am Standort 2 als Replikationspartner die WINS Server aus Standort 1 eintragen?

    4. Eigentlich sollte es doch egal sein welche DNS Server im Client eingetragen sind, da bei der Abfrage der Server auch der Standort mit abgefragt wird und automatisch der richtige DNS, wenn aktiv, am richtigen Standort antwortet, oder etwa nicht? Was empfehlt ihr?

    Danke schon mal und entschuldigt die Fragen, für mich ist standortübergreifend das erste Mal.


    • Bearbeitet SADFR Samstag, 13. Juni 2015 07:21
    Freitag, 12. Juni 2015 19:25
  • Moin,

    1. Die Grenze für Broadcast (dhcp) ist das Netzsegment.
      Soll der DHCP an Standort 1 genutzt werden, benötigst Du an Standort 2 ein DHCP Relay.
      Ich würde in so einem einfachen Szenario je Standort einen dhcp Server installieren.
    2. Ich würde immer die Server am Standort an die Clients verteilen. Ist am Standort nur ein DNS/WINS Server vorhanden, würde ich als zweiten Eintrag den Server eines anderen Standorts nutzen.
    3. Ja
    4. Nicht ganz egal. DNS differenziert nicht nach Standort. Beim DNS wird der erste Eintrag am Client zuerst gefragt - egal wo der erste DNS Server steht. Erst wenn der erste nicht Antwortet, wird der zweite gefragt usw.
      Die Standort-Logik greift erst bei der Verarbeitung von AD relevanten Dingen. (Anmeldung, Gruppenrichtlinien, Logonskripte, DFS usw.).

    This posting is provided AS IS with no warranties.

    • Als Antwort markiert SADFR Montag, 15. Juni 2015 16:31
    Samstag, 13. Juni 2015 05:53
  • Alles klar danke. Somit sind auch die letzten Fragen geklärt.
    Montag, 15. Juni 2015 16:30