In brief: Problem is due to PDC doing a fallback to Local Clock. Fix is to set PDC as NT5DS and set NTP server on BDC.
Look at this Reg entry. LocalClockDispersion
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\
LocalClockDispersion
This entry controls the dispersion (in seconds) that you must assume when the only time source is the built-in CMOS clock. The default value on domain members is 10. The default value on stand-alone clients and servers is 10.
http://technet.microsoft.com/en-us/library/cc773263(v=ws.10).aspx#w2k3tr_times_tools_uhlp
Mine was set to 10 as you pointed out but your post helped me locate the source of the problem in the InputProvider Registry key. This key indicates if the NTPServer provider is enabled. The default value on domain member is 1.
On my PDS, this was set to 0 instead of 1 which I got from your technet document. Changing it to 1 caused the PDC to start syncing with NT5DS. Next, because I was having so many problems with the PDC using its Local CMOS clock, I setup my BDC to be the Windows Time Server for my domain. It is set to pull its time sync from us.pool.ntp.org, 0x1 and it is working perfectly. Now I get the following on my PDC:C:\Windows\system32>w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 5 (secondary reference – syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.1414490s
Root Dispersion: 7.9517824s
ReferenceId: 0x0A0A0102 (source IP: 10.10.1.2)
Last Successful Sync Time: 7/27/2011 10:12:05 AM
Source: ApexDC2.ApexCost.local
Poll Interval: 7 (128s) The time on both DCs is now properly in sync with the external NTP server and my clients are in the process of updating their system time.
Be the first to comment