Uhrzeit Abweichung an DC, ESX etc
Hallo Forum,
wir haben derzeit bei uns im Netzwerk das Problem, dass die Uhrzeit der DCs etwas 1 Minute 30 Sekunden vor geht.
Clients, ESX Server, Storagesysteme etc. syncen auch mit den DCs und gehen daher "gleich falsch".
Ursache war, dass der DC seinen NTP Server längere Zeit nicht mehr erreichen konnte.
Jetzt meine Frage:
Wie gehe ich am besten vor, bzw. wann lasse ich den DC wieder synchronisieren?
Kann ich einfach im laufenden Betrieb mit w32tm am DC wieder syncen, oder habe ich da ggf. Probleme (z.B. Exchange, SQL, ESX)?
Grüße
-Hansi
wir haben derzeit bei uns im Netzwerk das Problem, dass die Uhrzeit der DCs etwas 1 Minute 30 Sekunden vor geht.
Clients, ESX Server, Storagesysteme etc. syncen auch mit den DCs und gehen daher "gleich falsch".
Ursache war, dass der DC seinen NTP Server längere Zeit nicht mehr erreichen konnte.
Jetzt meine Frage:
Wie gehe ich am besten vor, bzw. wann lasse ich den DC wieder synchronisieren?
Kann ich einfach im laufenden Betrieb mit w32tm am DC wieder syncen, oder habe ich da ggf. Probleme (z.B. Exchange, SQL, ESX)?
Grüße
-Hansi
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 526216
Url: https://administrator.de/contentid/526216
Ausgedruckt am: 20.11.2024 um 01:11 Uhr
11 Kommentare
Neuester Kommentar
Moin,
Wann immer Du willst.
Ja.
Nein, so lange die Abweichung nicht mehr als fünf Minuten beträgt.
Liebe Grüße
Erik
Zitat von @hanshuepf000:
Wie gehe ich am besten vor, bzw. wann lasse ich den DC wieder synchronisieren?
Wie gehe ich am besten vor, bzw. wann lasse ich den DC wieder synchronisieren?
Wann immer Du willst.
Kann ich einfach im laufenden Betrieb mit w32tm am DC wieder syncen,
Ja.
oder habe ich da ggf. Probleme (z.B. Exchange, SQL, ESX)?
Nein, so lange die Abweichung nicht mehr als fünf Minuten beträgt.
Liebe Grüße
Erik
Moin,
> > oder habe ich da ggf. Probleme (z.B. Exchange, SQL, ESX)?
Das würde ich schon ein bisschen differenzierter betrachten. Die Betriebssysteme und Services an sich haben damit kein Problem, wenn sie 1:30 in die Vergangenheit gebeamt werden. Wie sich allerdings die SQL-Anwendungen verhalten wenn Timestamps plötzlich doppelt vorkommen (könnten) kannst nur du beantworten.
Und btw: Den ESXi würde ich nicht mit dem DC syncen, sondern direkt mit einem NTP
lg,
Slainte
> > oder habe ich da ggf. Probleme (z.B. Exchange, SQL, ESX)?
Nein, so lange die Abweichung nicht mehr als fünf Minuten beträgt.
Das würde ich schon ein bisschen differenzierter betrachten. Die Betriebssysteme und Services an sich haben damit kein Problem, wenn sie 1:30 in die Vergangenheit gebeamt werden. Wie sich allerdings die SQL-Anwendungen verhalten wenn Timestamps plötzlich doppelt vorkommen (könnten) kannst nur du beantworten.
Und btw: Den ESXi würde ich nicht mit dem DC syncen, sondern direkt mit einem NTP
lg,
Slainte
Ganz zu Schweigen von VoIP Telefonie (unstabiles SIP und RTP verhalten).
Oder gar (falls vorhanden) Voice Recording (unlesbar).
Am besten einen zweiten NTP eintragen. Falls der erste nicht erreichbar ist.
Am besten über die Reg: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer
Dort dann im Wert einfach "PTB Braunschweig,0x01 WASauchIMMER,0x02" eintragen.
Eine Liste findet sich im Internetz
0x01 bedeutet "Interval", also abfrage nacheinander vergleichend
0x02 bedeutet "Backup"
0x04 SymmatricActive und 0x08 Client sind meiner Meinung nach absolut sinn-freie und noch verfügbare Optionen.
Oder gar (falls vorhanden) Voice Recording (unlesbar).
Am besten einen zweiten NTP eintragen. Falls der erste nicht erreichbar ist.
Am besten über die Reg: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer
Dort dann im Wert einfach "PTB Braunschweig,0x01 WASauchIMMER,0x02" eintragen.
Eine Liste findet sich im Internetz
0x01 bedeutet "Interval", also abfrage nacheinander vergleichend
0x02 bedeutet "Backup"
0x04 SymmatricActive und 0x08 Client sind meiner Meinung nach absolut sinn-freie und noch verfügbare Optionen.
Moin,
Gruß,
Dani
Du gibst den DCs per GPO nen externen NTP Server mit, z.B. PTB Braunschweig.
das ist so nicht ganz richtig. Bitte nur für die den Domain Controller, welcher die FSMO Rolle PDC -Emulator inne hat. Alle anderen Clients/Server (ja auch weitere DCs) holen sich automatisch dort die Zeit. Das Ganze kann man natürlich elegant mit einer GPO abbilden, damit die Richtlinie immer nur für den DC gilt, der die Rolle inne hat. Somit spart man sich Zeit und Nerven. Kann ich einfach im laufenden Betrieb mit w32tm am DC wieder syncen, oder habe ich da ggf. Probleme (z.B. Exchange, SQL, ESX)?
Auf jeden Fall sicherstellen, dass die VMs die Uhrzeit nicht vom ESXi-Host über die VMWare Tools sychronisieren. Denn geht die Uhrzeit auf dem Host falsch, wird diese auch automatisch (inkl. DC falls dieser virtuell ist) ebenfalls falsch gehen.Gruß,
Dani
Bitte nur für die den Domain Controller, welcher die FSMO Rolle PDC -Emulator inne hat.
Aus Interesse...Warum? Bei uns haben beide DCs einen externen NTP eingetragen, denn wenn der DC mit den FSMO Rollen ausfällt, ist keine aktuelle Netzwerkzeit mehr vorhanden. Läuft bei uns schon immer so und völlig problemlos......
Gruß
Looser
Moin,
Weil sich die Clients immer beim PDC ihre Zeit holen. Nun stell Dir vor, dass beim PDC der Abgleich mit dem Zeitserver warum auch immer schief läuft und so die Uhren falsch gehen. Dann hat nur der zweite DC noch die richtige Zeit. Alle anderen haben die falsche. Wenn sich nun ein Client/User beim zweiten DC authentifiziert und die Uhren weiter als fünf Minuten auseinandergelaufen sind, dann gibt es seltsame Fehler. Es ist also besser, wenn alle die falsche Zeit haben, als das nur einer die richtige hat.
Liebe Grüße
Erik
Zitat von @Looser27:
Aus Interesse...Warum? Bei uns haben beide DCs einen externen NTP eingetragen, denn wenn der DC mit den FSMO Rollen ausfällt, ist keine aktuelle Netzwerkzeit mehr vorhanden. Läuft bei uns schon immer so und völlig problemlos......
Bitte nur für die den Domain Controller, welcher die FSMO Rolle PDC -Emulator inne hat.
Aus Interesse...Warum? Bei uns haben beide DCs einen externen NTP eingetragen, denn wenn der DC mit den FSMO Rollen ausfällt, ist keine aktuelle Netzwerkzeit mehr vorhanden. Läuft bei uns schon immer so und völlig problemlos......
Weil sich die Clients immer beim PDC ihre Zeit holen. Nun stell Dir vor, dass beim PDC der Abgleich mit dem Zeitserver warum auch immer schief läuft und so die Uhren falsch gehen. Dann hat nur der zweite DC noch die richtige Zeit. Alle anderen haben die falsche. Wenn sich nun ein Client/User beim zweiten DC authentifiziert und die Uhren weiter als fünf Minuten auseinandergelaufen sind, dann gibt es seltsame Fehler. Es ist also besser, wenn alle die falsche Zeit haben, als das nur einer die richtige hat.
Liebe Grüße
Erik
Moin,
Gruß,
Dani
Aus Interesse...Warum? Bei uns haben beide DCs einen externen NTP eingetragen, denn wenn der DC mit den FSMO Rollen ausfällt, ist keine aktuelle Netzwerkzeit mehr vorhanden. Läuft bei uns schon immer so und völlig problemlos......
Alle anderen DCs holen sich beim DC mit der FSMO Rolle PDC Emulator ebenfalls ihre Zeit. Im Worst Case hast du somit Clients und Server mit der richtigen und falschen Uhrzeit. Da hast du ein schönes Chaos im Netzwerk, was nicht sein muss. Hier wird das Ganze nochmals erklärt.Weil sich die Clients immer beim PDC ihre Zeit holen.
Nicht ganz, die Workstation holt sich beim LOGON-Server (=DC) die Uhrzeit. Sonst würde in großen Netzwerken der DC mit PDC Emulator ganz schön was zu tun haben.Gruß,
Dani
Moin,
Da hast Du natürlich recht. Das macht die Sache aber eher noch schlimmer.
Liebe Grüße
Erik
Zitat von @Dani:
Weil sich die Clients immer beim PDC ihre Zeit holen.
Nicht ganz, die Workstation holt sich beim LOGON-Server (=DC) die Uhrzeit. Sonst würde in großen Netzwerken der DC mit PDC Emulator ganz schön was zu tun haben.Da hast Du natürlich recht. Das macht die Sache aber eher noch schlimmer.
Liebe Grüße
Erik
Moin,
vielen Dank für die Erklärung. Ich habe das, wie im Link von @Dani beschrieben korrigiert.
Gruß
Looser
vielen Dank für die Erklärung. Ich habe das, wie im Link von @Dani beschrieben korrigiert.
Gruß
Looser