agnostiker
Goto Top

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 ?

Content-Key: 328391

Url: https://administrator.de/contentid/328391

Ausgedruckt am: 19.03.2024 um 05:03 Uhr

Mitglied: emeriks
emeriks 03.02.2017 um 15:08:30 Uhr
Goto Top
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.
Mitglied: GuentherH
GuentherH 03.02.2017 um 18:23:58 Uhr
Goto Top
On top haben wir das Problem das sich einige Workstations aus Standort A versuchen in Standort B anzumelden,

Genau das Problem hast du, wenn du wie emeriks in seinem Beitrag schreibt die Standorte mit ihren Subnetzen nicht definiert hast.

LG Günther
Mitglied: agnostiker
agnostiker 06.02.2017 um 10:49:24 Uhr
Goto Top
Es gibt zwei Lokationen:

Lokation A: 192.168.32.0/21
Lokation B: 192.168.41.0/24

Das sind die Netze der Server!

Die Clients laufen in Site A mit: 192.168.33.0/21

Das bedeutet hier fehlt unter AD Sites ein Eintrag für die Clients !?
Mitglied: agnostiker
agnostiker 06.02.2017 um 11:04:00 Uhr
Goto Top
Exakt, das laden der Roaming Profiles ist das Problem, wenn sich der Client am Falschen DC anmeldet...
Mitglied: emeriks
emeriks 06.02.2017 aktualisiert um 11:10:28 Uhr
Goto Top
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.
Mitglied: emeriks
emeriks 06.02.2017 um 11:09:48 Uhr
Goto Top
Exakt, das laden der Roaming Profiles ist das Problem, wenn sich der Client am Falschen DC anmeldet...
Wo sind diese gespeichert?
Wie lauteten die Pfade im Benutzerobjekt?
Mitglied: agnostiker
agnostiker 06.02.2017 um 11:26:09 Uhr
Goto Top
Das war vorher schon exakt so wie Du es beschrieben hast. Auch die DCs waren bzw. sind richtig zugewiesen.
Mitglied: agnostiker
agnostiker 06.02.2017 um 11:31:34 Uhr
Goto Top
\\firma.lan\benutzer$\Profiles\Benutzername
Die Daten liegen auf einem Fileserver in Lokation A
\\Datenserver\profiles$
Mitglied: emeriks
emeriks 06.02.2017 um 11:50:14 Uhr
Goto Top
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.
Mitglied: agnostiker
agnostiker 06.02.2017 um 12:35:02 Uhr
Goto Top
Das Problem ist das sich Benutzer aus Lokation A am DC der Lokation B anmelden und es dann ewig dauert oder gar nicht funktioniert mit dem anlegen der Profile.
Mitglied: emeriks
emeriks 06.02.2017 um 12:39:33 Uhr
Goto Top
Du meinst bei der Erstanmeldung, wenn auf dem PC noch keine lokale Kopie des Profils drauf ist? Oder bei jeder Anmeldung?

das sich Benutzer aus Lokation A am DC der Lokation B anmelden
Woran stellst Du das eigentlich fest?

Hast Du Benutzer, welche sich an beiden Standorten an den PC's anmelden?
Mitglied: agnostiker
agnostiker 07.02.2017 um 09:59:09 Uhr
Goto Top
Wenn ein User eine neue Workstation bekommt, sich dann zum ersten mal anmeldet, leider am falschen DC gibts fehler bei der profilerstellung.
Wie jetzt vor ein paar Tagen, wurde versucht das alte profil zu ziehen V5 und dann wurde versucht parallel das V6 zu erstellen, beides hat nicht geklappt.
Mitglied: emeriks
emeriks 07.02.2017 aktualisiert um 11:00:19 Uhr
Goto Top
Wenn ich Dir helfen soll, dann wäre es hilfreich, wenn Du auch meine Fragen beantworten würdest.

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.