Nslookup auf AD Domain Namen
Hi,
Unsere 2012er AD beherbergt 3 DCs.
DC1 und DC2 stehen in Standort A
DC3 steht in Standort B
Jedesmal wenn ich nslookup domain.local eingebe, antwortet der DC3
Wenn ich domain.local anpinge antwortet DC1
On top haben wir das Problem das sich einige Workstations aus Standort A versuchen in Standort B anzumelden,
was dementsprechend lange dauert.
Ich habe jetzt folgendes geändert:
Ich habe mittels regedit:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters\LdapSrvWeight
sowie
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters\LdapSrvPriority
pro DC auf folgende Werte geändert:
DC1 Weight 200 Prio 10
DC2 Weight 100 Prio 20
DC3 Weight 50 Prio 30
Das müsste doch zwingend dazu führen das sich die Clients auf dem DC1 anmelden, ändert wohl aber nichts am nslookup auf die Domain ?
Unsere 2012er AD beherbergt 3 DCs.
DC1 und DC2 stehen in Standort A
DC3 steht in Standort B
Jedesmal wenn ich nslookup domain.local eingebe, antwortet der DC3
Wenn ich domain.local anpinge antwortet DC1
On top haben wir das Problem das sich einige Workstations aus Standort A versuchen in Standort B anzumelden,
was dementsprechend lange dauert.
Ich habe jetzt folgendes geändert:
Ich habe mittels regedit:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters\LdapSrvWeight
sowie
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters\LdapSrvPriority
pro DC auf folgende Werte geändert:
DC1 Weight 200 Prio 10
DC2 Weight 100 Prio 20
DC3 Weight 50 Prio 30
Das müsste doch zwingend dazu führen das sich die Clients auf dem DC1 anmelden, ändert wohl aber nichts am nslookup auf die Domain ?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 328391
Url: https://administrator.de/contentid/328391
Ausgedruckt am: 25.11.2024 um 13:11 Uhr
13 Kommentare
Neuester Kommentar
Hi,
sind die Standorte mit ihren Subnetzen auch im AD als Site- und Subnet-Objekte abgebildet? Wenn nicht, erstmal nachholen.
An den Wichtungen der einzelnen Records sollte Du nichts ändern, weil diese ja dann wieder für alle Clients gelten, unabhängig vom Standort. Es sei denn, Du hast je Standort einen DNS-Server und diese halten jeweils unabhängige Primäre Zonen. Ich denke das hast Du nicht.
Windows DNS Server unter 2012 sollten beim Round Robin standardmäßig auch das "Netzwerkmaskenanforderung" aktiviert haben. (DNS-Server - Eigenschaften - Erweitert). Das sorgt dafür, dass ein Client für einen angeforderten Namen vorzugsweise eine IP-Adresse aus seinem Subnetz bekommt. das funktioniert natürlich nur solange, wie Client und angeforderter Host im selben Subnet sind.
Anmelden über WAN an einem DC ist eigentlich nicht so sehr das Problem. Aber Laden eines Roaming Profiles über WAN schon. Ist letzteres vielleicht eher der Schuh, welcher drückt?
E.
sind die Standorte mit ihren Subnetzen auch im AD als Site- und Subnet-Objekte abgebildet? Wenn nicht, erstmal nachholen.
An den Wichtungen der einzelnen Records sollte Du nichts ändern, weil diese ja dann wieder für alle Clients gelten, unabhängig vom Standort. Es sei denn, Du hast je Standort einen DNS-Server und diese halten jeweils unabhängige Primäre Zonen. Ich denke das hast Du nicht.
Windows DNS Server unter 2012 sollten beim Round Robin standardmäßig auch das "Netzwerkmaskenanforderung" aktiviert haben. (DNS-Server - Eigenschaften - Erweitert). Das sorgt dafür, dass ein Client für einen angeforderten Namen vorzugsweise eine IP-Adresse aus seinem Subnetz bekommt. das funktioniert natürlich nur solange, wie Client und angeforderter Host im selben Subnet sind.
Anmelden über WAN an einem DC ist eigentlich nicht so sehr das Problem. Aber Laden eines Roaming Profiles über WAN schon. Ist letzteres vielleicht eher der Schuh, welcher drückt?
E.
Das bedeutet hier fehlt unter AD Sites ein Eintrag für die Clients !?
Möglicherweise.Du benötigst
2x Standort-Objekte
"Lokation A" ("Standardname-des-ersten-Standorts")
"Lokation B"
2x Subnet-Objekte
192.168.32.0/21 --> Standort "Lokation A"
192.168.41.0/24 --> Standort "Lokation B"
Dann alle Server-Objekt (DC's), welche in 192.168.41.0/24 laufen, von "Lokation A\Servers" nach "Lokation B\Servers" verschieben.
Na dann hätten wir uns doch das ganze Gerede über Namensauflösung und "anmelden an" sparen können.
Ist doch klar, dass die Anmeldungen dann lange dauern, wenn sich ein Benutzer an B anmeldet und von A über WAN das Profil laden muss. Auch wenn es sich nicht geändert hat, so muss es doch überprüft werden, ob alle Dateien noch gleich sind.
Lösung
Die Profile der Benutzer aus B in einer Freigabe auf einem Server in B ablegen. Den Profilpfad in den betreffenden Benutzerobjekten anpassen.
Falls Du Benutzer hast, welche an beiden Standortebn aktiv sind, dann können wir das auch noch anpassen.
Ist doch klar, dass die Anmeldungen dann lange dauern, wenn sich ein Benutzer an B anmeldet und von A über WAN das Profil laden muss. Auch wenn es sich nicht geändert hat, so muss es doch überprüft werden, ob alle Dateien noch gleich sind.
Lösung
Die Profile der Benutzer aus B in einer Freigabe auf einem Server in B ablegen. Den Profilpfad in den betreffenden Benutzerobjekten anpassen.
Falls Du Benutzer hast, welche an beiden Standortebn aktiv sind, dann können wir das auch noch anpassen.
Wenn ich Dir helfen soll, dann wäre es hilfreich, wenn Du auch meine Fragen beantworten würdest.
Hast Du Benutzer, welche sich an beiden Standorten an den PC's anmelden?
Hinweis:
"Anmeldung am DC" und "Laden eines Profils" sind zwei vollkommen verschiedene Vorgänge.
Wenn ein User eine neue Workstation bekommt, sich dann zum ersten mal anmeldet,
An welchem Standort war das?Hast Du Benutzer, welche sich an beiden Standorten an den PC's anmelden?
leider am falschen DC
Woran stellst Du das eigentlich fest?Hinweis:
"Anmeldung am DC" und "Laden eines Profils" sind zwei vollkommen verschiedene Vorgänge.