Ich habe einen Domänencontroller so konfiguriert, dass er time.windows.com verwendet (mit gesetzten 0x09-Flags). Mir ist aufgefallen, dass die Systemuhr häufig vorgeht – sie schwankt zwischen 10 und sogar 45 Minuten. Ich muss das Datum/die Uhrzeit des Systems immer wieder auf den richtigen Wert zurücksetzen.
Wenn ich „w32tm /query /source“ ausführe, wird mir angezeigt, dass time.windows.com verwendet wird, und natürlich vertraue ich darauf, dass Microsoft keine falschen Zeiten liefert, aber warum geht die Uhr meines Servers vor?
BEARBEITEN:
Es gibt einige Zeitdienstereignisse im Systemprotokoll:
Ereignis-ID: 142
Nachricht: Der Zeitdienst hat die Werbung als Zeitquelle beendet, da die lokale Uhr nicht synchronisiert ist.
Ereignis-ID: 139
Nachricht: Der Zeitdienst hat begonnen, als Zeitquelle zu werben.
Diese beiden Meldungen werden etwa stündlich paarweise angezeigt. Ereignis 142 wird 14 bis 16 Minuten nach dem Erscheinen von Ereignis 139 angezeigt.
Wenn wir ein paar Monate zurückblicken, erscheinen diese Ereignisse:
Ereignis-ID: 35
Meldung: Der Zeitdienst synchronisiert jetzt die Systemzeit mit der Zeitquelle time.windows.com,0x9 (ntp.m|0x9|0.0.0.0:123->65.55.21.21:123).
Ereignis-ID: 37
Meldung: Der Zeitanbieter NtpClient empfängt derzeit gültige Zeitdaten von time.windows.com,0x9 (ntp.m|0x9|0.0.0.0:123->65.55.21.21:123).
Ereignis-ID: 47
Meldung: Zeitanbieter NtpClient: Vom manuell konfigurierten Peer time.windows.com,0x9 wurde nach 8 Kontaktversuchen keine gültige Antwort empfangen. Dieser Peer wird als Zeitquelle verworfen und NtpClient versucht, einen neuen Peer mit diesem DNS-Namen zu finden. Der Fehler war: Die Zeitprobe wurde abgelehnt, weil: Der Peer nicht synchronisiert ist oder die letzte Synchronisierung des Peers zu lange her ist.
Diese drei Ereignisse erscheinen nur einmal im Protokoll, und zwar im Oktober.
BEARBEITEN:
Hier ist die Ausgabe von w32tm /query /status /verbose:
enter code here
C:\Users\Administrator>w32tm /query /status /verbose
Leap Indicator: 3(last minute has 61 seconds)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.1794868s
Root Dispersion: 4.6419912s
ReferenceId: 0x41371515 (source IP: 65.55.21.21)
Last Successful Sync Time: 2011-12-05 23:25:18
Source: time.windows.com,0x9
Poll Interval: 6 (64s)
Phase Offset: 0.0000695s
ClockRate: 0.0156243s
State Machine: 1 (Hold)
Time Source Flags: 0 (None)
Server Role: 0 (None)
Last Sync Error: 2 (The computer did not resync because only stale time data was available.)
Time since Last Good Sync Time: 1281.9919104s
Antwort1
Ich hatte das gleiche Problem und habe es heute Morgen endlich gelöst. Folgendes habe ich getan:
Sehen Sie sich die Registrierung (alle Strukturen und Schlüssel in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time) sowohl auf dem Server mit dem Zeitproblem als auch auf einem anderen Mitgliedsserver an, der NTP korrekt synchronisiert.
Ich habe ein paar Unstimmigkeiten gefunden und die erforderlichen Schlüssel/Hives vom funktionierenden Server auf den defekten exportiert. Die folgenden Schlüssel waren durcheinander geraten, hier sind die guten Schlüssel, die ich vom funktionierenden Server auf den defekten exportiert habe. Bitte beachten Sie, dass diese Werte möglicherweise nicht mit Ihren übereinstimmen. Verwenden Sie daher bitte nicht die folgenden Schlüssel:
Der Sicherheits-Hive fehlte, deshalb habe ich ihn folgendermaßen neu erstellt:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Security]
"Security"=hex:01,00,04,80,84,00,00,00,90,00,00,00,00,00,00,00,14,00,00,00,02,\
00,70,00,05,00,00,00,00,00,14,00,fd,01,02,00,01,01,00,00,00,00,00,05,12,00,\
00,00,00,00,18,00,ff,01,0f,00,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,\
00,00,00,14,00,8d,01,02,00,01,01,00,00,00,00,00,05,04,00,00,00,00,00,14,00,\
8d,01,02,00,01,01,00,00,00,00,00,05,06,00,00,00,00,00,14,00,9d,01,02,00,01,\
01,00,00,00,00,00,05,13,00,00,00,01,01,00,00,00,00,00,05,12,00,00,00,01,01,\
00,00,00,00,00,05,12,00,00,00
Und ich habe bemerkt, dass im NtpServer-Hive Schlüssel fehlten. Dies wurde durch den Import behoben:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpServer]
"DllName"=hex(2):25,00,73,00,79,00,73,00,74,00,65,00,6d,00,72,00,6f,00,6f,00,\
74,00,25,00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,77,\
00,33,00,32,00,74,00,69,00,6d,00,65,00,2e,00,64,00,6c,00,6c,00,00,00
"Enabled"=dword:00000000
"InputProvider"=dword:00000000
"AllowNonstandardModeCombinations"=dword:00000001
"EventLogFlags"=dword:00000000
"ChainEntryTimeout"=dword:00000010
"ChainMaxEntries"=dword:00000080
"ChainMaxHostEntries"=dword:00000004
"ChainDisable"=dword:00000000
"ChainLoggingRate"=dword:0000001e
Ich habe dann die folgenden vorhandenen Schlüssel geändert, um die Phase zu reduzieren:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config]
"MaxAllowedPhaseOffset"=dword:00000001
"SpecialPollInterval"=dword:00000005
"SpecialInterval"=dword:00000001
Wenn Sie sicher sind, dass die Registrierung korrekt ist, geben Sie die folgenden Befehle über die Befehlszeile als Administrator ein:
w32tm /config /manualpeerlist:"YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM,0x01" /syncfromflags:MANUAL /update
net stop w32time && net start w32time
w32tm /resync /computer:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM /rediscover
Ein paar Minuten gewartet und dann die Synchronisierung überprüft
w32tm /monitor /computers:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM
Es sollte ungefähr so aussehen:
YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM[IPOFYOUR.NTP.OR.DC:123]:
ICMP: 0ms delay
NTP: +0.0496804s offset from local clock
RefID: YOURNTPSERVER-OR-PDCHERE [IPOFYOUR.NTP.OR.PDC]
Stratum: 3
Dann Prüfphase:
w32tm /stripchart /computer:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM
Es sollte so aussehen:
10:08:42 d:+00.0000000s o:+00.0139224s [ * ]
10:08:44 d:+00.0000000s o:-00.0015659s [ * ]
10:08:46 d:+00.0000000s o:-00.0014534s [ * ]
10:08:48 d:+00.0000000s o:-00.0013418s [ * ]
10:08:50 d:+00.0000000s o:-00.0012421s [ * ]
Hoffe das hilft!
Antwort2
Ist dies der DC, der die PDC-Emulatorrolle innehat? Sie müssten nur den DC mit der PDC-Emulatorrolle mit einer externen Zeitquelle konfigurieren – andere DCs werden automatisch mit dem PDC synchronisiert.
Den aktuellen Status des Zeitdienstes können Sie über abrufen w32tm /query /status /verbose– er sollte Ihnen einige Details zum Status Ihrer lokalen Uhr, der Abweichung bei der letzten Synchronisierung und der Genauigkeit geben. Laut Ihren protokollierten Ereignissen scheint Ihre lokale Uhr für die Zeitquelle zu unzuverlässig zu sein. Das Standardsynchronisierungsintervall von w32time würde nach einigen erfolgreichen Synchronisierungen bei 1024 Sekunden liegen – das sind etwa 17 Minuten, was ungefähr der Zeitdifferenz zwischen Ihren Ereignissen 139 und 142 entspricht.
Wenn es sich um ein virtualisiertes System handelt, sollten Sie sich alternative Timer-Hardware-Emulationen ansehen. VMWare hat eineumfassendes Papier zu diesem Themadessen Lektüre sich auch dann lohnt, wenn Sie unterschiedliche Virtualisierungsprodukte verwenden.
Handelt es sich um ein physisches System, können Sie als Workaround das Reduzieren des MaxPollInterval für den w32time-Dienst oder das Verschieben der PDC-Emulatorrolle auf einen anderen Computer mit einer zuverlässigeren Uhr in Erwägung ziehen.
Bearbeiten: Das Problem mit den „veralteten Zeitdaten“ könnte tatsächlich ein Problem mit dem Zeitserver sein, den Sie abfragen möchten. Versuchen Sie, den Standard „time.windows.com“ durch einen Server aus dem öffentlichen NTP-Pool zu ersetzen (<region>.pool.ntp.org) in Ihrer NTP-Konfiguration (verwenden Sie einfach net time /setsntp:<servername>)