Read more on "Server Virtualization Spotlight" »

Virtualizing Active Directory Domain Controllers - Page 2 Page 2

Never Use the Export Feature of a Virtualization Product

The Export feature puts the domain controller into a saved state before the export process can export the associated files. The virtual machine is then resumed to provide the services.

For obvious reasons, it is strongly recommended not to pause the services of a domain controller unless absolutely necessary. Pausing these services may result in downtime for network applications that use Active Directory as their authentication provider.

Disable or Configure Automatic Start Action

A virtual machine can be configured to start automatically in the case of any failure with the virtualization host. This feature is provided by both Microsoft Hyper-V and VMware.

An Automatic Start action feature avoids the manual interventions but is not a good option/feature for Active Directory domain controllers. All virtual domain controllers must not be configured to restart automatically in case the virtualization host goes down.

Implementing this option will result in a delay in booting domain controllers. For example, a child domain controller should never start before the root domain controller is up and running. As a result, it is recommended to disable this option or set a delay for the initial startup for virtual machine domain controllers that are part of a child domain.

Disable Failback Policies for Virtual Domain Controllers

Active Directory is a multi-master replication technology. All domain controllers keep consistent copies of the Active Directory database with the help of Active Directory Replication technology. By default, Active Directory domain controllers ship with fault-tolerance and load-balancing mechanisms to provide the authentication and authorization services.

So if virtual domain controllers are running in a clustered environment, it is a best practice to disable all the failback policies to block the automated movement of virtual domain controllers across the cluster.

Keep at Least One DNS and Domain Controller Running on a Physical Box

There are several reasons to consider this a best practice item:

  1. Active Directory and DNS are closely integrated components. DNS is required for resolving names for network applications running in the production environment. DNS can be hosted on a server with or without Active Directory services installed. If DNS service is hosted on a domain controller then the recommendation is to have at least one DNS Server running in the physical environment to avoid any disruption in the name resolution services for network applications running outside the Virtualization infrastructure.

  2. Keep in mind that Microsoft Failover Clustering services require the use of a centralized Active Directory Domain controller for authentication purpose. If you virtualize all domain controllers, the failover cluster might not work or provide the failover services. Hence, it is recommended to have at least one Domain controller running in the physical environment so that failover cluster can work as expected.

  3. Virtualization Host also requires the use of DNS Server service. It is recommended to configure DNS settings on Virtualization Host to use an external DNS server so name resolution can occur in case all the Virtual Domain Controllers are offline.

Host Virtual Domain Controllers on Multiple Hosts

It is important to understand that a Virtualization Host, on which the Virtual Domain Controllers run, can also suffer from hardware or software failures. The loss of Virtualization Host should not result in the loss of all Virtual Active Directory domain controllers.

The best practice is to spread out Virtual Domain Controller installation on multiple Virtualization Hosts, if possible, to avoid any interruption in the service.


In this article we learned about the general best practice items for an Active Directory domain controller running on a virtualization platform. We also learned what we should do and not do on a Virtual Domain Controller.

Nirmal Sharma
is a MCSEx3, MCITP and Microsoft MVP in Directory Services. He has specialized in Microsoft Technologies since 1994 and has followed the progression of Microsoft Operating System and software. In his spare time, he likes to help others and share some of his knowledge by writing tips and articles on various sites and contributing to Solution IDs for www.Dynamic-SpotAction.com. Nirmal can be reached at nirmal_sharma@mvps.org.

Follow ServerWatch on Twitter and on Facebook

This article was originally published on February 27, 2013
Page 2 of 2

Read more on "Server Virtualization Spotlight" »
Thanks for your registration, follow us on our social networks to keep up-to-date