Virtual Domain Controllers and Time Synchronisation
The question of how to handle virtual Domain Controllers has been around for quite some time. The answer really depends on what product you have decided to use as your virtualisation platform: Microsoft or VMWare. Regardless of the product you have choosen, you will still have to make the same decision when it comes to Domain Controllers: How will I handle Time Synchronisation? Before I go into the details there is one thing that both companies agree on. Do not let your VMs use more than one method for Time Sync as this could lead to numerous time changes ... and you most definatly do not want this happening on Domain Controllers.
Side Note: Its worth noting that the challenge of Time Sync in a Virtual environment is not a bug or an issue related to how either vendor approaches virtualisation. The problem is the hardware virtualisation, more specially the virtual CPU. The phyiscal CPU's cycles help keep the time in sync just like a clock mechanisim. When the hardware is virtual, you no longer have the physical cycles to stop the time drifting.
Right, so how do the two approaches differ? Well, keeping in mind that both agree you should only use one method for time sync here are the two approaches:
- Microsoft: DISABLE the "Virtual Machine Additions" ability to sync time with the host. Use the normal domain hierarchy for Domain Controllers with the exception of the PDC in the forest root. Configre the PDC to use an external NTP source
- VMWare: ENABLE the "VMWare Tools" Time Synchronisation with the host. Disable the normal domain hierarchy for Domain Controllers. Additionally, install the NTP Daemon on the ESX host and have it sync with an external NTP source.
Microsoft do not recommend sync'ing with the physical host whereas VMWare recommend you do. So, from a supportability stance, which option do you choose? Good question! No surprises, but I would recommend starting with the Microsoft approach regardless of whether you are using ESX or not. Why? Well, from a support perspective following the VMWare approach means that you have to stop time sync from working as it should in a normal Active Directory Domain. If you run into problems and try and open a support case, you are putting yourself at a distinct disadvantage.
From experience, the busier the physical host the more likely you are to have time sync issues. The the virtual cpu cycles can go a little bit "wonky" sometimes. If you are running a test/lab environment I wouldn't be too worried. If you are running Domain Controllers in a product environment, well, keep a very close eye on things.
References:
Considerations when hosting Active Directory domain controller in virtual hosting environments
Support policy for Microsoft software running in non-Microsoft hardware virtualization software
VMware Time Sync and Windows Time Service
