12
Domänen Controller an zwei Standorten richtig konfigurieren.
Hallo zusammen,
ich habe folgende Situation:
Alles WIN 2008 Server
Standort 1 (IP: 172.10.x)
Domänen Controller 1 (DNS, DHCP)
Domänen Controller 2 (repikation mit DC1)
Standort 2 (IP: 172.11.x)
Domänen Controller 3 (replikation mit DC1 und DC2) und (DNS eigenem DHCP)
Wie kann ich nun den DC3 so konfigurieren das die Netzwerklastlast nicht arg belastet wird? Weil nach jedem Login des Benutzers das Script aus dem NETLOGON vom DC1 (sprich vom Standort1) geladen wird und dadurch unnötigen Netztransfer verursacht!
Würde mich über Eure Hilfe freuen!
LG
ich habe folgende Situation:
Alles WIN 2008 Server
Standort 1 (IP: 172.10.x)
Domänen Controller 1 (DNS, DHCP)
Domänen Controller 2 (repikation mit DC1)
Standort 2 (IP: 172.11.x)
Domänen Controller 3 (replikation mit DC1 und DC2) und (DNS eigenem DHCP)
Wie kann ich nun den DC3 so konfigurieren das die Netzwerklastlast nicht arg belastet wird? Weil nach jedem Login des Benutzers das Script aus dem NETLOGON vom DC1 (sprich vom Standort1) geladen wird und dadurch unnötigen Netztransfer verursacht!
Würde mich über Eure Hilfe freuen!
LG
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 159906
Url: https://administrator.de/forum/domaenen-controller-an-zwei-standorten-richtig-konfigurieren-159906.html
Ausgedruckt am: 23.12.2024 um 06:12 Uhr
12 Kommentare
Neuester Kommentar
Servus,
warum verwendest du --> offizielle <-- IP-Adressen?
Bei der Authentifizierung eines Clients ist das DNS und das Design im Snap-In "Active Directory-Standorte und -Dienste" entscheidend.
Falls AD-Standorte eingerichtet werden sollen, darf das erstellen der jeweiligen Subnetze und das verknüpfen an den entsprechenden Standorten nicht vergessen werden.
Natürlich müssen dann noch die DC-Icons an ihre AD-Standorte, in der MMC "Active Directory-Standorte und -Dienste" verschoben werden.
Die Vorgehensweise wie ein Client "einen" DC findet, ist wie folgt:
- Der Client fragt im DNS nach, welche DCs es gibt.
- Er erhält eine Liste aus der DNS-Antwort und geht diese durch, um einen DC zu finden der funktioniert und auch online ist. Dabei nimmt er bevorzugt
einen DC aus seinem Standort. Die DNS-Abfrage die der Client in diesem Moment stellt, wäre: _ldap._tcp.<Standort>._sites.dc._msdcs.<Domäne>.<TLD>.
- Erst wenn der Client bei dieser Anfrage (von einem DC aus seinem Standort) keine Antwort erhält oder er noch keine Standortinformationen hat
(z.B. nach einer Neuinstallation), fragt er nach einem DC diesmal aus seiner DOMÄNE nach. Die Abfrage lautet: _ldap._tcp.dc._msdcs.<Domäne>.<TLD>.
Spätestens bei dieser Abfrage erhält der Client einen DC mitgeteilt.
Auf der Gegenseite geht der DC der die Anfrage eines Clients erhält wie folgt vor:
- Der Domänencontroller reicht die Clientanfrage an seinen NETLOGON-Prozess durch, der dann die Client-IP in seiner Subnet to Site Mapping Table nachsieht und dann das treffende Standort-Objekt heraussucht.
- Der Netlogon-Prozess des DCs übergibt an den DC die folgenden Infos:
1. Den Namen des Standorts, in der sich der befragte Domänencontroller befindet
2. Den Standortnamen, in dem sich der Client befindet
3. Ein Flag das angezeigt wird, wenn sich der angefragte DC im gleichen Standort befindet (Bit gesetzt) oder ob der DC ausserhalb des Standortes ist (Bit nicht gesetzt).
Diese Informationen werden dann an den Client gesendet, der sich nun die Informationen näher anschaut:
- Wenn sich der Domänencontroller an dem gleichen (oder nächstgelegenen) Standort befindet (gesetztes Bit), nimmt der Client bevorzugt diesen DC.
- Wenn sich kein DC an dem Standort des Clients befindet, entscheidet das Design in der MMC "Standorte und Dienste", an welchem DC sich der Client authentifiziert.
Er verwendet der einen Domänencontroller der am nächsten zu seinem Standort ist. Dabei ist z.B. die Einstellung der Verbindungskosten entscheidend.
- Nachdem der Client einen Domänencontroller ermittelt hat, wird dieser Eintrag des DCs zwischengespeichert. Falls sich der DC nicht an dem Standort des Clients oder an einem optimalen
Standort befinden sollte (Kosten), leert der Client nach 15 Minuten den Zwischenspeicher und verwirft somit den zwischengespeicherten DC. Der Client versucht dann einen nächstgelegenen DC, idealerweise an
seinem eigenen Standort zu finden.
Siehe auch:
[Yusuf`s Directory - Blog - Domänencontroller am Standort]
http://blog.dikmenoglu.de/PermaLink,guid,ad2ea4b3-0374-4048-8b3d-43623c ...
Viele Grüße
/ > Yusuf Dikmenoglu
warum verwendest du --> offizielle <-- IP-Adressen?
Bei der Authentifizierung eines Clients ist das DNS und das Design im Snap-In "Active Directory-Standorte und -Dienste" entscheidend.
Falls AD-Standorte eingerichtet werden sollen, darf das erstellen der jeweiligen Subnetze und das verknüpfen an den entsprechenden Standorten nicht vergessen werden.
Natürlich müssen dann noch die DC-Icons an ihre AD-Standorte, in der MMC "Active Directory-Standorte und -Dienste" verschoben werden.
Die Vorgehensweise wie ein Client "einen" DC findet, ist wie folgt:
- Der Client fragt im DNS nach, welche DCs es gibt.
- Er erhält eine Liste aus der DNS-Antwort und geht diese durch, um einen DC zu finden der funktioniert und auch online ist. Dabei nimmt er bevorzugt
einen DC aus seinem Standort. Die DNS-Abfrage die der Client in diesem Moment stellt, wäre: _ldap._tcp.<Standort>._sites.dc._msdcs.<Domäne>.<TLD>.
- Erst wenn der Client bei dieser Anfrage (von einem DC aus seinem Standort) keine Antwort erhält oder er noch keine Standortinformationen hat
(z.B. nach einer Neuinstallation), fragt er nach einem DC diesmal aus seiner DOMÄNE nach. Die Abfrage lautet: _ldap._tcp.dc._msdcs.<Domäne>.<TLD>.
Spätestens bei dieser Abfrage erhält der Client einen DC mitgeteilt.
Auf der Gegenseite geht der DC der die Anfrage eines Clients erhält wie folgt vor:
- Der Domänencontroller reicht die Clientanfrage an seinen NETLOGON-Prozess durch, der dann die Client-IP in seiner Subnet to Site Mapping Table nachsieht und dann das treffende Standort-Objekt heraussucht.
- Der Netlogon-Prozess des DCs übergibt an den DC die folgenden Infos:
1. Den Namen des Standorts, in der sich der befragte Domänencontroller befindet
2. Den Standortnamen, in dem sich der Client befindet
3. Ein Flag das angezeigt wird, wenn sich der angefragte DC im gleichen Standort befindet (Bit gesetzt) oder ob der DC ausserhalb des Standortes ist (Bit nicht gesetzt).
Diese Informationen werden dann an den Client gesendet, der sich nun die Informationen näher anschaut:
- Wenn sich der Domänencontroller an dem gleichen (oder nächstgelegenen) Standort befindet (gesetztes Bit), nimmt der Client bevorzugt diesen DC.
- Wenn sich kein DC an dem Standort des Clients befindet, entscheidet das Design in der MMC "Standorte und Dienste", an welchem DC sich der Client authentifiziert.
Er verwendet der einen Domänencontroller der am nächsten zu seinem Standort ist. Dabei ist z.B. die Einstellung der Verbindungskosten entscheidend.
- Nachdem der Client einen Domänencontroller ermittelt hat, wird dieser Eintrag des DCs zwischengespeichert. Falls sich der DC nicht an dem Standort des Clients oder an einem optimalen
Standort befinden sollte (Kosten), leert der Client nach 15 Minuten den Zwischenspeicher und verwirft somit den zwischengespeicherten DC. Der Client versucht dann einen nächstgelegenen DC, idealerweise an
seinem eigenen Standort zu finden.
Siehe auch:
[Yusuf`s Directory - Blog - Domänencontroller am Standort]
http://blog.dikmenoglu.de/PermaLink,guid,ad2ea4b3-0374-4048-8b3d-43623c ...
Viele Grüße
/ > Yusuf Dikmenoglu
Hi Yusuf-Digmenoglu,
du kannst es einfach spitzenmäßig erklären.....
Dein Blog u. deine AD freelist sind super....., wenn ,man das hier mal so sagen darf !?!
Danke.
du kannst es einfach spitzenmäßig erklären.....
Dein Blog u. deine AD freelist sind super....., wenn ,man das hier mal so sagen darf !?!
Danke.
Salut,
<hust> das erste "g" sollte ein "k" sein.
</hust>
Freut mich zu hören.
Ohjaa, sei sanft zu mir. Natürlich darfst du das sagen und meine Augen machen, seit dem sie dein Post gelesen haben, Luftsprünge. =)
Gruß, Yusuf Dikmenoglu
Hi Yusuf-Digmenoglu,
<hust> das erste "g" sollte ein "k" sein.
</hust>du kannst es einfach spitzenmäßig erklären.....
Freut mich zu hören.
Dein Blog u. deine AD freelist sind super....., wenn ,man das hier mal so sagen darf !?!
Ohjaa, sei sanft zu mir.
Natürlich darfst du das sagen und meine Augen machen, seit dem sie dein Post gelesen haben, Luftsprünge. =)Gruß, Yusuf Dikmenoglu
Sorry, für das "G" anstelle des "K", das ist mir ja, schon fast peinlich...
mfg redocomp
mfg redocomp
Morgen Yusuf,
danke für die ausführliche Erklärung. Wie DCs/Clients miteinander kommunizieren ist mir bewusst. Was ich wissen wollte ist wie ich den DC3 so konfiguriere dass wenn alle Benutzer am Standort 2 sich anmelden auch nur! der DC3 angesprochen wird. (ob das DHCP, DNS, NETLOGON etc. ist)
Ich habe ein wenig in der Hilfe gestöbert und bin auf die „Active Directory Standorte und Dienste“ gestoßen. Ich denke hier bin ich richtig! Hier kann man einen Zusätzlichen Standort einrichten und den jeweiligen DC in meinem Fall den DC3 in diesen Standort schieben. Selbstverständlich müssen hier auch die IP Adressen Bereiche festgelegt werden, damit das System weiss für welche Bereiche der jeweilige DC greift.
Ich hoffe Ihr Versteht mich?
PS: Die öffentlichen IPs spielen doch keine Rolle oder?
danke für die ausführliche Erklärung. Wie DCs/Clients miteinander kommunizieren ist mir bewusst. Was ich wissen wollte ist wie ich den DC3 so konfiguriere dass wenn alle Benutzer am Standort 2 sich anmelden auch nur! der DC3 angesprochen wird. (ob das DHCP, DNS, NETLOGON etc. ist)
Ich habe ein wenig in der Hilfe gestöbert und bin auf die „Active Directory Standorte und Dienste“ gestoßen. Ich denke hier bin ich richtig! Hier kann man einen Zusätzlichen Standort einrichten und den jeweiligen DC in meinem Fall den DC3 in diesen Standort schieben. Selbstverständlich müssen hier auch die IP Adressen Bereiche festgelegt werden, damit das System weiss für welche Bereiche der jeweilige DC greift.
Ich hoffe Ihr Versteht mich?
PS: Die öffentlichen IPs spielen doch keine Rolle oder?
hi adminit,
AD standorte u. dienste, dort das subnetz deines DC3 Standortes als neues subnetz anlegen u. einen neuen AD Standort3 anlegen.
den neuen Standort dem neuen subnetz zuordnen u. den DC3 noch dem neuen Standort3 zuordnen.
Das wäre der Weg....
PS: Die öffentlichen IPs spielen hier keine Rolle !
AD standorte u. dienste, dort das subnetz deines DC3 Standortes als neues subnetz anlegen u. einen neuen AD Standort3 anlegen.
den neuen Standort dem neuen subnetz zuordnen u. den DC3 noch dem neuen Standort3 zuordnen.
Das wäre der Weg....
PS: Die öffentlichen IPs spielen hier keine Rolle !
danke für die ausführliche Erklärung.
Keine Ursache!
Wie DCs/Clients miteinander kommunizieren ist mir bewusst.
Na wenn du das sagst...
Was ich wissen wollte ist wie ich den DC3 so konfiguriere dass wenn alle Benutzer am Standort 2 sich
anmelden auch nur! der DC3 angesprochen wird. (ob das DHCP, DNS, NETLOGON etc. ist)
anmelden auch nur! der DC3 angesprochen wird. (ob das DHCP, DNS, NETLOGON etc. ist)
Je nachdem wie sehr du in der Materie steckst, aber mit meiner ersten Antwort kommt man von alleine drauf.
Ich habe ein wenig in der Hilfe gestöbert und bin auf die „Active Directory Standorte und Dienste“ gestoßen. Ich denke hier bin ich richtig!
Ach sieh' an... *jetzt* wird es dir langsam klarer...
Hier kann man einen Zusätzlichen Standort einrichten und den jeweiligen DC in meinem Fall den DC3 in diesen Standort schieben.
Selbstverständlich müssen hier auch die IP Adressen Bereiche festgelegt werden, damit das System weiss für welche Bereiche der jeweilige DC greift.
Selbstverständlich müssen hier auch die IP Adressen Bereiche festgelegt werden, damit das System weiss für welche Bereiche der jeweilige DC greift.
Genau so ist es!
AD-Standorte sollten nur dann erstellt:
- um die AD-Replikation standortübergreifend zu steuern
- einem AD-Standort vorzugeben, an welchen DCs sich die Clients authentisieren sollen (was du also möchtest)
- einem Client einen lokalen DFS-Pfad zur Verfügung zu stellen
Ich hoffe Ihr Versteht mich?
Das hatte ich schon von Anfang an!
PS: Die öffentlichen IPs spielen doch keine Rolle oder?
Das ist zwar dem AD egal, trotzdem gehört es zu einem sauberen Design dazu, dass man im internen Netz eben nur private IPs verwendet!
Gruß, Yusuf Dikmenoglu
Super ! Vielen Dank.
Jetzt meine letzte Frage. Du schreibst oben den DNS bereinigen.
Das Verschieben der Clients von einem Standort/DNS in den anderen funktioniert nicht ohne weiteres.
Muss ich alle DNS Einträge löschen oder wie mache ich das richtig? Wenn ich den eintrag einfach lösche dürfte ein Neustart des Clients reichen? Oder?
Gibt es vielleicth ein Tool?
Jetzt meine letzte Frage. Du schreibst oben den DNS bereinigen.
Das Verschieben der Clients von einem Standort/DNS in den anderen funktioniert nicht ohne weiteres.
Muss ich alle DNS Einträge löschen oder wie mache ich das richtig? Wenn ich den eintrag einfach lösche dürfte ein Neustart des Clients reichen? Oder?
Gibt es vielleicth ein Tool?
Hallo zusammen,
nach dem Verschieben der Server funktionier soweit alles allerdings habe ich leider den Punkt 13. von Yusuf übersehen.
Dort steht:
13. Das DNS sollte zwingend bereinigt werden. Denn nach dem verschieben des DCs, bleiben die Einträge vom alten Standort weiterhin im DNS bestehen.
Dazu sind die SRV-Records aus dem Pfad _tcp.<Name des Standorts>._sites.dc._msdcs.Domäne.TLD vom alten Standort zu entfernen.
Ansonsten könnten sich die Clients weiterhin versuchen, an dem DC der an einen anderen Standort verschoben wurde, zu authentifizieren.
Das Resultat wären langsame Anmeldevorgänge.
Unter 2008 Server R2 finde allerdings den Pfad (_tcp.<Name des Standorts>._sites.dc._msdcs.Domäne.TLD ) nicht direkt . Den Punkt "_tcp" finde ich unter jedem Standort im fast jedem unterverzeichnis (siehe Bild unten). Ehrlich gesagt habe ich angst einen SRV-Record zu löschen da ich keine Ahnung habe was dann passieren kann.
Kann mir vielleicht jemand einen Tip geben was ich genau löschen muss? Würde mich über Eure Hilfe freuen.
nach dem Verschieben der Server funktionier soweit alles allerdings habe ich leider den Punkt 13. von Yusuf übersehen.
Dort steht:
13. Das DNS sollte zwingend bereinigt werden. Denn nach dem verschieben des DCs, bleiben die Einträge vom alten Standort weiterhin im DNS bestehen.
Dazu sind die SRV-Records aus dem Pfad _tcp.<Name des Standorts>._sites.dc._msdcs.Domäne.TLD vom alten Standort zu entfernen.
Ansonsten könnten sich die Clients weiterhin versuchen, an dem DC der an einen anderen Standort verschoben wurde, zu authentifizieren.
Das Resultat wären langsame Anmeldevorgänge.
Unter 2008 Server R2 finde allerdings den Pfad (_tcp.<Name des Standorts>._sites.dc._msdcs.Domäne.TLD ) nicht direkt . Den Punkt "_tcp" finde ich unter jedem Standort im fast jedem unterverzeichnis (siehe Bild unten). Ehrlich gesagt habe ich angst einen SRV-Record zu löschen da ich keine Ahnung habe was dann passieren kann.
Kann mir vielleicht jemand einen Tip geben was ich genau löschen muss? Würde mich über Eure Hilfe freuen.
Was ist denn daran nicht zu verstehen: _tcp.<Name des Standorts>._sites.dc._msdcs.Domäne.TLD?
Der Pfad ist doch eindeutig. Wenn z.B. "Standort 2" der *alte* Standort ist, musst du im Pfad "_tcp.Standort 2._sites.dc._msdcs.Domain.local"
die SRV-Einträge des DCs entfernen. Bei aktiviertem Aufräumprozess würden die Einträge zwar auch automatisch verschwinden, aber bis der Prozess durchgelaufen
(je nach Konfiguration, falls es überhaupt konfiguriert wurde) dauert es dann eben.
Gruß, Yusuf Dikmenoglu
Der Pfad ist doch eindeutig. Wenn z.B. "Standort 2" der *alte* Standort ist, musst du im Pfad "_tcp.Standort 2._sites.dc._msdcs.Domain.local"
die SRV-Einträge des DCs entfernen. Bei aktiviertem Aufräumprozess würden die Einträge zwar auch automatisch verschwinden, aber bis der Prozess durchgelaufen
(je nach Konfiguration, falls es überhaupt konfiguriert wurde) dauert es dann eben.
Gruß, Yusuf Dikmenoglu
Hi Yusuf,
danke für deine schnelle Antwort. Ich habe mich etwas blöd angestellt. Folgendes habe ich gemacht:
Am DC3 (Standort2) habe ich die Einträge vom Standort1 gelöscht und den DNS bereinigt (Clients entfernt!)
Am DC1 (Standort1) habe ich die Einträge vom Standort2 gelöscht und den DNS bereinigt (Clients entfernt!)
Denn der Ist-Stand ist wie folgt:
Standort 1 (DC1 und DC2)
Standort 2 (DC3)
Nach 2 Stunden wollte ich mir das noch mal anschauen und stelle fest, dass sich weiterhin Clients nicht am jeweiligen Standort/DNS anmelden.
Zusätzlich waren die Einträge, die ich unter (_tcp.Standort 2._sites.dc._msdcs.Domain.local) gelöscht habe wieder da?!
Was mache ich falsch?
LG
danke für deine schnelle Antwort. Ich habe mich etwas blöd angestellt. Folgendes habe ich gemacht:
Am DC3 (Standort2) habe ich die Einträge vom Standort1 gelöscht und den DNS bereinigt (Clients entfernt!)
Am DC1 (Standort1) habe ich die Einträge vom Standort2 gelöscht und den DNS bereinigt (Clients entfernt!)
Denn der Ist-Stand ist wie folgt:
Standort 1 (DC1 und DC2)
Standort 2 (DC3)
Nach 2 Stunden wollte ich mir das noch mal anschauen und stelle fest, dass sich weiterhin Clients nicht am jeweiligen Standort/DNS anmelden.
Zusätzlich waren die Einträge, die ich unter (_tcp.Standort 2._sites.dc._msdcs.Domain.local) gelöscht habe wieder da?!
Was mache ich falsch?
LG
Zitat von @adminit:
Nach 2 Stunden wollte ich mir das noch mal anschauen und stelle fest, dass sich weiterhin Clients nicht am jeweiligen Standort/DNS
anmelden.
Zusätzlich waren die Einträge, die ich unter (_tcp.Standort 2._sites.dc._msdcs.Domain.local) gelöscht habe wieder da?!
Nach 2 Stunden wollte ich mir das noch mal anschauen und stelle fest, dass sich weiterhin Clients nicht am jeweiligen Standort/DNS
anmelden.
Zusätzlich waren die Einträge, die ich unter (_tcp.Standort 2._sites.dc._msdcs.Domain.local) gelöscht habe wieder da?!
Oder muss ich die SRV-Einträge an allen DCs entfernen? Eventuell war das der Grund dass die Einträge wieder aufgetaucht sind weil die DCs untereinander repliziert haben?
War das vielleicht mein Fehler?
