Network Time vs. Hyper-V Time syncronization

I have dealt with incorrectly configured NTP in a domain several times – the worst case was where all client computers were off by 14 minutes from real time! Why did this happen? That happened because the GPO and w32tm settings were configured completely wrong and the authoritative time source for the domain was a local servers local hardware clock. The proper configuration for NTP in a domain is a whole post in itself, and that is not what I’ll be discussing here.

The problem I’m talking about is one that I experienced in my home lab – the problem is that the Hyper-V Time synchronization integration service has a higher priority than properly configured network time…which will cause headaches when you have a domain controller VM. This is only an issue if every domain controller in your environment is a VM – which is how my home lab is setup….another physical box just for a DC for home? I don’t think so.

This issue stems from the fact that my Hyper-V host is a domain member (and there’s only one domain) combined with the fact that my domain controllers are virtualized on that host. So I configured the PDCe to go get accurate time from the ntp.org pool, but the time continually drifted and would not update. Why does this happen? The Hyper-V host is giving the DC Time information via the VMBus (Time synchronization integration service). This time comes from the host hardware clock…which is syncronized to the logon server (it’s a domain member). So the domain controller is providing time to the Hyper-V host which is in turn resetting the VM clock thus causing the time to never sync to an accurate source.

The solution? Simple: disable the Time synchronization Integration Service on your DC(s):

 

Leave a Reply