17.12.2019

2729

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

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 526216

Url: https://administrator.de/forum/uhrzeit-abweichung-an-dc-esx-etc-526216.html

Ausgedruckt am: 22.12.2024 um 10:12 Uhr

11 Kommentare

Neuester Kommentar

Moin,

Du gibst den DCs per GPO nen externen NTP Server mit, z.B. PTB Braunschweig.
Stell aber sicher, dass der NTP-Port in Eurer Firewall auch offen ist und der auch anfragen kann.

Gruß

Looser

Hi,

1:30min sehe ich als nicht kritisch an. Lass den DC einfach neu synchronisieren.
Schlimmer wäre es bei einem Versatz von 5min+ (Kerberos Tickets usw.).

LG

tomolpi

Moin,

Zitat von @hanshuepf000:
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)?

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.

Moin,

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,

Zitat von @Looser27:

Bitte nur für die den Domain Controller, welcher die FSMO Rolle PDC -Emulator inne hat.

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,

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,

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