We have a Windows Server 2003 SP2 VM running on Hyper-V (Server 2008 R2 host). The VM has Hyper-V time synchronization enabled.

I noticed that the time on the VM was fast by around 25 minutes. I saw the following in the event log:

  • The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible. No attempt to contact a source will be made for 15 minutes. NtpClient has no source of accurate time.

  • The time provider NtpClient cannot reach or is currently receiving invalid time data from ourdc.ourdomain.local (ntp.d|>

  • Time Provider NtpClient: No valid response has been received from domain controller ourdc.ourdomain.local after 8 attempts to contact it. This domain controller will be discarded as a time source and NtpClient will attempt to discover a new domain controller from which to synchronize.

I had been logged in as a local user. (We have an old app that runs on this VM - it requires a user to be logged in at all times, and we use a non-domain user account for this.)

When I logged in as a domain user, the clock almost immediately corrected itself. Running "w32tm /monitor" and "net time" as the domain user showed no errors, and indicated that our domain controller was the time source.

Does anyone know what might cause this, and why logging in under a domain account fixes the problem? I'm wondering if the time will start to drift again.

Thanks for your help,

  • 1
    I'm not sure what the cause is, but I have the same problem on our 2003 VMs. Personally I disable the Hyper-V time sync, disable the service on the VM and restart the Windows Time service to get it syncing with the DCs. – Chris McKeown Apr 5 '12 at 20:52
  • Thanks Chris - I followed these three steps and it seems to be working now. I'll keep an eye on it to see if it continues to drift... – Richard Beier Apr 8 '12 at 5:16

What i learned from experience on the field: -Sync all hypervisor to your DC (create a round robin dns like ntp.mydomain.local to each DC) -The DC that has the fsmo "pdc emulator" must sync to an official ntp server. Only him must do that. -all DC running as VM mustn't sync time through hyper-v or vmware tools.

When a VM start, hypervisor emulate a bios, with a time and date. This is taken from the current date & time of the hypervisor. That's why they must on time, and especially on AD time, even if they are workgroup.

More than 5mn difference will break kerberos by default.

Check for time on all hypervisor and DC.

Here is a poor script i use that give offset between computers and a reference one (choose the dc with pdc emulator FSMO): (long line). Must have psexec on the current folder, and feed servers.txt with one server per line to checkup

for /f %s in (servers.txt) do echo %s >> ntp_stripchart.txt && psexec \\%s w32tm /stripchart /computer:myspecialDC /period:1 /dataonly /samples:1 >> ntp_stripchart.txt && echo -------- >> ntp_stripchart.txt
| improve this answer | |
  • Thanks Mathieu - this is good information. I'm not responsible for our overall domain - mostly just for this hyper-V server and a couple others. But I'll talk to our main network administrator about it. I'll try running your script to check how far out of sync our machines are. – Richard Beier Apr 8 '12 at 5:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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