Best Practices: Time synchronization with virtual Domain Controllers
In Hyper-V virtualization, a guest virtual machine has something called “Integration Services.” By default, all of these services are pretty much enabled, including time synchronization. However, this can cause big issues if you have virtual Domain Controllers, and your physical host servers are not getting their time from a common, reliable source, such as an external NTP server like 0.us.pool.ntp.org, 1.us.pool.ntp.org, etc.
In particular, if a virtual host is running a guest Domain Controller, then the DC will be getting its time from the clock of the physical Hyper-V server at start-up. When these times get out of sync with other DC’s and virtual hosts (e.g. power outage, migration project, etc.), stuff gets funky quickly, as computers are constantly fighting each other, and confused about who to trust as regards time authority. As the time issues spread on your network, suddenly half your users report that they cannot log in to anything.
Keep only one time authority
Therefore, you need to decide who will be the central time authority on the network, and design everything else to refer back to that source. Why?
Because there should be only one time authority on the network, which in turn should be synchronized with a reliable NTP server. Set up your virtual hosts and/or primary Domain Controller to sync with an outside NTP server, and then set any other DC’s to refer to the primary DC only.
To see what your server is using as it’s time authority use:
w32tm /query /source
If integration services is enabled on your virtual machines, this will return a value like: VM IC Time Synchronization Provider. Disabling time integration services at least for virtual DC’s seems like a good idea, and arguably you should do this for all VM’s if you want the DC’s to be in charge of network time, without involving the underlying host systems. The other option is synchronize your Hyper-V hosts’ hardware clock to the NTP authority.
Option 1: Disable time synchronization for VM’s
To disable time synchronization on your virtual machines, use PowerShell as Administrator from the Hyper-V host servers:
Get-VM | Disable-VMIntegrationService -Name “Time Synchronization”
Or in the GUI: Hyper-V Manager > Virtual Machine > Settings > Integration Services:
Set time sync for your Domain Controllers
Next, on your DCs, reset the time authority. Microsoft offers a fix that helps you set an external time source such as “0.us.pool.ntp.org” (scroll down on that page–past the fix for syncing with an internal hardware clock).
You can also manually set the sync partner on the Domain Controller to fix time sync issues with this (as Administrator):
w32tm /config /syncfromflags:manual /manualpeerlist:”0.us.pool.ntp.org 1.us.pool.ntp.org” /reliable:yes /update
Net stop w32time
Net start w32time
w32tm /resync /force
After that, the network time should start falling into line, but you can also run w32tm /resync /force from any client computer to force a sync (or just reboot).
You should still use the Microsoft fix with this solution to set an external authority in the registry. If you go this route, then as double-extra precaution, on your virtual Domain Controllers, you might also “neuter” the time sync integration services from within the guest VM itself, with this registry key (from an elevated command prompt):
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0
This will disable the VMICTimeProvider after Windows boots, so the virtual server can default back to the external time authority that you have set. Using this precaution in the VM is good insurance, in case the time integration features accidentally get re-enabled down the road on the host (e.g. after a migration, export/import, backup/restore procedure, etc.).
Option 2: Alternative design with hardware-based NTP
If you would rather manage the time authority at the hardware level, and keep integration services enabled, that is also an option. Some hardware vendors have a firmware setting for configuring NTP, for example (see your vendor’s documentation). Make sure all physical/host servers refer to the same time authority, and make sure the Hyper-V host is set to refer to the hardware clock on the server using the Microsoft fix.
You will want to be careful with this during migrations in particular–make sure that you sync existing/physical domain controllers with an external time source, and any new servers you add should be set to sync in turn (remember: time cannot be off by more than 5 minutes or you will have problems).
Comments (14)
Alex….thanks for the info…I’ve struggle with my VM-DC’s getting “off sync” since Server 2012 ;-) So a quick question, are you saying to have ALL VM-DC’s use an external time source regardless the where the FSMO (PDC Emulator) role is located?
Hi Dale, I would just be consistent in the treatment of virtual machines. If you have the synchronization settings enabled, be sure that the hardware clocks are reliable and syncing with a known good NTP server. Otherwise, if you choose to disable VM time sync settings, then I set my domain controllers’ peers manually. It is okay if you set your other DC’s look to the PDC, but it is also okay to manually set peers on all DC’s to the same external provider.
Are you saying to configure ALL VM-DCs regardless of where the PDC-Emulator FMSO role is located?
Sorry…your site gave me an error…didn’t mean to post twice ;-)
Worked! Now my domain is perfect. I’m in Australia and used this time server:
0.au.pool.ntp.org
Thanks this helped a lot.
Thanks! helped a lot!
Leaving the Time Synchronisation enabled for the DC VM but disabling VMICTimeProvider via the registry allows the VM BIOS/UEFI to receive the correct local time at VM initialisation, but then allows W32Time to sync time from whichever time source it’s configured with.
It’s also a good idea to disable VMICTimeProvider on each boot, as updates can flip it back to an enabled state.
I am unable to configure NTP in domain controller which is virtual machine.
Please help me in configuring the NTP to client ntp server
Following this advice, do we still set the Hyper-V Host to manually sync time to the same ntp pool?
“Leaving the Time Synchronisation enabled for the DC VM but disabling VMICTimeProvider via the registry allows the VM BIOS/UEFI to receive the correct local time at VM initialisation, but then allows W32Time to sync time from whichever time source it’s configured with.
It’s also a good idea to disable VMICTimeProvider on each boot, as updates can flip it back to an enabled state.”
I stopped paying attention to this, and it’s been so long since I’ve worked with Hyper-V now… basically the principle would remain the same–ideally there should be one source of time authority rather than multiple. Just have to choose how you’re going to do that and remain consistent.
I follows 3 documentation almost identically. I have 3 virtualized machine as DC and GC and one of them are supposed to be TIME Provider but from unknown reasons simply do not want to be authoritative and because of this my Linux machines does not update time from it.
I spend one week trying to figure it out. Everything is in place.
have absolute no idea. Before joining domain, when it was SIMPLE server, i Expressly test the time server to be sure it will work also after join the domain and promote to DC and GC but now surprise surprise is not providing time anymore.
have absolute no idea what to do more.
Maybe run the AD BPA to see if there are any issues being reported there. As well, try resetting with w32tm–set peers, set as reliable and restart the service. See if it is advertising. Then see what client reports–it should be getting its time from DC, use w32tm again to check.
Thank you for your advice. I solve it in different way with help of other documentation. However it was a weird to require 4 documentations to be assembly in order to reach stratum 1.