Jump to content
Sign in to follow this  
bertl81

Client melden sich am falschen DC an

Recommended Posts

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

Share this post


Link to post
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

Share this post


Link to post

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 ?

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post
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

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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. :)

Share this post


Link to post

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

Share this post


Link to post
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...