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:
[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
And noticed that the NtpServer hive had missing keys, this was fixed by importing:
[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
I then amended the following existing keys to reduce phase:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config]
"MaxAllowedPhaseOffset"=dword:00000001
"SpecialPollInterval"=dword:00000005
"SpecialInterval"=dword:00000001
Once you are sure the registry is correct, Issue the following commands via Command Line as Administrator:
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
Waited a few minutes then checked sync
w32tm /monitor /computers:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM
It should look a bit like this:
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
Then check phase:
w32tm /stripchart /computer:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM
It should look like this:
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 [ * ]
Hope this helps!
NTP should work fine. Look at some of the options for fast synchronization on start-up. Look at the burst
and iburst
options for the system B. Look at the true
option for the GPS clock source.
Consider using the hardware clock as a backup time source on both systems. Set a higher stratum system B. Something like the following should work:
server 127.127.1.0
fudge 127.127.1.0 stratum 8
Watch the output of ntpq -c peers
to see when you get a trusted clock source. Normally ntp
wants a number of responses from a trusted time source before it trusts it. This is indicated by the first character on each line.
While NTP likes more sources, any odd number of time sources within one stratum level should work well. As you only have two servers and a GPS clock the priority (stratum) of the sources should increase from GPS, clock on server A, clock on server B. Increasing the stratum between each by three or four levels will ensure priorities are respected.
EDIT: If you have the busybox NTP server on server A, it may be worthwhile installing the full ntp server package. Understanding what is happening with server A should go a long way to solving your problem. You will need at least one trusted time source there before server B should trust it. If ntpq -c peers
doesn't work, then you can try ntpdc peers
. Both these commands allow you to query other hosts. A peerstats
log could also be useful.
On server B use ntpclient as documented the busybox ntp howto to log what is happening on it
The clocks should be reasonably close to the correct time if the servers haven't been down for long. If you need to sync the two systems, that should be sufficient. The GPS will bring the time into sync with the real world eventually.
'ntpd -q' synchronizes quickly, but exits (ntpdate behaviour). It needs to be followed by an ntpd
command without the quit option to have continuous synchronization.
EDIT2: I check my server and found one of the servers was off by a second. While fixing this I played with the settings. iburst
gets a server trusted very quickly. true
ensured the clock driver was trusted if there weren't multiple other trusted sources. The clock took a little more than a minute before it was locally trusted and could be trusted remotely.
When testing you should be able to restart the ntpd
process once it is synchronized and test how fast settings work. In the above case Server B may need to be restarted to test how fast it synchronizes. When monitoring ntpd
changes I use a line like:
while ntpq -c peers localhost; do sleep 10; done
The hostname and sleep time are adjusted as require. In some cases I chain two or more ntpq
command lines in the loop. When doing so I use an echo and/or date command to provide an indication of where sets of data change.
Best Answer
The PDC in your domain may simply be off by many seconds. Especially if it is drifting and not synced to anything. Check its performance with
w32tm /monitor /domain:
from a domain joined Windows box. For more useful commands, this previous question has a w32tm quick reference: How to find time server in a domain?Windows Server before 2016 was not designed for sub second accuracy. Often it achieves this anyway, so I'm still suspicious your domain's time keeping given the large error.
And a tip: configure chrony.conf (or ntp.conf) with
pool ad.example.org
. Active Directory best practice is to have more than one DC, and they're all in DNS as the domain name. Might as well use them all, like you did for the NTP public pool.