Manually syncing comp clock with DC works, but after a minute - clock incorrect by 5 minutes

Question

The problem:

DC1 Clock: 17:23
AD joined client clock: 17:28

After client> w32tm /resync time is in sync, but the clock again jumps forward for 5 minutes for client. It always happens in less than a minute.

Ok, maybe syncing from somwhere else. I did manually set peer list to domain controllers :

client>w32tm /config /manualpeerlist:"DC1 DC2 DC3" /syncfromflags:manual
The command completed successfully.

client>w32tm /resync
Sending resync command to local computer
The command completed successfully.

The result? Doesn't help, because behaviour is the same. I should note that the DC and client is in different subnets, but can communicate.

What should I check to further troubleshoot the situation, please?

Posting requested information:

client> w32tm /query /configuration
[Configuration]

EventLogFlags: 2 (Local)
AnnounceFlags: 10 (Local)
TimeJumpAuditOffset: 28800 (Local)
MinPollInterval: 10 (Local)
MaxPollInterval: 15 (Local)
MaxNegPhaseCorrection: 4294967295 (Local)
MaxPosPhaseCorrection: 4294967295 (Local)
MaxAllowedPhaseOffset: 300 (Local)

FrequencyCorrectRate: 4 (Local)
PollAdjustFactor: 5 (Local)
LargePhaseOffset: 50000000 (Local)
SpikeWatchPeriod: 900 (Local)
LocalClockDispersion: 10 (Local)
HoldPeriod: 5 (Local)
PhaseCorrectRate: 1 (Local)
UpdateInterval: 30000 (Local)


[TimeProviders]

NtpClient (Local)
DllName: C:\Windows\system32\w32time.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
CrossSiteSyncFlags: 2 (Policy)
AllowNonstandardModeCombinations: 1 (Local)
ResolvePeerBackoffMinutes: 15 (Policy)
ResolvePeerBackoffMaxTimes: 7 (Policy)
CompatibilityFlags: 2147483648 (Local)
EventLogFlags: 0 (Policy)
LargeSampleSkew: 3 (Local)
SpecialPollInterval: 3600 (Policy)
Type: NT5DS (Policy)

VMICTimeProvider (Local)
DllName: C:\Windows\System32\vmictimeprovider.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
NtpServer (Local)
DllName: C:\Windows\system32\w32time.dll (Local)
Enabled: 0 (Local)
InputProvider: 0 (Local)


client> get-date -format "yyyy.MM.dd hh:mm:ss"

2013.05.27 10:53:12 (Time WRONG)


client> w32tm /resync
Sending resync command to local computer
The command completed successfully.
client> get-date -format "yyyy.MM.dd hh:mm:ss"

2013.05.27 10:48:03 (Time OK)


client> w32tm /query /status
Leap Indicator: 3(last minute has 61 seconds)
Stratum: 0 (unspecified)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0804749s
Root Dispersion: 7.8843410s
ReferenceId: 0x00000000 (unspecified)
Last Successful Sync Time: 2013.05.27. 10:53:17
Source: DC1
Poll Interval: 10 (1024s)

client> get-date -format "yyyy.MM.dd hh:mm:ss"

2013.05.27 10:53:44 (Time WRONG)


client> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0804749s
Root Dispersion: 7.8845136s
ReferenceId: 0x0A0A0109 (source IP:  10.10.1.9)
Last Successful Sync Time: 2013.05.27. 10:48:17
Source: DC1
Poll Interval: 10 (1024s)

when it goes off by 5 minutes do a w32tm /query /status and post results. Also, if you can post w32tm /query /configuration (from an admin cmd) that might help others. — TheCleaner, May 24 '13 at 15:01
If it *is* a virtual machine, check if it is set to synchronize to the hypervisor's host clock. You very likely will find this to be the root of the problem. — the-wabbit, May 24 '13 at 16:06
@TheCleaner look at the edited question, I did post the results. — Janis Veinbergs, May 27 '13 at 08:01
Had the same issue with a virtual machine. Turned off the VM time sync setting (and fixed the clock) and the issue went away. — fiskfisk, Feb 25 '16 at 11:16

score 1 · Accepted Answer · answered Jun 03 '13 at 19:58

net stop w32time

w32tm /unregister

w32tm /register

net start w32time

You do not need to set manual peers in an Active Directory environment, with the sole exception of the forest root PDCe. Re-registering the w32tm service as shown above on the domain member will reset it to use the NT5DS or "domhier" setting, which is what it should be.

Afterwards, give the client a few minutes to organically locate a suitable DC for time sync. You can use w32tm /query /peers and verify that you are synchronizing with a domain controller.

Today, when I looked at the clocks, they looked okay. But I did these steps so everything is Ok. Thank you. — Janis Veinbergs, Jun 04 '13 at 07:10

Manually syncing comp clock with DC works, but after a minute - clock incorrect by 5 minutes

Posting requested information:

1 Answers1