4
Neuer 2022 DC hinzugefügt, Uhrzeitprobleme
Hallo Community,
ich benötige ml eure Hilfe.
Einer Windows 2012 R2 Domäne (1 Server, Blech, PDC "SRV30") wurde ein "Windows 2022 Server Std" als weiterer Domänencontroller (SRV41) hinzugefügt (Virtuell unter Hyper-V auf einer separaten Maschine).
Das funktionierte (gestern) ohne Problem. Ein AD-Sync hatte gestern fehlerfrei funktioniert. Heute sehe ich das die Uhrzeit auf dem neuen Server (Hyper-V Client) 1 Stunde in der Zukunft liegt, was natürlich den AD-Sync verhindert. Die Zeit auf dem Hyper-V Host selbst ist korrekt. Alle Versuche das auf SRV41 zu "korrigieren" schlagen fehl. Die Namesauflösung (DNS) funktioniert wie erwartet.
w32tm /monitor
SRV30.xxx.lokal * PDC *
ICMP: 0ms Verzögerung
NTP: +0.0000000s Offset von SRV30.xxx.lokal
RefID: mail2.light-speed.de [85.214.83.151]
Stratum: 3
Srv41.xxx.lokal[192.168.10.3:123]:
ICMP: 0ms Verzögerung
NTP: +3588.9568856s Offset von SRV30.xxx.lokal
RefID: 80.84.77.86.rev.sfr.net [86.77.84.80]
Stratum: 4
Was übersehe ich, oder worin könnte das Problem begründet sein?
Danke im Voraus
Snoopycount
ich benötige ml eure Hilfe.
Einer Windows 2012 R2 Domäne (1 Server, Blech, PDC "SRV30") wurde ein "Windows 2022 Server Std" als weiterer Domänencontroller (SRV41) hinzugefügt (Virtuell unter Hyper-V auf einer separaten Maschine).
Das funktionierte (gestern) ohne Problem. Ein AD-Sync hatte gestern fehlerfrei funktioniert. Heute sehe ich das die Uhrzeit auf dem neuen Server (Hyper-V Client) 1 Stunde in der Zukunft liegt, was natürlich den AD-Sync verhindert. Die Zeit auf dem Hyper-V Host selbst ist korrekt. Alle Versuche das auf SRV41 zu "korrigieren" schlagen fehl. Die Namesauflösung (DNS) funktioniert wie erwartet.
w32tm /monitor
SRV30.xxx.lokal * PDC *
ICMP: 0ms Verzögerung
NTP: +0.0000000s Offset von SRV30.xxx.lokal
RefID: mail2.light-speed.de [85.214.83.151]
Stratum: 3
Srv41.xxx.lokal[192.168.10.3:123]:
ICMP: 0ms Verzögerung
NTP: +3588.9568856s Offset von SRV30.xxx.lokal
RefID: 80.84.77.86.rev.sfr.net [86.77.84.80]
Stratum: 4
Was übersehe ich, oder worin könnte das Problem begründet sein?
Danke im Voraus
Snoopycount
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: 3936154466
Url: https://administrator.de/forum/neuer-2022-dc-hinzugefuegt-uhrzeitprobleme-3936154466.html
Ausgedruckt am: 23.01.2025 um 03:01 Uhr
4 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani
- hast du in den Einstellungen der VM in Hyper-V die Zeitsychronisiation deaktiviert?
- Zeitzone, etc. ist auf allen Servern (auch Hyper-V) korrekt eingestellt?
- Holen sich alle Server die Zeit vom Server mit der FSMO PDC?
- Holt sich der Server mit PDC Rolle die Zeit bei einem NTP im Internet?
Gruß,
Dani
Moin,
als ntp-Quelle hast du für den Server 2 mögliche Ziele:
w32tm /monitor
SRV30.xxx.lokal * PDC *
Srv41.xxx.lokal[192.168.10.3:123]:
Und die beiden holen sich die Zeit auch noch von unterschiedlichen Quellen:
SRV30.xxx.lokal * PDC *
RefID: mail2.light-speed.de [85.214.83.151]
Srv41.xxx.lokal[192.168.10.3:123]:
RefID: 80.84.77.86.rev.sfr.net [86.77.84.80]
Wobei beide möglichen Quellen einen anderen Stratumswert haben (je kleiner der Wert, desto höher in der Hierarchie).
Grundsätzlich richte ich das NTP-Konstrukt immer so ein:
Firewall holt die Zeit beim ext. NTP-Server ab (https://www.pool.ntp.org/zone/de)
Der/ die DCs holen sich die Zeit von der Firewall (sowie Systeme, in in der DMZ liegen und nichts mit dem LAN/ AD am Hut haben)
Der/ die DCs verteilen dann alles an die Clients im LAN
somit haben immer alle die selbe Zeitquelle. Ist die FW mal nicht erreichbar (warum auch immer), behalten die DCs ihre zu letzt gültige Zeit...
als ntp-Quelle hast du für den Server 2 mögliche Ziele:
w32tm /monitor
SRV30.xxx.lokal * PDC *
Srv41.xxx.lokal[192.168.10.3:123]:
Und die beiden holen sich die Zeit auch noch von unterschiedlichen Quellen:
SRV30.xxx.lokal * PDC *
RefID: mail2.light-speed.de [85.214.83.151]
Srv41.xxx.lokal[192.168.10.3:123]:
RefID: 80.84.77.86.rev.sfr.net [86.77.84.80]
Wobei beide möglichen Quellen einen anderen Stratumswert haben (je kleiner der Wert, desto höher in der Hierarchie).
Grundsätzlich richte ich das NTP-Konstrukt immer so ein:
Firewall holt die Zeit beim ext. NTP-Server ab (https://www.pool.ntp.org/zone/de)
Der/ die DCs holen sich die Zeit von der Firewall (sowie Systeme, in in der DMZ liegen und nichts mit dem LAN/ AD am Hut haben)
Der/ die DCs verteilen dann alles an die Clients im LAN
somit haben immer alle die selbe Zeitquelle. Ist die FW mal nicht erreichbar (warum auch immer), behalten die DCs ihre zu letzt gültige Zeit...
Woher holt er sich den aktuellen timestamp?
Das würde ich zuerst immer überprüfen.
w32tm /query /source
Das würde ich zuerst immer überprüfen.
w32tm /query /source
Hallo zusammen
Danke für die Tipps.
Nachdem ich in der VM in Hyper-V die Zeitsychronisiation deaktiviert hatte ist die Zeit synchron.
SRV30.xxx.lokal * PDC *[192.168.10.2:123]:
ICMP: 0ms Verzögerung
NTP: +0.0000000s Offset von SRV30.xxx.lokal
RefID: mail2.light-speed.de [85.214.83.151]
Stratum: 3
Srv41.xxx.lokal[[xxxxxxx%6]:123]:
ICMP: Fehler 0x8007271D
NTP: +0.0029755s Offset von SRV30.xxx.lokal
RefID: SRV30.xxx.lokal [192.168.10.2]
Stratum: 4
SRV41 -> w32tm /query /source
SRV30.xxx.lokal
Gruß
Snoopycount
Danke für die Tipps.
Nachdem ich in der VM in Hyper-V die Zeitsychronisiation deaktiviert hatte ist die Zeit synchron.
SRV30.xxx.lokal * PDC *[192.168.10.2:123]:
ICMP: 0ms Verzögerung
NTP: +0.0000000s Offset von SRV30.xxx.lokal
RefID: mail2.light-speed.de [85.214.83.151]
Stratum: 3
Srv41.xxx.lokal[[xxxxxxx%6]:123]:
ICMP: Fehler 0x8007271D
NTP: +0.0029755s Offset von SRV30.xxx.lokal
RefID: SRV30.xxx.lokal [192.168.10.2]
Stratum: 4
SRV41 -> w32tm /query /source
SRV30.xxx.lokal
Gruß
Snoopycount
