Things to consider when you host Active Directory domain controllers in virtual hosting environments

Applies to: Windows Server 2019Windows Server 2016Windows Server 2012 R2


A virtual hosting environment lets you run multiple guest operating systems on a single host computer at the same time. Host software virtualizes resources such as the following:

  • CPU
  • Memory
  • Disk
  • Network
  • Local devices

By virtualizing these resources on a physical computer, host software lets you use fewer computers to deploy operating systems for testing and development, and in production roles. However, certain restrictions apply to an Active Directory domain controller (DC) that runs in a virtual hosting environment. These restrictions do not apply to a DC that runs on a physical computer.

This article discusses the things to consider when a Microsoft Windows Server-based DC runs in a virtual hosting environment. Virtual hosting environments include the following:

  • Windows Server Virtualization with Hyper-V
  • VMware family of virtualization products
  • Novell family of virtualization products
  • Citrix family of virtualization products
  • Any product on the hypervisor list in the Server Virtualization Validation Program (SVVP)

More information

For updated information about the current status of system robustness and security for virtualized DCs, see Virtualizing Domain Controllers using Hyper-V. The Virtualizing Domain Controllers article provides general recommendations that apply to all configurations. Many of the considerations that are described in that article also apply to third-party virtualization hosts. It might include recommendations and settings that are specific to the hypervisor that you are using. Topics include the following:

  • How to configure time synchronization for DCs
  • How to manage disk volumes for data integrity
  • How to take advantage of Generation ID support in restoration or migration scenarios
  • How to manage allocation and performance of RAM and processor cores on the virtual machine host

This article supplements the Virtualizing Domain Controllers article by providing additional hints and considerations that were not in scope for the Virtualizing Domain Controllers article.

Things to consider when you host DC roles in a virtual hosting environment

When you deploy an Active Directory DC on a physical computer, certain requirements must be satisfied throughout the DC's lifecycle. The deployment of a DC in a virtual hosting environment adds certain requirements and considerations. These include the following:

  • The Active Directory service helps preserve the integrity of the Active Directory database if a power loss or other failure occurs. To do this, the service runs unbuffered writes, and tries to disable the disk write cache on the volumes that host the Active Directory database and log files. Active Directory also tries to work in this manner if it is installed in a virtual hosting environment.

    If the virtual hosting environment software correctly supports a SCSI-emulation mode that supports forced unit access (FUA), unbuffered writes that Active Directory performs in this environment are passed to the host operating system. If FUA is not supported, you must manually disable the write cache on all volumes of the guest operating system that host the Active Directory database, the logs, and the checkpoint file.
  • An Active Directory DC is intended to run Active Directory mode continuously as soon as it is installed. Do not stop or pause the virtual machine for an extended time. When the DC starts, end-to-end replication of Active Directory must occur. Make sure that all the DCs do inbound replication on all locally held Active Directory partitions according to the schedule that is defined on site links and connection objects. This is especially true for the number of days that is specified by the tombstone lifetime attribute.

    If this replication does not occur, you might experience an inconsistency in the contents of Active Directory databases on DCs in the forest. This inconsistency occurs because knowledge of deletes persists for the number of days that is defined by the tombstone lifetime. DCs that do not transitively complete inbound replication of Active Directory changes within this number of days cause objects to linger in Active Directory. Cleaning up lingering objects can be very time-consuming, especially in multi-domain forests that include many DCs.
  • To recover from user, hardware, software, or environmental problems, an Active Directory DC requires regular system state backups. The default useful life of a system state backup is 60 or 180 days, depending on the operating system version and the service pack revision that is in effect during the installation. This useful life is controlled by the tombstone lifetime attribute in Active Directory. At least one DC in every domain in the forest should be backed up on a regular cycle per the number of days that is specified in the tombstone lifetime.

    In a production environment, you should make system state backups from two different DCs on a daily basis.

Things to consider when you host DC roles on clustered hosts or when you use Active Directory as a back end in a virtual hosting environment

  • When your DCs run on clustered host servers, you would expect that they are fault tolerant. This same expectation applies to virtual server deployments that are not from Microsoft. However, there is one problem in this assumption: In order for the nodes, disks and other resources on a clustered host computer to auto-start, authentication requests from the clustered host computer must be serviced by a DC in the clustered host computer's domain. Alternatively, part of the configuration of the clustered host must be stored in Active Directory.

    To make sure that such DCs can be accessed during cluster system startup, deploy at least two DCs in the clustered host computer's domain on an independent hosting solution that is outside this cluster deployment. You can use physical hardware or another virtual hosting solution that does not have an Active Directory dependency. For more information about this scenario, see “Avoid creating single points of failure” in "Virtualizing Domain Controllers using Hyper-V."
  • These DCs on separate platforms should be kept online and be network-accessible (in DNS and in all required ports and protocols) to the clustered hosts. In some cases, the only DCs that can service authentication requests during cluster startup reside on a clustered host computer that is being restarted. In this situation, authentication requests fail, and you will have to manually recover the cluster.

Support for Active Directory DCs in virtual hosting environments

For more information about the supportability of hosting DCs in Microsoft and third-party virtual hosting environments, see the following Knowledge Base article:

897615 Support policy for Microsoft software that runs on non-Microsoft hardware virtualization software