johnripper 0 Geschrieben 25. November 2016 Melden Teilen Geschrieben 25. November 2016 (bearbeitet) Hallo zusammen, ich bin ja hier ein fleißiger Mitleser und habe bisher auf fast alle meine Fragen immer eine Antwort gefunden. Jetzt habe ich aber doch eine Anforderung, die ich so nicht hier gefunden habe und die auch sonst keine Antwort gefunden habe: Folgendes Szenario bzw. Topologie (vereinfacht/gekürzt) Standorte ("Site"), Subnetze (Erläuterung) DESTL: 10.0.0.0/8, 192.168.1.0/24 (Hauptstelle) DEFRA: 192.168.2.0/24 (Außenstelle 1) DEMAN: 192.168.3.0/24 (Außenstelle 2) DEBER: 192.168.4.0/24 (Außenstelle 3) ... Die vorgenannten Netze sind physisch an unterschiedlichen Ort. Jeder physische Ort ist ebenfalls im AD als ein Standort ("Site") eingerichtet und via Subnetz identifiziert. Die Netze sind physisch über VPN-Verbindungen wie folgt verbunden: DESTL <-> DEFRA DESTL <-> DEMAN DEFRA <-> DEMAN DESTL <-> DEBER DEFRA <-> DEBER Jede Außenstelle (außer Außenstelle 1) also immer mit der Hauptstelle und der Außenstelle 1 verbunden. Außerdem ist natürlich die Hauptstelle mit der Außenstelle 1 verbunden. Das Routing folgt dem, also jede Nebenstelle (außer Außenstelle 1) geht immer direkt zur Hauptstelle oder direkt zur Außenstelle 1, wobei Haupt- und Außenstelle 1 ebenfalls geroutet sind. Der Traffic läuft also entweder direkt an Außenstelle 1 oder via Hauptstelle an die entsprechende nicht direkt verbundene Nebenstelle. Im AD sind die Standorte derzeit über einen großen Standortlink verbunden. Domain Controller sind derzeit wie folgt aufgestellt DC01 in DESTL DC06 in DESTL DC10 in DEFRA Man sieht: An einem Standorten sind zwei Domain Controller an machen nur einer und an vielen keiner. Was ich jetzt will: Wie kann mein AD dazu bewegen, dass die Clients nach der folgenden Logik anmelden: - in der Hauptstelle: Primär am DC01, sekundär am DC06, dann an jedem anderen - In der Nebenstelle 1: Primär am DC10, dann an jedem anderen (bzw. wahlweise an DC01/DC06) - In allen anderen Nebenstellen: Primär am DC01/DC06, dann an jedem anderen (bzw. D10) (Nach der Logik werden auch die DNS Server via DHCP vergeben). Was ich will dürfte klar sein: - Die Hauptstelle soll sich zuerst am lokalen DC(01/06) anmelden und dann ggf. an dem DC(10) in der Außenstelle 1 - Die Außenstelle 1 soll sich zuerst am lokalen DC(10) anmelden und dann ggf. an dem DC(01/06) in der Hauptstelle - Jede andere Außenstelle soll sich zuerst am Haupstellen DC(01/06) anmelden und dann ggf. an dem DC(10) in der Außenstelle 1 Derzeit sehe ich DNS, dass der Netlogon Dienst irgendwas einrichtet, aber ich habe keine Ahnung nach welcher Logik. Hoffe die Anforderung ist soweit klar und jemand kann mir eine Tipp geben. Danke JR bearbeitet 25. November 2016 von johnripper Zitieren Link zu diesem Kommentar
NilsK 2.958 Geschrieben 25. November 2016 Melden Teilen Geschrieben 25. November 2016 Moin, deine Standort- und Subnetz-Zuordnung sieht schon ganz passend aus. Damit die Clients wissen, wo sie sich anmelden müssen, ist zweierlei nötig: die Clients müssen sich in dem Subnet befinden, das im AD ihrem Standort zugewiesen ist der jeweilige DC muss auch im DNS seinem Standort zugeordnet sein Der zweite Punkt ist manchmal nicht gegeben. Das kann passieren, wenn ein neuer DC zunächst am Hauptstandort installiert und dann nachträglich in die Ziel-Site verschoben wurde. In dem Fall passen meist die DNS-Einträge nicht, und man muss sie manuell nachtragen. Dann ist natürlich allgemein die DNS-Client-Konfiguration zu beachten: [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net]http://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Und schließlich solte die Replikationstopologie der tatsächlichen Netztopologie entsprechen. Du gibst an, dass das Routing bei euch eingeschränkt ist und kein vollvermaschtes WAN vorliegt. Dann solltest du die Standorte auch nicht über den Default-Link verbinden, sondern die tatsächlichen Verbindungen mit Sitelinks abbilden. Sofern das Routing tatsächlich durch Firewalls oder technische Maßnahmen eingeschränkt ist, musst du außerdem das "Automatic Site Link Bridging" abschalten, damit die AD-Replikation sich nicht über die Wunsch-Topologie hinwegsetzt. Gruß, Nils Zitieren Link zu diesem Kommentar
johnripper 0 Geschrieben 25. November 2016 Autor Melden Teilen Geschrieben 25. November 2016 Danke soweit mal. Jedoch habe ich noch eine Frage zu den folgenden Ausführungen: der jeweilige DC muss auch im DNS seinem Standort zugeordnet sein Der zweite Punkt ist manchmal nicht gegeben. Das kann passieren, wenn ein neuer DC zunächst am Hauptstandort installiert und dann nachträglich in die Ziel-Site verschoben wurde. In dem Fall passen meist die DNS-Einträge nicht, und man muss sie manuell nachtragen. Was heißt, dass jeder DC im DNS an seinem Standort zugeordnet sein soll? Meinst du die SRV, A und CNAME Einträge. Dies setzten die DC ja nach einem Netlogon Start automatisch nach einer Logik die ich irgendwie nicht nachvollziehen kann. Bspw1 trägt sich an der Außenstelle 1 als einiger Server der DC an der Außenstelle ein. Eigentlich logisch, aber natürlich will ich als Failover für die Clients auch die Möglcihkeit DC an einem anderen Standort zu nehmen. Bspw2: An der Außenstelle 2 werden als DC immer die beiden DC der Hauptstelle eingetragen. Um eine gewisse Ausfallsicherheit zu gewährleisten, auch weil die Standorte teilweise nur über VPN-Verbindungen verbunden sind, möchte ich natürlich entweder Zugriff auf einen DC an der Hauptstelle oder eben einen DC an der Außenstelle 1. Zitieren Link zu diesem Kommentar
daabm 1.366 Geschrieben 26. November 2016 Melden Teilen Geschrieben 26. November 2016 Wie Nils schon schreibt: In Sites und Services sollten die Standorte, Subnetze und Site Links der tatsächlichen Konfiguration entsprechen. Und dort solltest Du auch prüfen, daß die DCs in den Sites aufgeführt werden, in denen sie tatsächlich sind. Über die Site Link Costs kannst Du ggf. sogar noch eine Priorisierung umsetzen. Zitieren Link zu diesem Kommentar
johnripper 0 Geschrieben 26. November 2016 Autor Melden Teilen Geschrieben 26. November 2016 (bearbeitet) Wie Nils schon schreibt: In Sites und Services sollten die Standorte, Subnetze und Site Links der tatsächlichen Konfiguration entsprechen. Und dort solltest Du auch prüfen, daß die DCs in den Sites aufgeführt werden, in denen sie tatsächlich sind. Über die Site Link Costs kannst Du ggf. sogar noch eine Priorisierung umsetzen. Wie schon gesagt: Standorte, Subnetze und Sites sind korrekt. Die DC tragen sich auch an den entsprechenden Sites ein. Aber nochmal anders erklärt: Bspw steht in Außenstelle 1 ein DC (DC10). Dieser ist in der Site DEFRA (Außenstelle 1) auch korrekt zugeordnet. Der DC10 sieht sich auch in der Site DEFRA (Außenstelle 1) korrekt (geprüft mit gpresult /R) Im DNS trägt er sich unter der Site auch als GC, LDAP, usw. ein. Aber eben nur sich. Natürlich will ich aber, dass ein Client an der Site DEFRA (Außenstelle 1) sich zuerst am DC10 und dann natürlich an den anderen DC versucht anzumelden. Was ich nicht will ist, dass ein Client bei Nicht Verfügbarkeit von DC10 die Anmeldung zurückweist. Ergo muss ich doch in der Site DEFRA (Außenstelle 1) neben dem DNS Eintrag von DC10 auch bspw. DC01 eingetragen sein. Das versuche ich dem System klar zu machen...klappt nur nicht. bearbeitet 26. November 2016 von johnripper Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 26. November 2016 Melden Teilen Geschrieben 26. November 2016 (bearbeitet) Moin, mein Gedanke, wie schaut es denn mit den DNS-Einträgen an den Clients der Aussenstelle aus? Und, erreicht der Client bei Ausfall des Dc10 denn den alterntiven DC/Anmeldeserver und DNS? bearbeitet 26. November 2016 von lefg Zitieren Link zu diesem Kommentar
NilsK 2.958 Geschrieben 27. November 2016 Melden Teilen Geschrieben 27. November 2016 Moin, jeder DC ist in DNS nur der Site zugeordnet, an der er sich wirklich befindet. Bring das AD und die Clients nicht durcheinander, indem du willkürlich weitere EInträge vornimmst! Das Failover auf einen anderen Standort geschieht automatisch, wenn am eigenen Standort kein DC antwortet. Wenn du willst, kannst du dieses Verfahren anmelden, um den Failover auf einen anderen DC zu steuern. Das setzt aber voraus, dass die Site-Konfiguration minutiös aufgebaut und korrekt ist. [Enabling Clients to Locate the Next Closest Domain Controller]https://technet.microsoft.com/en-us/library/cc733142(v=ws.10).aspx Gruß, Nils Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.