Server 2012 R2 - Time syncronisation issues

[CHiLL]

We have had time issues a while back and had a third party confirmed that our setup was not 'best practice'. They managed to correct the time syncronisation issue however we could not at the time meet the best practice, which was defined as having one source, such as our HP core switch configured to connect to the external NTP server (such as 0.uk.pool.ntp.org) and all other devices syncronising with that.

 

Device / Computer / Client / Server / None PDC > PDC > Core Switch > 0.uk.pool.ntp.org

 

However we have had some more time issues where our non-PDC domain controller was out of sync this week and I am finding that our servers are still pointing to our non PDC domain controller. I checked this by running this command:

w32tm /query /source

 

I have followed best practice and set our HP core switch SNTP as 0.uk.pool.ntp.org and pointed our ESXi hosts and virtual PDC (DC2) to it. As far as I can tell, we have no GPO settings enabled for time syncronisation at all across our site, yet our Server 2012 R2 servers are pointing to DC1, which is a physical (not PDC) server.

 

I have tried:

w32tm /resync

and

net stop w32time
w32tm /unregister
w32tm /register
net start w32time

Both with no avail, as the servers still report their time server as DC1.

 

Running this command on the servers:

w32tm /query /peers /verbose

They are reporting this:

C:\Windows\system32>w32tm /query /peers /verbose
#Peers: 1

Peer: DC1.SJW.Internal
State: Active
Time Remaining: 1021.0781418s
Mode: 3 (Client)
Stratum: 4 (secondary reference - syncd by (S)NTP)
PeerPoll Interval: 17 (out of valid range)
HostPoll Interval: 10 (1024s)
Last Successful Sync Time: 23/05/2017 14:32:59
LastSyncError: 0x00000000 (Succeeded)
LastSyncErrorMsgId: 0x00000000 (Succeeded)
AuthTypeMsgId: 0x0000009B (NtSignature )
Resolve Attempts: 0
ValidDataCounter: 1
Reachability: 3

 

Whereas my Windows 10 workstation is returning:

C:\Windows\system32>w32tm /query /peers /verbose
#Peers: 1

Peer: DC2.SJW.Internal
State: Active
Time Remaining: 3685.3286835s
Mode: 3 (Client)
Stratum: 3 (secondary reference - syncd by (S)NTP)
PeerPoll Interval: 12 (4096s)
HostPoll Interval: 12 (4096s)
Last Successful Sync Time: 23/05/2017 14:35:25
LastSyncError: 0x00000000 (Succeeded)
LastSyncErrorMsgId: 0x00000000 (Succeeded)
AuthTypeMsgId: 0x0000009B (NtSignature )
Resolve Attempts: 0
ValidDataCounter: 8
Reachability: 255

 

How can I get our servers and any clients that are not currently pointing to DC2 to do so? Ideally without having to run a command on each one individually?

[mavhc]

Have you run Group Policy Results to see if there's an GPO settings being applied?

[CHiLL]

Have you run Group Policy Results to see if there's an GPO settings being applied?

I have just ran one against our SIMS server (which is reporting DC1 as the NTP server) and there are no references to any time settings.

I have just ran another against one of our pupil workstations and there are no references to any time settings.

[mavhc]

NTP could be set by DHCP, check options 4 and 42, also how do you image your computers?

[CHiLL]

DHCP only has open 006. 066 and 067 enabled. 004 and 042 are unchecked.

We use SCCM to image our machines.

[jthompson]

Do the event logs on the affected servers or DC1 give any clues (filtering events in the System log to the Time-Service source)? Given that your servers might have different firewall settings than your Win10 clients, could UDP port 123 be a factor?

[CHiLL]

Do the event logs on the affected servers or DC1 give any clues (filtering events in the System log to the Time-Service source)? Given that your servers might have different firewall settings than your Win10 clients, could UDP port 123 be a factor?

Filtering the event log for that type on DC1, it has reported the following today:

 

14:03:25 - Information - Event 139 - The time service has started advertising as a time source.

14:03:09 - Warning - Event 142 - The time service has stopped advertising as a time source because the local clock is not synchronized.

14:03:09 - Information - Event 35 - The time service is now synchronizing the system time with the time source DC2.SJW.Internal (ntp.d|0.0.0.0:123->10.22.11.12:123).

14:03:09 - Information - Event 139 - The time service has started advertising as a time source.

14:02:40 - Information - Event 37 - The time provider NtpClient is currently receiving valid time data from DC2.SJW.Internal (ntp.d|0.0.0.0:123->10.22.11.12:123).

 

 

 

 

There are no entries for yesterday, in fact nothing until back on 12/05/2017 and earlier, where the error was:

Warning - Event 129 - NtpClient was unable to set a domain peer to use as a time source because of discovery error. NtpClient will try again in 15 minutes and double the reattempt interval thereafter. The error was: The entry is not found. (0x800706E1)

Edited May 23, 2017 by CHiLL

[jthompson]

I think the first four of those events (happening in reverse order, although a few happen at the same time) can be explained by the way in which Windows syncs time: if there's a difference, it doesn't correct that difference all in one big go, it reduces it by smaller and smaller jumps so that the clocks align themselves smoothly. DC1 had a time difference from DC2, so it stopped advertising itself as a time source until the difference was sufficiently small.

 

None of which really helps with your problem, though. I don't know enough about domain controllers to know what the default behaviour is here. Perhaps try pointing one of your 2012 servers to DC2 and then see if it reverts itself back to DC1 after a spell? At least if it does stay with DC2, you would have a way of keeping them synced, even though you didn't want to be running commands to achieve it.

[CHiLL]

Appears as though we've sussed it. It appears that DC1 was not synchronising with DC2, but instead synchronising with it's internal CMOS clock. This would explain the time drift as DC1 is a separate physical server, compared to DC2 which is a virtual.

 

By running these commands on DC1, it was able to synchronise with DC2:

w32tm /config /syncfromflags:domhier /reliable:no /update	
net stop w32time 
net start w32time
w32tm.exe /resync
W32TM /query /status

 

As for the other servers and workstations - it appears that they will receive their time from their logon server, which could be either DC. We just have to tell each DC in the domain to inherit the time from the PDCe using the commands above. The important thing is that DC1 and DC2 are syncing correctly.

[Sephiroth]

When did you notice this happening? I've just corrected a very similar issue with our 3 DCs where one would occasionally just jump ~20 minutes forward, completely messing up any clients using it at the time. it would correct itself as soon as anyone logged onto it.

 

Running he above commands on the non-PDC DCs seems to have resolved it though.

 

Edit: I've also changed our main external time server to time.google.com. I don't believe that this will have had much effect, but I've been meaning to do it for a while.

Edited May 25, 2017 by Sephiroth

[CHiLL]

When did you notice this happening? I've just corrected a very similar issue with our 3 DCs where one would occasionally just jump ~20 minutes forward, completely messing up any clients using it at the time. it would correct itself as soon as anyone logged onto it.

 

Running he above commands on the non-PDC DCs seems to have resolved it though.

 

Edit: I've also changed our main external time server to time.google.com. I don't believe that this will have had much effect, but I've been meaning to do it for a while.

We noticed it late on Monday afternoon.

[Sephiroth]

I noticed this specifically during Tuesday. I think our issue might have stemmed from the change to BST though, so possibly not the same thing.