9
Falscher Logonserver trotz Standortkonfiguration
Hallo Zusammen,
folgendes Thema:
Wir haben am Standort (Lokal) einen Domänencontroller "DC1". Ein zweiter ("PDC") wurde an einem Remotestandort (Rechenzentrum) installiert.
Das RZ ist per VPN an den lokalen Standort angebunden. AD-Replikation funktioniert.
In AD-Standorte und Dienste sind die Physischen Standorte inkl. der Subnetze abgebildet und entsprechend angelegt. Die DCs entsprechend zugewiesen.
Auf den DC im RZ sollten die FSMO Rollen übertragen werden. das hat auch soweit funktioniert.
Mein Problem ist nun (ja ich habe lange genug gewartet, 36 Stunden sollten da ja reichen):
Im RZ laufen im gleichen Subnetz noch andere Server. Gebe ich echo %logonserver% auf jedem der RZ-Server ein, kommt der Lokale "DC1" (außer beim "PDC" im RZ selbst).
Im DNS sind die SRV Einträge der Sites entsprechend passend konfiguriert, daran sollte es daher eigentlich nicht liegen.
Was sehr interessant ist: Schalte ich den lokalen "DC1" ab und reboote einen einen RZ-Server, zeigt er bei Logonserver immernoch "DC1" an (den er ja gar nicht erreichen kann eigentlich)...
Weiß einer, was hier schief läuft? Ist die Logonservervariable vielleicht einfach falsch? Muss/Kann man das korrigieren?
Grüße
Ketanest
folgendes Thema:
Wir haben am Standort (Lokal) einen Domänencontroller "DC1". Ein zweiter ("PDC") wurde an einem Remotestandort (Rechenzentrum) installiert.
Das RZ ist per VPN an den lokalen Standort angebunden. AD-Replikation funktioniert.
In AD-Standorte und Dienste sind die Physischen Standorte inkl. der Subnetze abgebildet und entsprechend angelegt. Die DCs entsprechend zugewiesen.
Auf den DC im RZ sollten die FSMO Rollen übertragen werden. das hat auch soweit funktioniert.
Mein Problem ist nun (ja ich habe lange genug gewartet, 36 Stunden sollten da ja reichen):
Im RZ laufen im gleichen Subnetz noch andere Server. Gebe ich echo %logonserver% auf jedem der RZ-Server ein, kommt der Lokale "DC1" (außer beim "PDC" im RZ selbst).
Im DNS sind die SRV Einträge der Sites entsprechend passend konfiguriert, daran sollte es daher eigentlich nicht liegen.
Was sehr interessant ist: Schalte ich den lokalen "DC1" ab und reboote einen einen RZ-Server, zeigt er bei Logonserver immernoch "DC1" an (den er ja gar nicht erreichen kann eigentlich)...
Weiß einer, was hier schief läuft? Ist die Logonservervariable vielleicht einfach falsch? Muss/Kann man das korrigieren?
Grüße
Ketanest
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: 456913
Url: https://administrator.de/forum/falscher-logonserver-trotz-standortkonfiguration-456913.html
Ausgedruckt am: 22.12.2024 um 07:12 Uhr
9 Kommentare
Neuester Kommentar
Hallo keta,
eben geprüft, funktioniert in einem normalen Setup quasi OOB - zumindest bei uns (drei Standorte). Hast du denn die Subnetze richtig auf den DCs konfiguriert?
Viele Grüße,
Christian
certifiedit.net
eben geprüft, funktioniert in einem normalen Setup quasi OOB - zumindest bei uns (drei Standorte). Hast du denn die Subnetze richtig auf den DCs konfiguriert?
Viele Grüße,
Christian
certifiedit.net
Hi Christian,
In Active-Directory Standorte und Dienste sind die Subnetze ja den Standorten zugewiesen und die DCs ebenfalls. Dadurch weist man ja dem DC indirekt ein Subnetz zu. Oder wie darf ich die Frage verstehen?
Beide DCs machen für den jeweils eigenen Standort/Subnetz DHCP.
EDIT:
Gruß
Keta
In Active-Directory Standorte und Dienste sind die Subnetze ja den Standorten zugewiesen und die DCs ebenfalls. Dadurch weist man ja dem DC indirekt ein Subnetz zu. Oder wie darf ich die Frage verstehen?
Beide DCs machen für den jeweils eigenen Standort/Subnetz DHCP.
EDIT:
Gruß
Keta
Hallo,
Gruß,
Peter
Zitat von @ketanest112:
Ein zweiter ("PDC") wurde an einem Remotestandort (Rechenzentrum) installiert.
Nur als Info: Einen PDC gibt es seit Server 2000 nicht mehr. ES ist ein DC und alle DCs sind gleichwertig. Nur dessen Konfiguration entscheided darüber was dieser DC denn dann Tuen soll.Ein zweiter ("PDC") wurde an einem Remotestandort (Rechenzentrum) installiert.
Im RZ laufen im gleichen Subnetz noch andere Server. Gebe ich echo %logonserver% auf jedem der RZ-Server ein, kommt der Lokale "DC1" (außer beim "PDC" im RZ selbst).
Du weißt das der Server gewinnt der am schnellsten Antwortet?Was sehr interessant ist: Schalte ich den lokalen "DC1" ab und reboote einen einen RZ-Server, zeigt er bei Logonserver immernoch "DC1" an (den er ja gar nicht erreichen kann eigentlich)...
Dein DC1 mag nicht erreichbar sein (Ausgeschaltet), aber da scheinen zwischengespeicherte Anmeldedaten vorzuliegen (Normales verhalten damit man sich auch z.B. mit ein Laptop in seiner gewohnten Umgebung befindet wenn der DC nicht erreichbar ist. Geht aber nur wennn sich dieser Client und Benutzer zuvor mindesten 1 mal Erfolgreich Verbinden konnte.Weiß einer, was hier schief läuft? Ist die Logonservervariable vielleicht einfach falsch?
Eigentlich nicht wenn due die nicht per Skript oder sonstwie veränderst.Muss/Kann man das korrigieren?
Die Logonservervariable? Nee. Aber dein DC verhalten bzw. wo kann sich ein Client erfolgreich anmelden wenn dein DC down ist. Di sagtest es gibt noch mehr Server dort. Es reicht nicht Server zu haben, es müssen dann schon DCs sein.Und die Replikation muss stimmen usw. Mal DCDiag laufen lassen?Gruß,
Peter
Zitat von @Pjordorf:
Hallo,
Das ist mir durchaus bewusst, er hat nur die FSMO Rollen inne, etc. daher wurde er so benannt. "PDC" auch deshalb in "" weil es der Hostname ist.Hallo,
Zitat von @ketanest112:
Ein zweiter ("PDC") wurde an einem Remotestandort (Rechenzentrum) installiert.
Nur als Info: Einen PDC gibt es seit Server 2000 nicht mehr. ES ist ein DC und alle DCs sind gleichwertig. Nur dessen Konfiguration entscheided darüber was dieser DC denn dann Tuen soll.Ein zweiter ("PDC") wurde an einem Remotestandort (Rechenzentrum) installiert.
Im RZ laufen im gleichen Subnetz noch andere Server. Gebe ich echo %logonserver% auf jedem der RZ-Server ein, kommt der Lokale "DC1" (außer beim "PDC" im RZ selbst).
Du weißt das der Server gewinnt der am schnellsten Antwortet?Was sehr interessant ist: Schalte ich den lokalen "DC1" ab und reboote einen einen RZ-Server, zeigt er bei Logonserver immernoch "DC1" an (den er ja gar nicht erreichen kann eigentlich)...
Dein DC1 mag nicht erreichbar sein (Ausgeschaltet), aber da scheinen zwischengespeicherte Anmeldedaten vorzuliegen (Normales verhalten damit man sich auch z.B. mit ein Laptop in seiner gewohnten Umgebung befindet wenn der DC nicht erreichbar ist. Geht aber nur wennn sich dieser Client und Benutzer zuvor mindesten 1 mal Erfolgreich Verbinden konnte.Weiß einer, was hier schief läuft? Ist die Logonservervariable vielleicht einfach falsch?
Eigentlich nicht wenn due die nicht per Skript oder sonstwie veränderst.Muss/Kann man das korrigieren?
Die Logonservervariable? Nee. Aber dein DC verhalten bzw. wo kann sich ein Client erfolgreich anmelden wenn dein DC down ist. Di sagtest es gibt noch mehr Server dort. Es reicht nicht Server zu haben, es müssen dann schon DCs sein.Und die Replikation muss stimmen usw. Mal DCDiag laufen lassen?Wie genau konfiguriert man das "wo kann sich ein Client erfolgreich anmelden, wenn mein DC down ist"?
Ich meine, es stört mich jetzt nicht groß, mich hat es nur gewundert, dass dann doch der "langsamere" DC gewonnen hat.
In Zeiten der Glasfaservernetzung ist das mit ~25ms Ping eh unerheblich aber es entsteht halt vermeidbarer Traffic, denke ich mir.
EDIT: Der "PDC" ist ein Server 2019, der "DC1" ein 2012 R2, falls das relevant sein sollte...
Gruß
Keta
DCDIAG gibt folgendes aus (hab mal nur die Fehler aufgelistet).
Starting test: Advertising
Achtung: Bei dem Versuch, PDC zu erreichen, wurden von DsGetDcName Informationen für \\dc1.whome.local
zurückgegeben.
DER SERVER REAGIERT NICHT oder GILT ALS UNGEEIGNET.
......................... Der Test Advertising für PDC ist fehlgeschlagen.
Starting test: DFSREvent
Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse
vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.
......................... Der Test DFSREvent für PDC ist fehlgeschlagen.
Starting test: NetLogons
Die Verbindung mit der NETLOGON-Freigabe kann nicht hergestellt werden. (\\PDC\netlogon)
[PDC] Bei einem Vorgang vom Typ "net use" oder "LsaPolicy" ist der Fehler 67 aufgetreten,
Der Netzwerkname wurde nicht gefunden..
......................... Der Test NetLogons für PDC ist fehlgeschlagen.
Starting test: SystemLog
Warnung. Ereignis-ID: 0x00000018
Erstellungszeitpunkt: 05/29/2019 11:10:39
Ereigniszeichenfolge:
Zeitanbieter "NtpClient": Es wurde keine gültige Antwort vom Domänencontroller dc1.whome.local nach 8 Kontaktversuchen empfangen. Der Domänencontroller wird nicht mehr als Zeitquelle verwendet und es wird versucht einen neuen Domänencontroller für die Synchronisierung zu finden. Fehler: Der Peer ist nicht erreichbar.
Starting test: LocatorCheck
Achtung: Fehler beim Aufrufen von DcGetDcName(TIME_SERVER): 1355
Es wurde kein Zeitserver gefunden.
Der Server mit der Rolle für den primären Domänencontroller ist nicht verfügbar.
Achtung: Fehler beim Aufrufen von DcGetDcName(GOOD_TIME_SERVER_PREFERRED): 1355
Es wurde kein geeigneter Zeitserver gefunden.
......................... Der Test LocatorCheck für whome.local ist fehlgeschlagen.
Also irgendwas passt dann wohl doch nicht...
EDIT:
Könnte es an IPv6 liegen?
Im DNS sind für die Clients/Sever am lokalen Standort IPv6 Adressen eingetragen (öffentliche), die aber von der Firewall von außen abgeschirmt werden. Die Adresse sind natürlich nicht über das VPN geroutet. Die Server im RZ haben aber erstmal nur v4 Adressen (sind auch nur für den internen Gebrauch). Daher dürfte das eigentlich nicht das Problem sein.
Außerdem: Eine DFS-Replikation eines anderen Servers funktioniert einwandfrei.
EDIT2:
Hab auch grad nochmal die Firewallregeln angeschaut. Vom RZ-Netz .11.0/24 ins Lokale Netz .10.0/24 ist alles freigegeben (IPv4, alle Protokolle, alle Ports). Umgekehrt genauso.
Gruß
Ketanest
Starting test: Advertising
Achtung: Bei dem Versuch, PDC zu erreichen, wurden von DsGetDcName Informationen für \\dc1.whome.local
zurückgegeben.
DER SERVER REAGIERT NICHT oder GILT ALS UNGEEIGNET.
......................... Der Test Advertising für PDC ist fehlgeschlagen.
Starting test: DFSREvent
Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse
vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.
......................... Der Test DFSREvent für PDC ist fehlgeschlagen.
Starting test: NetLogons
Die Verbindung mit der NETLOGON-Freigabe kann nicht hergestellt werden. (\\PDC\netlogon)
[PDC] Bei einem Vorgang vom Typ "net use" oder "LsaPolicy" ist der Fehler 67 aufgetreten,
Der Netzwerkname wurde nicht gefunden..
......................... Der Test NetLogons für PDC ist fehlgeschlagen.
Starting test: SystemLog
Warnung. Ereignis-ID: 0x00000018
Erstellungszeitpunkt: 05/29/2019 11:10:39
Ereigniszeichenfolge:
Zeitanbieter "NtpClient": Es wurde keine gültige Antwort vom Domänencontroller dc1.whome.local nach 8 Kontaktversuchen empfangen. Der Domänencontroller wird nicht mehr als Zeitquelle verwendet und es wird versucht einen neuen Domänencontroller für die Synchronisierung zu finden. Fehler: Der Peer ist nicht erreichbar.
Starting test: LocatorCheck
Achtung: Fehler beim Aufrufen von DcGetDcName(TIME_SERVER): 1355
Es wurde kein Zeitserver gefunden.
Der Server mit der Rolle für den primären Domänencontroller ist nicht verfügbar.
Achtung: Fehler beim Aufrufen von DcGetDcName(GOOD_TIME_SERVER_PREFERRED): 1355
Es wurde kein geeigneter Zeitserver gefunden.
......................... Der Test LocatorCheck für whome.local ist fehlgeschlagen.
Also irgendwas passt dann wohl doch nicht...
EDIT:
Könnte es an IPv6 liegen?
Im DNS sind für die Clients/Sever am lokalen Standort IPv6 Adressen eingetragen (öffentliche), die aber von der Firewall von außen abgeschirmt werden. Die Adresse sind natürlich nicht über das VPN geroutet. Die Server im RZ haben aber erstmal nur v4 Adressen (sind auch nur für den internen Gebrauch). Daher dürfte das eigentlich nicht das Problem sein.
Außerdem: Eine DFS-Replikation eines anderen Servers funktioniert einwandfrei.
EDIT2:
Hab auch grad nochmal die Firewallregeln angeschaut. Vom RZ-Netz .11.0/24 ins Lokale Netz .10.0/24 ist alles freigegeben (IPv4, alle Protokolle, alle Ports). Umgekehrt genauso.
Gruß
Ketanest
Hallo,
Gruß,
Peter
Zitat von @ketanest112:
Das ist mir durchaus bewusst, er hat nur die FSMO Rollen inne, etc. daher wurde er so benannt. "PDC" auch deshalb in "" weil es der Hostname ist.
Dann sage uns auch das das nur ein willkürlich gewählter Hostname ist.Das ist mir durchaus bewusst, er hat nur die FSMO Rollen inne, etc. daher wurde er so benannt. "PDC" auch deshalb in "" weil es der Hostname ist.
Ja, das sollte aber am dann der sein, der am selben Standort ist (in der theorie), da durch die Standortvernetzung (VPN) ja eine Verzögerung entsteht. (Ping des DC am gleichen Standort <1ms, Ping des anderen DCs 15-25 ms).
Es gab und gibt viele Theorien (mögen die noch so gut sein) die sich im Praktischen Betrieb nicht an die Theorezischen Regeln gealten haben.Okay, ist mir durchaus bewusst, aber wenn ein DC zum anmelden da ist (in diesem Fall dann der "PDC"), sollte er doch den nehmen, egal ob er gecached hat oder nicht...
Sollte - sollte. Und wenn der PDC es aufgrund von Problemen oder Fehlfunktionen nicht kann / tut?Nein, es sollte pro Standort/Subnetz einen DC geben. Die "anderen" Server im RZ sind reine Applikationsserver.
Dann hast du was falsches Konfiguriert.Wie genau konfiguriert man das "wo kann sich ein Client erfolgreich anmelden, wenn mein DC down ist"?
Das macht der Client schon wenn er einen zuständigen DC erreichen kann. Stndard.Ich meine, es stört mich jetzt nicht groß, mich hat es nur gewundert, dass dann doch der "langsamere" DC gewonnen hat.
Dann ist etwas falsch Konfiguriert.In Zeiten der Glasfaservernetzung ist das mit ~25ms Ping eh unerheblich aber es entsteht halt vermeidbarer Traffic, denke ich mir.
Ja.Gruß,
Peter
Nein, es sollte pro Standort/Subnetz einen DC geben. Die "anderen" Server im RZ sind reine Applikationsserver.
Dann hast du was falsches Konfiguriert.An jedem Standort steht ein DC (PDC und DC1), der ADDS für den Standort anbieten soll. Warum soll jetzt jeder Server im RZ ein DC sein??? So wie du vorher angedeutet hast? Ein Applikationsserver (z.B. MSSQL) muss doch keine ADDS anbieten, sondern es reicht ja, wenn er auf die ADDS vom "PDC" zugreifen kann. Er ist ja im gleichen Subnetz?!
Ich meine, es stört mich jetzt nicht groß, mich hat es nur gewundert, dass dann doch der "langsamere" DC gewonnen hat.
Dann ist etwas falsch Konfiguriert.Gruß
Ketanest
Hallo,
Da dann ansetzen und bereinigen. Erst dann wird es evetl Funktionieren. Beim Server bin ich mir nicht sicher ob der ald DC in eine Domäne gebracht werden kann wenn diese auf ein 2012R2 basiert.
Gruß,
Peter
Da dann ansetzen und bereinigen. Erst dann wird es evetl Funktionieren. Beim Server bin ich mir nicht sicher ob der ald DC in eine Domäne gebracht werden kann wenn diese auf ein 2012R2 basiert.
DER SERVER REAGIERT NICHT oder GILT ALS UNGEEIGNET.
Solltest du prüfen ob deine Kombi passt bzw. rennen kann.Also irgendwas passt dann wohl doch nicht...
Scheint einiges zu sein. Die Ereignissprotokolle liefern dir mehr Infos.Könnte es an IPv6 liegen?
Könnte, muss aber nicht.Im DNS sind für die Clients/Sever am lokalen Standort IPv6 Adressen
Dann beschäftige dich mal mit IPv6 oder lass nur IPv4 zu (Sofern dass noch bei dir geht Server 2012R2 ja, Server 2019 nein.)Hab auch grad nochmal die Firewallregeln angeschaut. Vom RZ-Netz .11.0/24 ins Lokale Netz .10.0/24 ist alles freigegeben (IPv4, alle Protokolle, alle Ports). Umgekehrt genauso.
Ein Wireshark hilft dir deine Vermutungen in Gewissheit zu wandeln.Gruß,
Peter
Hallo Peter,
danke für die Infos!
Er zerlegt sich die NETLOGON und SYSVOL Freigaben immer... Konnte ihn zwar erfolgreich als DC heraufstufen aber das heißt ja noch nix...
Joa mal sehen...
Jepp, da seh ich mal nach
Wirds vermutlich auch nicht, wie gesagt IPv6 ist im RZ-Netz nicht aktiv (also auf der NIC schon aber es gibt keinen DHCPv6 Server oder jemand, der ein Präfix rumbrüllt).
Am lokalen Standort wollen wir ja Hybrid fahren, das passt schon.
Danke!
Gruß
Ketanest
danke für die Infos!
DCDIAG gibt folgendes aus (hab mal nur die Fehler aufgelistet).
Da dann ansetzen und bereinigen. Erst dann wird es evetl Funktionieren. Beim Server bin ich mir nicht sicher ob der ald DC in eine Domäne gebracht werden kann wenn diese auf ein 2012R2 basiert. DER SERVER REAGIERT NICHT oder GILT ALS UNGEEIGNET.
Solltest du prüfen ob deine Kombi passt bzw. rennen kann.Also irgendwas passt dann wohl doch nicht...
Scheint einiges zu sein. Die Ereignissprotokolle liefern dir mehr Infos.Könnte es an IPv6 liegen?
Könnte, muss aber nicht.Im DNS sind für die Clients/Sever am lokalen Standort IPv6 Adressen
Dann beschäftige dich mal mit IPv6 oder lass nur IPv4 zu (Sofern dass noch bei dir geht Server 2012R2 ja, Server 2019 nein.)Danke!
Gruß
Ketanest
