5

OK. After a lot of fun with syncing time across my workstations, I got that sorted out. My workstations are now perfectly synced with my Server 2008 R2 Domain Controller (physical server, not virtual).

Unfortunately, that means all our computers are now WRONG because the time is incorrect!

I have configured the Domain Controller using a Group Policy as such:

  • enable Windows NTP Server (works great, all the workstations are pulling the wrong time from this server)
  • enable Windows NTP Client
  • configure Windows NTP Client

Config:

NtpServer: ca.pool.ntp.org,0x09
Type: NTP
CrossSiteSyncFlags: 2
ResolvePeerBackoffMinutes: 15
ResolvePeerBackoffMaxTimes: 7
SpecialPollInterval: 3600
EventLogFlags: 0

The output of w32tm /query /status is:

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.0949367s
Root Dispersion: 4.6343267s
ReferenceId: 0xC632918A (source IP:  198.50.145.138)
Last Successful Sync Time: 2014-08-05 11:34:35 AM
Source: ca.pool.ntp.org,0x09
Poll Interval: 6 (64s)

And w32tm /query /peers is:

#Peers: 1

Peer: ca.pool.ntp.org,0x09
State: Active
Time Remaining: 2064.7302675s
Mode: 3 (Client)
Stratum: 2 (secondary reference - syncd by (S)NTP)
PeerPoll Interval: 6 (64s)
HostPoll Interval: 6 (64s)

As far as I can tell, everything is right. But my current time is 11 minutes ahead of what http://time.gov/ says is the right time for my time zone. What the heck???

The worst part is if I do a w32tm /resync it gets the right time and everything drifts back into place, and then a few days later it's horribly wrong again so it's really hard to troubleshoot. Thoughts?

Improve this question
6
  • 1
    Why did you specify the 0x09 flag?
    – Ryan Ries
    Aug 5, 2014 at 18:15
  • It was originally set to time.windows.com,0x09 and a few discussions on the topic also suggested the same flag so I figured it was a good idea. I suppose it could be my problem (along with a trillion other things), I don't know a heck of a lot about NTP.
    – evilspoons
    Aug 5, 2014 at 18:36
  • Maybe try changing your NTP source to a particular stratum 2 server near you and see if that helps.
    – TheCleaner
    Aug 5, 2014 at 19:16
  • I use "w32tm /config /manualpeerlist:<ntp pool fqdn> /syncfromflags:manual /reliable:yes /update" and it seems to be accurate. What command line switches are you using?
    – Ian Murphy
    Aug 6, 2014 at 16:15
  • None, I am configuring it via the group policy above.
    – evilspoons
    Aug 6, 2014 at 20:56

1 Answer 1

Reset to default
1

CRUMMY ANSWER, I will switch the answer to a better one when a better one shows up. This is what I did for now.

I still have no idea why the group policy didn't work, but I "fixed" it by disabling the group policy that told it to enable and configure the NTP client (NTP server part is still on).

This broke the w32tm service on the server. W32tm simply returned some permission message, and "net start w32time" said something about the service being queued to be removed.

I had to reboot the server, run w32tm /register, reboot the server again, and then the server began using its own internal clock, which is more accurate than randomly skewing the NTP time forward by 10+ minutes in three days.

I will try the command line version of w32tm syncing from NTP at some future date, but I shouldn't have to do that - that's the entire point of group policy, no? I wanted to just be able to replace this DC with another one and have the NTP server set itself up.

I'm wondering if Microsoft's Group Policy templates are broken for the NTP client.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .