Virtualizing Active Directory Domain Controllers: General Best Practices

Wednesday Feb 27th 2013 by Nirmal Sharma
Share:

Before virtualizing mission-critical services like Active Directory domain controllers, make sure to brush up on what you should and should not do with our "best practices" reference.

Both VMware and Microsoft have been providing virtualization services for a number of years. For VMware, it's been more than a decade now, while Microsoft entered into server virtualization relatively recently.

An IT environment consists of a number of physical IT components, including servers hosting Active Directory services. Active Directory domain controllers are the critical servers needed to run the IT operation smoothly. As part of the virtualization roadmap, an organization has to ensure that every physical IT resource is in the process of being virtualized to reduce the cost. This also includes virtualizing physical domain controllers.

The Active Directory domain controllers not only helps in smoothing IT operations, they are also a key component for providing authentication and authorization services. In today's production environment, almost all network applications now use Active Directory as the authentication provider. There are a number of things we must consider before these critical services are virtualized.

This is where a general "best practices" reference comes in handy, explaining the best practice items in terms of what you should do and what you should not when virtualizing Active Directory domain controllers on either VMware or Hyper-V:Server Tutorials

Disable Time Synchronization

Active Directory domain controller has a built-in mechanism to deal with the time synchronization with the help of the Windows Time Service. Virtualization platforms also provide time service for Virtual Machines (VMs), but it is recommended to disable the Time Synchronization on each Virtual domain controller and let Active Directory manage the time synchronization between Virtual domain controllers.

Do Not Take Snapshots

The Snapshot feature is designed for development and testing purpose. Snapshots are taken to revert back to the configuration that was taken as part of the snapshot process. Snapshot requires that a Virtual Machine is put into a saved state before the snapshot files are created.

  1. In the first place, putting a virtual domain controller into a saved state as part of snapshot process causes minimal downtime, which can have a significant impact if the differencing disk file grows too large.
  2. Secondly, we would never want to revert to a previous configuration for a virtual domain controller specifically. If you do so, this may result in inconsistent copies of the Active Directory database on that domain controller.

Note: Microsoft Hyper-V addresses downtime issues with snapshot by introducing a new Live Snapshot Merge feature in Windows Server 2012.

Disable Disk Caching on Domain Controllers

For the "Disable the Disk Write Caching on the Policies Tab of all Disk Drives in virtual domain controller" setting, it is recommended to configure this setting for all the services which use Extensible Engine Storage (ESE) technology to avoid any data loss.

Disabling Disk caching ensures that data is actually written to the disk instead of keeping the data in volatile memory, which may be lost during a power failure or if the Host server crashes.

Do Not Pause

Pausing a virtual domain controller is not recommended, especially if the virtual domain controller is paused for an extended period of time beyond the Active Directory tombstone timeframe. Pausing can cause the Virtual domain controllers to get out of sync and can introduce lingering objects in the Active Directory environment.

Lingering objects occur when deleted objects are not replicated to all Active Directory domain controllers within the period set for Active Directory tombstone timeframe, which is 80 or 160 days depending on the operating system in use.

Always Configure Fixed Hard or Pass-Through Disks for Virtual Domain Controllers

It is recommended to configure Fixed or Pass-through Disk type for storing domain controller's database (NTDS.DIT) and log files so that domain controllers operate more efficiently. Implementing one of the other types of disks (e.g. differencing disk virtual hard disks) will reduce the performance of virtual domain controllers.

Note: Pass-Through disk type is a feature of Microsoft Hyper-V and can be compared with a Raw disk as termed in the VMware Virtualization platform.

Do Not Clone The Domain Controller Virtual Machine

Most of the virtualization vendors provide the option for cloning the virtual machines for rapid deployment. It is highly recommended to avoid cloning a domain controller installation, though, unless you are using Windows Server 2012, which provides its own cloning feature.  Otherwise, if you need to do so, we would recommend using the SysPrep.exe tool, which prepares the operating system by removing the duplicate Security Identifiers (SID).

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.

Conclusion

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

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved