Client melden sich am falschen DC an

[bertl81 10]

Hi !

 

Ich hab folgendes Problem und hoffe ihr könnt mir weiterhelfen.

 

In unserem Unternehmen gibt es 2 Standorte - Vienna und Prag.

Die Subnetze sind dem jeweiligem Standort zugeordnet.

 

Meistens melden sich die Clients aus Vienna auch in Vienna an, aber manchmal auch in Prag. Das ist natürlich nicht so toll, da es zwischen den beiden Standorten nur eine 2mbit Leitung gibt.

 

Ich muss auch noch dazusagen das es bis vor kurzem zwar die zwei Standorte gab.

Aber die Standorte nicht im AD konfiguriert waren.

Das heist es hat im AD nur einen Standort gegeben.

Ich hab also die zwei Standorte im Ad angelegt und die Subnetze dem jeweiligem Standort zugewiesen.

Hab ich da noch irgendwas vergessen ?

 

lg

bertl

[dippas 10]

Hab ich da noch irgendwas vergessen ?

 

Sind beide DCs auch GC?

 

DNS etc. passt aber soweit? Und er Server in Vienna (Wien?) ist auch nicht überbelastet?

 

grüße

 

dippas

[bertl81 10]

Hi !

 

Es gibt auf jedem Standort 3 DC's die auch GC's sind.

Sollte nicht ein anderer DC am gleichen Standort benutzt werden wenn einer überlastet ist ?

 

DNS denke ich das er passt, wir hatten noch keine Probleme...

Muss ich denn im DNS etwas ändern wenn ich Standorte einrichte ?

[dippas 10]

Normalerweise reicht ein GC je Standort.

 

Aber es ist schon richtig, das der Client zunächst die Server im eigenen Netz aufsuchen sollte und erst, wenn er diese nicht im entsprechenden Zeitrahmen erreicht, dann geht er in ein anderes Subnetz.

 

Bezüglich DNS bleibt die Frage, ob auch dort die Zonen alle drin sind (Forward und Reverse) und ob auf die Serverrollen richtig eingetragen sind.

 

grüße

 

dippas

[bertl81 10]

Das mit den 3 DC's je Standort ist wegen der Redundanz.

Aber egal das ist jetzt nicht das Problem...

 

Im DNS sind die Forward und Reverse Zonen richtig eingetragen.

Was mir etwas komisch vorkommt ist das in der Forward Zone unter der Doamin -> _sites zwar die beiden Standorte eingetragen sind, aber auch ein Ordner mit dem Domainnamen.

Stimmt das so ?

 

In den Sites selber gibt es dann jeweils einen _tcp Folder in dem die Server vorhanden sind, die miteinander replizieren.

[dippas 10]

Das mit den 3 DC's je Standort ist wegen der Redundanz.

 

Die Sache mit den 3 DCs ist ja in Ordnung, allerdings brauchen/sollten nicht alle 3 auch GC sein. Das meine ich.

 

Im DNS hast Du normalerweise unter der Forward-Zone stehen:

 

_msdcs.domainname.tld mit weiteren Unterordnern, z.B. dc oder gc usw.

 

sowie

 

domainname.tld mit Unterordnern wie _sites oder _tcp etc.

 

Das im DNS unterhalb des Baums "Forward-Lookup-Zone/domainname.tld" nochmal der Domainname als Ordner auftaucht, ist so nicht ganz in Ordnung. Das sich daraus ergebene Konstrukt "Forward-Lookup-Zone/domainname.tld/domainname.tld" sollte mal überprüft werden.

 

grüße

 

dippas

[bertl81 10]

Vielleicht hilft es wenn ich mal ein bild hochlade...?

 

[dippas 10]

Na, das sieht schon verständlicher aus.

 

Die eingetragenen Namen "Vienna" und "Prag" sind in diesem Falle nicht die Bezeichnungen von Domänen, sondern die Namen, welche bei AD-Standorten vergeben wurden. Bei einem nicht geänderten Standortname stünde dort "Standardname-des-ersten-Standorts".

 

Wir sind uns aber definitv einig, das DNS und WINS ordnungsgemäß funktionieren (Replikation, Registrierungen etc.)?

 

Tja, nun aber zu Deinem "Problem":

 

Von der Vorgehensweise der Anmeldung läuft es normalerweise so ab, das der Client sich den nächstbesten GC schnappt und sich an diesem anmeldet. Dazu wird DNS entsprechend geprüft ("wer ist hier GC?").

 

Die Antwort wird in die Registry der Clients geschrieben und die Anmeldung erfolgt nun.

 

Hat jetzt der Client einen anderen GC intus, der nicht im eigenen Subnetz steht, versucht er zunächst auch immer wieder diesen GC zu erreichen.

 

"Normalerweise" wird aber der Client darauf aufmerksam gemacht, das der GC in seiner Registry nicht wirklich derjenige ist, der in seinem Subnetz steht. Klappt alles, wird der Registry-Schlüssel mit dem Wert der "vor-Ort-GC" überschrieben.

 

Wünschenswert wäre nun eine Lösung, die z.B. via GPO auf Ebene einer OU (z.B. OU "Vienna") den dort versammelten Clients eine "Abfragereihenfolge" für GCs unterjubeln könnte. Also sinngemäß "Frag erst den GC in Vienna und wenn Du den nach zwei/drei Versuchen nicht bekommst, frag andere GCs"

 

Aber genau da bin ich mir (ziemlich) sicher, dass das nicht geht.

 

Ich glaube, dass es nicht bestimmbar ist, an welchem GC sich der Client nun tatsächlich anmeldet.

 

Deshalb würde ich gerne das Wort an Grizzly weitergeben. Sorry

 

grüße

 

dippas

[Christoph35 10]

Bin zwar nicht der Grizzly aber vielleicht darf ich auch kurz meinen Senf dazugeben :D

 

Es kann (in gewissem Rahmen) schon bestimmt werden, welchen DC ADClients zum Anmelden auswählen. Und zwar wird das über die Priority- und Weight-Werte in den SRV Records geregelt. Normalerweise wird daran allerdings nicht gedreht.

 

Siehe z.B. hier

Creating an Active Directory Site for Exchange Server

(etwas unterhalb der Mitte).

 

Ich habe das selbst noch nicht ausprobiert, wie sich das auswirkt. Für die praktische Erfahrung gebe ich hier auch das Wort gerne an Grizzly weiter.

 

Christoph

[Das Urmel 10]

OK, bin zwar auch nicht Grizzly, aber auch manchmal bissig ;)

 

Ich würde mal in das Snapin Active Directory-Standorte und Dienste schauen, dort die Standorte definieren, die DC's dahin verschieben und mal abwarten.......

was Grizzly da so ergänzen wird. :)

[Christoph35 10]

Hat er schon gemacht ;)

 

Ich hab also die zwei Standorte im Ad angelegt und die Subnetze dem jeweiligem Standort zugewiesen.

Hab ich da noch irgendwas vergessen ?

 

Christoph

[twenty 12]

Snapin - Active Directory-Standorte und Dienste

 

Du solltest die Domaincontroller noch in die richtigen Standortordner verschieben.

[bertl81 10]

Die DC's hab ich natürlich schon in die Standorte verschoben.