A Small Concern When Virtualizing Domain Controllers - Time Sync

I'm sure this might open a can of worms, but it's a discussion that needs to happen. As virtualization technologies come into maturity, customers are more and more leaning towards virtualizing all of their infrastructure services. This includes Active Directory. Virtualizing Domain Controllers has been going on for some time now and was at first completely unsupported and even recommended against. That stance is changing considerably now, and we're beginning to see some official recommendations addressing this issue.

Let me first emphasize following the guidance set forth in this article: https://technet.microsoft.com/en-us/library/dd363553.aspx which contains official recommendations when virtualizing domain controllers in Hyper-V. The big 3 “don’t dos” are: never user differencing disks, don’t clone the guest without SYSPREPing it first, and don’t copy a VHD of a previously installed DC as the base for a new one. Those are all pretty straight forward to keep you from having SID conflicts or USN rollback issues which will totally mess up your AD installation.

Now, the next big issue is Time Sync. Microsoft recommends disabling host to guest time synchronization so that all DCs will use the default Windows Time service hierarchy just like a physical server. That’s not so hard, right? Just go into Hyper-V and disable that feature from the Integration Services settings. Easy. Done.

But: what about DCs running virtualized on VMWare [for the sake of discussion, let’s assume the SVVP supported version]? What does VMWare recommend? According to their KB article https://kb.vmware.com/selfservice/viewContent.do?language=en_US&externalId=1318, they say to turn of Windows Time service and use their host-to-guess time sync, except for the PDC Emulator of course, but then they want you to leave that on with “NoSync” turned on.

So: what is one to do?

First, I’d suggest a compromise – one that may avoid some of the issues. Don’t virtualize all your DCs. In fact, this is outlined in the Microsoft article above. You should really keep at least one hardware-based copy of your domain, and it should be the PDC emulator of the root domain of the forest. Preferably, in multi-domain forests, you’d want to keep a physical server for the PDC emulator of each child domain as well. This doesn’t have to be a very large machine, unless you’re a very large organization.

Now, if you virtualize all other DCs on Hyper-V (which I’d recommend not just because it’s Microsoft’s solution and I’m an employee, but because I’ve used both and Hyper-V is SO much easier to manage and configure), then the answer is clear: for DCs, leave the Windows Time service running on the guest DCs, with the root PDC Emulator’s time service configured to point to a highly-accurate external clock and disable Time Synchronization in the Integration settings. The Hyper-V hosts should then be joined to the domain. This will keep all hosts and guests synched to the proper time.

For guest running on VMWare, this is a tough decision since there are competing recommendations. Anecdotally, I have heard of no particular issues with disabling time sync in the VMWare tools and leaving Windows Time to synch the DC time clocks, but I have heard of issues the other way around: letting VMWare tools manage the time sync. In my opinion, such a custom solution as VMWare recommends should only be used if you’ve experience problems with the regular way of doing things. That’s why it’s the default: it generally works well when left that way. You should also configure the hosts to retrieve their time from the physical PDC Emulator in the root domain.

So, in summary, use a physical DC for at least one of your DCs per domain, and when you have to use VMWare, I’d recommend disabling the time sync from host to guest on domain controllers, and setting the hosts to obtain their time information from the root PDC Emulator. All other guests can be configured to obtain time from the host. But, as always, carefully monitor all your event logs for your servers and make sure you don’t have any issues.

Comments

• Anonymous
  January 01, 2003
  With Virtual PC, you cannot - it simply wasn't made for it. This article is mainly relelvant for only permanently hosted environments. If your lab setup is Virtual PC, it's likely not on most of the time like a Hyper-V lab is. In the scenario you describe, you will not be able to configure the underlying time sync capabilities of the virtual client, and it's probably not necessary to do so.

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  October 24, 2010
  I am running a very simple lab on Widows Virtual PC where my DC and member server are both W2008. Time Service is disabled on both VMs, but still the time gets synched somehow. What do I need to go to DISABLE time sync completely?

• Anonymous
  March 16, 2017
  Having a mixed enviro is a good idea all around. VMWare Servers acting as DC's should synch with the PDC or ROOT DC. Currently, we are experiencing the anomaly of time synch with a VMWare enviro which hosts both Windows and Linux servers. A little "chicken and egg" going on here though. VMWare is synching with Linux NTP boxes stratum 2 hosted within the VSphere which look to the Internet for accurate time.. Windows PDC\ROOT DC (Physical) is going out to pool for time stratum 3. All hosted DC's are pointed to the PDC. On occasion, not on reboot or resize or other known event from within VMWare, a time synch will take place. This is not an acceptable scenario. My preference would be for all DC's and member Windows servers get time from nearest DC at lowest cost. Linux can do whatever it pleases to keep things happy in that realm. I'm primarily concerned with Kerberos authentication being skewed because the DC's aren't getting time from amongst their own kind. What to do?