Primäre DCs für versch. Standorte festlegen

[liveticker 0]

Hallo zusammen,

 

ich fange direkt einmal mit der Problembeschreibung an...

 

Standort 1 = Deutschland

Standort 2 = Deutschland

Standort 3 = Russland

 

Ich habe drei verschiedene Standorte (2x Deutschland verbunden durch MPLS/Vodafone WAN und einen in Standort in Russland verbunden durch SonicWALL Site-2-Site Tunnel).

An Standort 1 gibt es den DC01 und den VM-DC01, Standort 2 lediglich DC02, Standort 3 DC03 und VM-DC03.

Entsprechende drei Subnetze.

 

Das Problem ist, dass das Logon der Clients in Deutschland, tatsächlich mit dem DC03/VM-DC03/VM-DC01 von statten geht. (nicht immer der Falle aber ab und an kommt es vor)

Das ist natürlich absoluter Käse, zumal die Replizierung unter DCs ja keine Live-Synchronisierung ist (das ist jetzt nur ein negativer Nebeneffekt, es gibt noch mehr...).

Kann ich standortbezogen primäre Domaincontroller festlgen?

Sprich alles was Standort 1 ist -> DC01/VM-DC01, Standort 2 -> DC02/DC01/VM-DC01, Standort 3 DC03/VM-DC03.

Betriebsmaster ist der DC01 es gibt ausschließlich eine Domäne mit wie gesagt drei Standorten.

 

 

Braucht ihr weitere Informationen?

Ich stehe da derzeit noch auf dem Schlauch.

 

 

Mit freundlichem Gruß! :)

bearbeitet 16. März 2017 von liveticker

[testperson 1.674]

Hi,

 

also wenn alles korrekt konfiguriert ist, sprich die Subnetze sind dem korrekten Standort zugewiesen, dann sollte dein gewünschtes Verhalten automatisch so ablaufen.

Gibt es Meldungen im Eventlog des Clients?

Wie heißen deine Standorte?

 

Gruß

Jan

[NilsK 2.930]

Moin,

 

Kann ich standortbezogen primäre Domaincontroller festlgen?

 

"primäre" nicht, aber wie Jan schon richtig sagt, ist genau dafür das Standort-Konzept in Active Directory da:

• definiere Standorte
• weise die DCs den jeweiligen Standorten zu
• weise die Subnets den jeweiligen Standorten zu

Im Prinzip ist das alles. Die DCs sollten ihrerseits auch aus dem jeweils passenden Subnet kommen, das ist aber nicht zwingend.

 

Sofern die DCs nicht von vornherein am passenden Standort installiert wurden, kann es sein, dass sie sich im DNS falsch eingetragen haben. Das wäre also zu kontrollieren. Steht ein DC im DNS für den falschen Standort drin, dann löschst du den Eintrag dort und führst eine Neuregistrierung durch:

net stop netlogon
net start netlogon
ipconfig /registerdns

Wichtig ist natürlich auch, dass die Clients auch den passenden Subnets angehören, sonst suchen sie sich "irgendeinen" DC.

 

Gruß, Nils

[liveticker 0]

Ja also wenn ich mir die Eigenschaften der Subnets anschaue ist bei allen drei der richtige Standort eingetragen.

Gegenprobe: Eigenschaften auf die drei Sites dort ist auch das entsprechende Subnet eingetragen.

 

Die Namen der Sites sind jeweils die Namen der Städte der Standorte.

 

Keine passenden Ereignisse lassen sich in der Ereignisanzeige finden.

Ich denke aber schon auch eher in die Richtung Konfiguration der Standorte.

Gibt es da noch den ein oder anderen Kniff?

 

Die DNS Einstellungen checke ich nochmal ab, aber da sollte alles passen.

bearbeitet 16. März 2017 von liveticker

[testperson 1.674]

Die Standorte fangen nicht zufällig zur besseren Sortierung mit Zahlen an: https://www.faq-o-matic.net/2012/10/31/ad-standorte-namen-drfen-nicht-mit-ziffern-beginnen/

[v-rtc 88]

Hast Du schon eine Weile gewartet? Weil wie Du sagst, ist es ja kein Live-Sync.

 

Bei uns hat es eine ganze Weile gedauert, bis alles so war, wie es konfiguriert und gedacht war. 

bearbeitet 16. März 2017 von RolfW

[liveticker 0]

Ja also konfiguriert ist das jetzt schon seit ca. 2 Monaten.

Die Standorte nennen sich wie schon gesagt nach der Stadt der Niederlassung, wobei es beim DC03 ein ß im Standortnamen gibt.

 

Ich habe jetzt gerade nochmal nachgescahut nach den Subnets.

Für den Standort 1 ist ein klassisches B-Netz eingetragen 172.16.0.0/16

Wobei die Subnetmask aber eigentlich /20 sein müsste da wir über zwei VLANs am Standort 1 verfügen.

 

Ich kann mir denken, dass Clients die aus der /16 Maske rausfallen demnach nicht zugeordnet werden können und sich an irgendeinen DC wenden.

Bei allen Clients am Standort 1 ist nämlich /20 drin als Subnetmask.

 

Könnte es (im Idealfall) jetzt schon daran liegen?

Im Subnet steht derzeit noch /16 drin weil es vor langer Zeit eben keine VLANs am Standort 1 gab und es gleich mit den anderen Standorten (172.17.0.0/16, 172.19.0.0/16).

Man müsste das doch jetzt anpassen und aus /16, /20 machen?

[NilsK 2.930]

Moin,

 

die Subnet-Angabe im AD muss nicht exakt der im Netzwerk entsprechen. Das AD vergleicht die IP des Clients mit den Subnet-Angaben und entscheidet daran, wohin der Client gehört. Wenn es also mehrere "reale" Subnets zu einem "logischen" AD-Subnet gibt, ist das OK, solange diese zum selben Standort gehören. Nur echte Überschneidungen darf es nicht geben.

 

Clients, deren IP-Adresse nicht zu einem definierten Subnet passt, suchen sich irgendeinen DC. Das würde zu dem beobachteten Phänomen passen. Die DCs führen ein Log über Clients, die sie nicht zuordnen können, Hinweise darauf gibt es im Eventlog.

 

Gruß, Nils

[liveticker 0]

Okay, also ich habe jetzt mal die 172.16.0.0/16 durch 172.16.0.0/20 ersetzt.

Mal sehen was passiert ^_^

Die Netzwerkadressen und Einstellungen der Clients passen an allen Standorten zu 100%.

 

Ich verfolge jetzt mal diverse Netlogons bei den Clients, sollte sich das Phänomen gelöst haben, dann werde ich (sofern ich daran denke, ich geb' mein Bestes) hier im Thread das Ganze mal bestätigen, für die Nachwelt. :thumb1:

 

Sollte noch jemand Ideen zu dem Thema haben trotzdem her damit, ich freue mich über jeden Gedanken.

[Squire 260]

Die Clients die irgendwo an einen DC gehen sind aber nicht zufällig via VPN eingewählt? Wenn ja, dann muss auch das jeweilige VPN Netz dem jeweiligen Standort zugewiesen werden