One of the hardest things to get right with virtual Domain Controllers is the time hierarchy in Active Directory. Recommended practices from Microsoft have been all over the place, but seem to have solidified in the last years, but the question remains:

How do I manage Active Directory Time Synchronization on VMware vSphere?

This is a valid question, and the answer for virtual Domain Controllers running on Microsoft Hyper-V is different to virtual Domain Controllers running on VMware vSphere…

Active Directory and time

Why the correct time is important to Domain Controllers

You might not think accurate time is important in Active Directory, and you would be right in most cases. However, there are a couple of cases where accurate time is important:

• Kerberos authentication, as heavily used in Active Directory, allows for five minutes time difference between an authenticating client (that could also be a domain-joined server) and the authenticating server (that is always a Domain Controller). Beyond the five minute time frame, authentication fails.
• Domain Controllers replicate the contents of the Active Directory database based on InvocationIDs, indicating replication partners, unique serial numbers per object (USNs) and the originating DN (Domain Controller) for writes to objects.
  Only when two writes in Active Directory cross replication, the time stamp is used to make the last write win.

That’s why Active Directory offers a time hierarchy.

About the Active Directory Time Hierarchy

In every Active Directory environment, time is synchronized in a hierarchy. This hierarchy is depicted in the below image, courtesy of the Time Synchronization in Active Directory Forests page in the Microsoft TechNet Wiki:

The Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role in the root domain represents the top of the hierarchy and is considered the authoritative time source. That’s why the Active Directory Best Practices Analyzer (BPA) reports an action when this Domain Controller does not synchronize its time with an external source, like a pool of NTP servers on the Internet or a couple of GPS-equipped internal appliances, or a combination of both.

The Domain Controller holding the PDCe FSMO role represents the top. This Domain Controller is contacted by the w32time service running on:

1. Domain Controllers holding the PDCe FSMO role for the other domains in the Active Directory forest (although these Domain Controllers can synchronize with any Domain Controller from the root domain)
2. The other Domain Controllers in the root domain

Domain-joined devices and member servers in the root domain, then, contact these other Domain Controllers to synchronize time with. (This reduces the load on the Domain Controller with the PDCe FSMO role.)

In the other domains in the Active Directory forest, other Domain Controllers in these domains synchronize their time with the Domain Controller holding the PDCe FSMO role in their domain. Domain-joined devices and member servers in the non-root domain can synchronize with any Domain Controller in their respective domain.

Challenges with time drift

The above hierarchy works almost flawless in environments with physical Domain Controllers, but represents a couple of challenges when working with virtualized Domain Controllers:

• When the hypervisor host is not synchronizing time with a reliable time source, it may provide the wrong time to a virtual Domain Controller. Domain Controllers synchronizes time with the tier above them only every 3600 seconds, so in extremis Domain Controllers may provide member servers and domain-joined devices wrong time for an hour, resulting in possible authentication failures.
• When the hypervisor host is not synchronizing time with a reliable time source, it may provide the wrong time to a virtual Domain Controller. In environments with high volumes of changes to objects in Active Directory, this might result in replicating changes from the Domain Controller as they are indicated as winning last writes, due to incorrect time stamps.
• When the time difference is greater than 48 hours, the w32time service on Windows Server 2008, and up, will not correct the time, because of the phase correction limits. Microsoft KnowledgeBase article 884776 explains how to change these limits through the MaxPosPhaseCorrection and MaxNegPhaseCorrection registry entries. (However, with incorrect time, there is no Kerberos, and thus no Group Policy…)

Microsoft recommended practices

Microsoft recommends to:

1. Synchronize the time of the Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role in the root domain with a reliable time source.
2. Use the default time synchronization hierarchy throughout Active Directory.

Specific to virtual Domain Controllers, Microsoft has held different points of view on time synchronization.

accurate time for Windows Server 2016

Microsoft introduced increased polling and clock update frequency in Windows Server 2016 Active Directory, when compared to Windows Server 2008/2012. While this introduces a small additional CPU load on Domain Controllers, it does provide for more Accurate Time for Windows Server 2016 because of more frequent polling, updating and through an algorithm that calculates time difference trends.

Time Synchronization on VMware vSphere

There are two models for time synchronization between virtual Domain Controllers and VMware vSphere hosts:

1. Disable time synchronization between virtual machines and the hypervisor to avoid a virtual Domain Controller to pick up bad time settings when the hypervisor is not synchronizing time properly.
2. Synchronize the time on hypervisor hosts to the same external time source as the Domain Controller with the PDCe FSMO role in the forest root domain.

There are some things you need to know:

Disable time synchronization with the hypervisor host

Many websites on the internet will instruct you to disable the Synchronize guest time with host option in the virtual machine’s properties to disable time synchronization with the hypervisor host, like in the below screenshot:

As VMware KnowledgeBase article 1189 points out, this does not completely disable time synchronization, because virtual Domain Controllers will synchronize their time when you,

• Suspend it, the next time you resume it
• Migrate the virtual Domain Controller using vMotion
• Take a snapshot
• Restore to a snapshot
• Shrink the virtual disk
• Restart the VMware Tools service
• Reboot the virtual Domain Controller

To effectively disable time synchronization, add the following lines to your virtual machine’s advanced configuration options:

tools.syncTime = "0"
time.synchronize.continue = "0"
time.synchronize.restore = "0"
time.synchronize.resume.disk = "0"
time.synchronize.shrink = "0"
time.synchronize.tools.startup = "0"
time.synchronize.tools.enable = "0"
time.synchronize.resume.host = "0"

To disable time synchronization across multiple VMs at once, use VMware vRealize Orchestrator.

Synchronize hypervisor time with a reliable source

Synchronizing the time on the hypervisor with a reliable source sounds like a piece of cake, but gets tedious to manage at large scale. When you’ve found your way to manage the configuration of all hypervisor hosts, it’s also noteworthy to:

• Disable VMware Distributed Resource Scheduler (DRS) for Domain Controllers holding the PDCe FSMO role
• Use Host-Guest Affinity Rule for Domain Controllers holding the PDCe FSMO role

Recommendations

Disable time synchronization with the hypervisor host on the virtual Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role in the root domain and synchronize its time with a combination of:

• DNS names of a reliable time source on the internet, like pool.ntp.org.
• IP addresses of a reliable time source on the internet, like 131.211.8.244 and 5.79.108.34. (This make sure time synchronization occurs even when DNS is unavailable and minimizes the effect of DNS poisoning attacks.)
• IP addresses of reliable time sources on the internal network, like GPS-based NTP appliances on the internal network. (This makes sure time synchronization occurs even when internet connectivity is unavailable).

For all other virtual Domain Controllers, virtual member servers and virtual domain-joined devices, make sure the hypervisor hosts they run on have accurate time. Then, the virtual machines will make the most of time synchronization from both the hypervisor and Active Directory. Especially when they run Windows Server 2016, or up.

Further reading

Time Synchronization in Active Directory Forests
Active Directory: Time Synchronization
Configuring the Windows Time Service in an Active Directory Forest – A step by step