Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a domain controller configured to use (with 0x09 flags set). I've noticed that frequently the systems' clock is fast - it varies from 10 minutes to even 45 minutes. I always have to keep resetting the system date/time back to what it should be.

When I run "w32tm /query /source" it tells me it's using, and obviously I trust Microsoft not to serve incorrect times, but why is my server's clock fast?


There are a few Time-Service events in the System log:

Event ID: 142

Message: The time service has stopped advertising as a time source because the local clock is not synchronized.

Event ID: 139

Message: The time service has started advertising as a time source.

These two messages appear in pairs every hour or so. Event 142 appears 14 to 16 minutes after 139 appears.

Going back a few months, these events appear:

Event ID: 35

Message: The time service is now synchronizing the system time with the time source,0x9 (ntp.m|0x9|>

Event ID: 37

Message: The time provider NtpClient is currently receiving valid time data from,0x9 (ntp.m|0x9|>

Event ID: 47

Message: Time Provider NtpClient: No valid response has been received from manually configured peer,0x9 after 8 attempts to contact it. This peer will be discarded as a time source and NtpClient will attempt to discover a new peer with this DNS name. The error was: The time sample was rejected because: The peer is not synchronized, or it has been too long since the peer's last synchronization.

These three events only appear once in the log, back in October.


Here is the output of w32tm /query /status /verbose:

enter code here

C:\Users\Administrator>w32tm /query /status /verbose
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.1794868s
Root Dispersion: 4.6419912s
ReferenceId: 0x41371515 (source IP:
Last Successful Sync Time: 2011-12-05 23:25:18
Poll Interval: 6 (64s)

Phase Offset: 0.0000695s
ClockRate: 0.0156243s
State Machine: 1 (Hold)
Time Source Flags: 0 (None)
Server Role: 0 (None)
Last Sync Error: 2 (The computer did not resync because only stale time data was available.)
Time since Last Good Sync Time: 1281.9919104s
share|improve this question
Do you see synchronization-related events (source: Time-Service) in your system event log? If so, post the content please. –  the-wabbit Nov 25 '11 at 13:16
I've done this. –  Dai Nov 25 '11 at 14:39
Is the DC in question a Virtual Machine? –  Driftpeasant Dec 5 '11 at 23:43
No, it's a physical machine - every computer in the domain is physical. –  Dai Dec 6 '11 at 0:03

2 Answers 2

up vote 1 down vote accepted

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:


And noticed that the NtpServer hive had missing keys, this was fixed by importing:


I then amended the following existing keys to reduce phase:


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


It should look a bit like this:

    ICMP: 0ms delay
    NTP: +0.0496804s offset from local clock
        Stratum: 3

Then check phase:


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!

share|improve this answer

Is this the DC holding the PDC emulator role? You only would need to configure the one with the PDC emulator role with an external time source - other DCs automatically will synchronize to the PDC.

The current status of the time service can be obtained via w32tm /query /status /verbose - it should give you some details about the status of your local clock, the deviation at the last sync and the precision. According to your logged events, your local clock seems to be too unreliable for the time source. The default w32time synchronization interval would be at 1024 seconds after some successful synchronizations - this is around 17 minutes which is roughly the time difference between your events 139 and 142.

If this is a virtualized system, you should look at alternative timer hardware emulations. VMWare has published a comprehensive paper on this topic which is worth reading even when you use different virtualization products.

If this is a physical system, consider reducing the MaxPollInterval for the w32time service as a workaround or moving the PDC emulator role to a different machine with a more reliable clock.

Edit: the "stale time data" problem might indeed be a problem with the time server you are trying to query. Try replacing the default "" by a server from the public NTP pool (<region> in your NTP configuration (just use net time /setsntp:<servername>)

share|improve this answer
The server is a PDC Emulator. I've added the output of the command to my original question. –  Dai Dec 5 '11 at 23:24
I've added some notes. –  the-wabbit Dec 6 '11 at 22:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.