Active Directory already provides a complete hierarchy for time synchronisation. The forest root PDC Emulator obtains time from an approved external source, while the remaining domain controllers and domain members follow the domain hierarchy.

Virtualisation should not replace that design. The objective is to retain one authoritative Windows time path while ensuring that the hypervisor hosts themselves are also correctly synchronised.

The forest root PDC Emulator

The PDC Emulator in the forest root domain sits at the top of the Active Directory time hierarchy. It should use several approved external NTP peers or a suitable internal source.

It should not use the virtualisation host as its regular time source. Doing so makes the entire forest dependent on the host configuration and places the hypervisor inside the Windows time hierarchy.

Verify the selected source with:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

The source should be one of the approved peers rather than the host integration provider, the local clock or another domain controller.

Other domain controllers

All other domain controllers should normally use NT5DS and obtain time through the Active Directory hierarchy.

They do not need their own external peer lists and should not be pointed directly at the PDC Emulator by hostname. Windows should be allowed to discover a suitable domain source and follow the hierarchy naturally.

On a correctly configured domain controller, the following command should normally report another domain controller:

w32tm /query /source

Hypervisor time synchronisation

Hyper-V, VMware, Proxmox VE and XCP-ng all have mechanisms that can influence a guest clock, but they do not expose identical controls.

Some distinguish between ongoing synchronisation and one-off correction during startup, resume, migration or snapshot restoration. Others rely on guest-agent operations rather than a continuously running time service.

The preferred design is:

  • Windows Time Service remains the normal source inside every domain controller.
  • The forest root PDC Emulator uses its approved external source.
  • Other domain controllers use the Active Directory hierarchy.
  • Hypervisor correction is limited to exceptional lifecycle events where appropriate for the platform.

The platform-specific articles explain the relevant controls:

The hosts still need accurate time

Disabling ongoing host-to-guest synchronisation does not make host time irrelevant.

A virtual machine may inherit the host clock when it starts. Resume, migration and recovery operations may also use the host as part of a one-off correction. A badly incorrect host can therefore affect a domain controller before Windows Time Service has an opportunity to restore the intended source.

Every host that may run a domain controller should use the same deliberate time design. This is especially important in clusters where a VM can migrate between nodes.

Snapshots and checkpoints

Restoring a snapshot or checkpoint of a domain controller is not simply a time operation. It can also affect Active Directory replication state, update sequence numbers, invocation IDs and other safeguards.

Where a supported restore is performed, the guest clock may still return to an earlier point in time. Verify Windows Time Service immediately after the domain controller resumes.

w32tm /query /source
w32tm /query /status
w32tm /resync /rediscover

VM-Generation ID

VM-Generation ID allows a supported hypervisor to notify Windows that a virtual machine has been restored, cloned or otherwise returned to an earlier state.

Active Directory uses this information to protect against problems that affected older virtualised domain controllers, including update sequence number rollback.

VM-Generation ID does not make every snapshot operation harmless, and it does not remove the need to verify time after a restore. It is an Active Directory safeguard, not a replacement for a recovery plan.

Cloning domain controllers

Modern Windows Server versions support a specific virtual domain controller cloning process on supported hypervisors.

Copying a domain controller VM outside that supported process is not equivalent to cloning a normal member server. The resulting VM may contain duplicated identity, replication state and configuration.

Time configuration should be reviewed as part of any supported clone operation, particularly if the source VM holds or later receives the PDC Emulator role.

Role transfers

If the forest root PDC Emulator role moves to another virtual domain controller, the external time configuration must move with it.

The new role holder should be configured with the approved external peers. The previous role holder should be returned to domain hierarchy synchronisation:

w32tm /config /syncfromflags:domhier /reliable:no /update
w32tm /resync /rediscover

Do not assume that transferring the FSMO role also transfers the Windows Time configuration.

Large time differences

A virtual domain controller that resumes with a large time difference may be unable to authenticate normally or contact a suitable source immediately.

Before manually setting the clock, establish why the difference occurred. Check the host time, the selected Windows source, the event logs and whether the VM has just resumed, migrated or been restored.

Correct the underlying source rather than turning manual clock adjustment into part of the normal operating procedure.

Verifying the hierarchy

Verification should start at the top:

  1. Identify the forest root PDC Emulator.
  2. Confirm that it uses the approved external source.
  3. Confirm that other domain controllers use domain-based sources.
  4. Check representative member servers and workstations.
  5. Confirm that every hypervisor host uses a reliable time source.

Useful commands include:

netdom query fsmo
w32tm /query /source
w32tm /query /status
w32tm /query /configuration
w32tm /monitor

w32tm /monitor provides a useful view of domain controller time differences, but it does not replace checking the source and configuration on the forest root PDC Emulator.

Common mistakes

  • Allowing the forest root PDC Emulator to use the hypervisor as its regular source.
  • Configuring every virtual domain controller with external NTP peers.
  • Leaving ongoing host synchronisation enabled without understanding its interaction with Windows Time Service.
  • Ignoring host time because the guest clock currently appears correct.
  • Restoring snapshots without checking Active Directory and time afterwards.
  • Assuming VM-Generation ID makes every rollback safe.
  • Transferring the PDC Emulator role without moving the external time configuration.
  • Checking only the displayed clock rather than the selected source.

Microsoft and vendor documentation

Related information