Things to Consider When You host Active Directory Domain Controllers in Virtual Environments
We all know that it is fairly easy to host servers in virtual environments these days. In fact, it is so easy that people can often overlook the implications of hosting Active Directory Domain Controllers (DCs) in a virtual environment. Because Active Directory doesn’t support any method that restores snapshots of the operating system due to the fact that it can cause an Update Sequence Number (USN) rollback, one can argue that Domain Controllers are not really supported in a virtual environment.
Although I wouldn’t go as far as stating that DCs are not supported in a virtualized environment but clearly snapshots are not supported for virtualized DCs because of the way Active Directory was designed. If you decide to run DCs in a virtualized environment, here are some solutions that are documented in Microsoft’s KB article 888794. This is only a partial list. For the complete listing check out the KB article.
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.
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.
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.
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.
In an effort to boot with the latest zone contents, the Microsoft DNS Server service waits 15 or more minutes for Active Directory to inbound replicate before loading an AD-integrated DNS zone. Configuring DC guests to point to themselves as primary for name resolution causes domain controllers to hang while applying network connections during OS startup. Virtualized domain controllers should point to one or two reliable off-box DNS Servers to insure faster OS startup. Similarly, virtual host computers should point to one or two off-box DNS Servers for name resolution. Virtual host computers should not point to virtualized DNS Server running on the local virtual host computer.
To roll back the contents of Active Directory to a previous point in time, restore a valid system state backup. A system state backup can be restored up to the tombstone lifetime number of days after the backup was performed. The backup must have also been made on the same operating system installation as the operating system that you are restoring. Active Directory does not support other methods to roll back the contents of Active Directory. In particular, Active Directory does not support any method that restores a “snapshot” of the operating system or the disk volume the operating system resides on. This kind of method causes a rollback in the update sequence number (USN) used to track changes in Active Directory. When a USN rollback occurs, the contents of the Active Directory databases on the improperly restored domain controller and its replication partners may be permanently inconsistent.
If you are running servers, or plan to run servers, in a virtual environment it is good for you to know the support policy documented by Microsoft in the KB article 897615: Support policy for Microsoft software running in non-Microsoft hardware virtualization software.
Copyright ©2011 Zubair Alexander. All rights reserved.