I have a domain controller configured to use time.windows.com (with 0x09 flags set). I've noticed that frequently the systems' clock is fast - it varies from 10 minutes to even 45 minutes. I always have to keep resetting the system date/time back to what it should be.
When I run "w32tm /query /source" it tells me it's using time.windows.com, and obviously I trust Microsoft not to serve incorrect times, but why is my server's clock fast?
EDIT:
There are a few Time-Service events in the System log:
Event ID: 142
Message: The time service has stopped advertising as a time source because the local clock is not synchronized.
Event ID: 139
Message: The time service has started advertising as a time source.
These two messages appear in pairs every hour or so. Event 142 appears 14 to 16 minutes after 139 appears.
Going back a few months, these events appear:
Event ID: 35
Message: The time service is now synchronizing the system time with the time source time.windows.com,0x9 (ntp.m|0x9|0.0.0.0:123->65.55.21.21:123).
Event ID: 37
Message: The time provider NtpClient is currently receiving valid time data from time.windows.com,0x9 (ntp.m|0x9|0.0.0.0:123->65.55.21.21:123).
Event ID: 47
Message: Time Provider NtpClient: No valid response has been received from manually configured peer time.windows.com,0x9 after 8 attempts to contact it. This peer will be discarded as a time source and NtpClient will attempt to discover a new peer with this DNS name. The error was: The time sample was rejected because: The peer is not synchronized, or it has been too long since the peer's last synchronization.
These three events only appear once in the log, back in October.
EDIT:
Here is the output of 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
I had the same issue and finally resolved it this morning. Here is what I did:
Have a look in the registry (all hives and keys in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time) on both the server with the time issue and another member server that is syncing ntp correctly.
I found a few discrepancies and exported the required keys \ hives from the working server to the broken one. The following keys had been messed up, here is the good keys I exported from the working box onto the broken one. Please note that these values may not be the same as yours so please dont use the keys below:
The security Hive was missing so I recreated with this:
And noticed that the NtpServer hive had missing keys, this was fixed by importing:
I then amended the following existing keys to reduce phase:
Once you are sure the registry is correct, Issue the following commands via Command Line as Administrator:
Waited a few minutes then checked sync
It should look a bit like this:
Then check phase:
It should look like this:
Hope this helps!
Is this the DC holding the PDC emulator role? You only would need to configure the one with the PDC emulator role with an external time source - other DCs automatically will synchronize to the PDC.
The current status of the time service can be obtained via
w32tm /query /status /verbose- it should give you some details about the status of your local clock, the deviation at the last sync and the precision. According to your logged events, your local clock seems to be too unreliable for the time source. The default w32time synchronization interval would be at 1024 seconds after some successful synchronizations - this is around 17 minutes which is roughly the time difference between your events 139 and 142.If this is a virtualized system, you should look at alternative timer hardware emulations. VMWare has published a comprehensive paper on this topic which is worth reading even when you use different virtualization products.
If this is a physical system, consider reducing the MaxPollInterval for the w32time service as a workaround or moving the PDC emulator role to a different machine with a more reliable clock.
Edit: the "stale time data" problem might indeed be a problem with the time server you are trying to query. Try replacing the default "time.windows.com" by a server from the public NTP pool (
<region>.pool.ntp.org) in your NTP configuration (just usenet time /setsntp:<servername>)