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

S’applique à : Microsoft Windows Server 2003 Service Pack 2Windows Server 2008 StandardWindows Server 2008 Enterprise


A virtual hosting environment lets you run multiple guest operating systems on a single host computer at the same time. Host software virtualizes resources that include 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 test, for development, and in production roles. However, certain restrictions apply to the deployment of Active Directory domain controllers that run in a virtual hosting environment. These restrictions do not apply to a domain controller that runs on a physical computer. 

This article discusses the things to consider when a Microsoft Windows 2000 Server-based domain controller, a Windows Server 2003-based domain controller, or a Windows Server 2008-based controller runs in a virtual hosting environment. Virtual hosting environments include the following:  
  • Windows Server 2008 Virtualization with Hyper-V
  • VMware family of virtualization products
  • Novell family of virtualization products

More Information

There is an updated document on virtualized Domain Controllers that reflects the current status of system robustness and security more closely than this article:

Many of the considerations in TechNet also apply to 3rd party virtualization hosts. This article is still in place to help with additional hints and considerations deemed not relevant enough for TechNet.

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

When you deploy an Active Directory domain controller on a physical computer, certain requirements must be satisfied throughout the domain controller's life cycle. The deployment of a domain controller in a virtual hosting environment adds certain requirements and considerations. These include the following:  
  • To help preserve the integrity of the Active Directory database if a power loss or another failure were to occur, the Active Directory service performs un-buffered writes and tries to disable the disk write cache on volumes hosting the Active Directory database and log files. Active Directory also attempts to work in this manner when installed in a virtual hosting environment.

    If the virtual hosting environment software correctly supports a SCSI emulation mode that supports forced unit access (FUA), un-buffered writes that Active Directory performs in this environment are passed to the host operating system. If forced unit access is not supported, you must disable the write cache on all volumes of the guest operating system that host the Active Directory database, the logs, and the checkpoint file. 

    • You must disable the write cache for all components that use Extensible Storage Engine (ESE) as their database format. These components include Active Directory, the File Replication Service (FRS), Windows Internet Name Service (WINS), and Dynamic Host Configuration Protocol (DHCP). 
    • As a best practice, consider installing uninterruptable power supplies on VM hosts.

  • An Active Directory domain controller is intended to run Active Directory mode continuously as soon as it is installed. When the domain controller is started, end-to-end replication of Active Directory must occur. Make sure that all the domain controllers perform inbound replication on all locally held Active Directory partitions according to the schedule defined on site links and connection objects, especially in the number of days that is specified by the tombstone lifetime attribute.

    If inbound replication does not occur, the following Error event may be logged in the Directory Service log:
    When this replication does not occur, you may experience an inconsistency in the contents of Active Directory databases on domain controllers in the forest. This inconsistency occurs because knowledge of deletes is persisted for tombstone lifetime number of days. Domain controllers that do not transitively inbound replicate Active Directory change in a rolling tombstone lifetime number of days cause lingering objects. Lingering objects are objects intentionally deleted by an administrator, service or operating system that incorrectly exists on destination DCs that did not perform timely replication. The cleanup of lingering objects can be very time-consuming, especially in multi-domain forests that include many domain controllers.
  • When a domain controller runs in a virtual hosting environment, do not pause the domain controller for long periods of time before you resume the operating system image. If you do pause the domain controller for a long time, replication may stop and cause lingering objects. The following Error event may be logged in the Directory Service log:
  • An Active Directory domain controller requires regular system state backups to recover from user, hardware, software, or environmental problems. 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 at play during the installation. This useful life is controlled by the tombstone lifetime attribute in Active Directory. At least one domain controller in every domain in the forest should be backed up every tombstone lifetime number of days.

    In a production environment, you should make system state backups from two different DCs on a daily basis.
  • Virtualized DCs in clustered hosts 
    In order for the nodes, disks and other resources on a clustered computer to auto-start, authentication requests from the clustered computer must be serviced by a DC in the cluster computer's domain. 

    To insure that such a DC exists during cluster OS startup, deploy at least 2 domain controllers in the clustered host computer's domain on physical hardware. The physical DCs should be kept online and be network accessible (in DNS + all required ports and protocols) to the clustered hosts. If the only DC’s that can service authentication request during cluster startup reside on a cluster computer that is being restarted, authentication requests will fail and manual recovery steps will be required to make the cluster operational. 

    Virtualized DCs may be placed on Cluster Shared Volumes (CSV) and non-CSV volumes. CSV disks cannot be brought online unless authentication request have been serviced by Active Directory. Non-CSV disks can be brought online without authentication. Because non-CSV disks can be brought online more easily, Microsoft recommends that files for virtualized domain controllers be placed on non-CSV disks.

    Note: Always have at least one DC that is on physical hardware so that failover clusters and other infrastructure can start. When you host domain controllers on virtual machines that are managed by Windows Server 2008 R2 or by Hyper-V Server 2008 R2, we recommend that you store the virtual machine files on cluster disks that are not configured as Cluster Shared Volumes (CSV) disks. This allows for easier recovery in specific failure situations. If there is a site failure or a problem that causes the whole cluster to crash and the DC on physical hardware is not available, storing the virtual machine files on a non-CSV cluster disk should enable the cluster to start. In this situation, the disks that are required by the virtual machine can be brought online. This will let you start the virtual machine that hosts the domain controller. Then, you can bring CSV disks online and start other nodes. This process is required only if there are no other domain controllers available at the time that the cluster is started.

Support for Active Directory domain controllers in virtual hosting environments

For more information about the supportability of hosting domain controllers in Microsoft and third-party virtual hosting environments, click the following article number to view the article in the Microsoft Knowledge Base:

897615 Support policy for Microsoft software running in non-Microsoft hardware virtualization software