In May 2009, I worked with Infinite Group Inc. and conducted a virtualization assessment for all state community colleges in the State of Mississippi. In particular, I was asked to create a set of best practices as guidance to use for virtualizing Active Directory.
Since most Windows based network services rely on Microsoft Active Directory, virtualizing this role requires careful consideration. In particular, the following elements must be carefully planned:
- Time Synchronization
- Fault Tolerance
- High Availability
- FSMO Role Positioning
Time Synchronization
All Active Directory services are dependent on the time in some way. For services such as authentication and eventing, and licensing, the relationship is obvious. For other services such as updating, the relationship may not be so obvious.
In virtualizing servers, most if not all elements are virtualized and not physical. This includes the processor. The way that the time is maintained is in accordance with processor ticks. Most physical clocks or time keeping devices are imprecise to some degree. It is very difficult to maintain precise and accurate time without there being some degree of a time skew which requires periodic adjustments to correct for accuracy in time keeping.
In the case of virtualization, virtual machines require a mechanism to adjust or translate the virtual processor ticks and synchronize them with some time source. This skew is more apparent in virtual machines than in their physical counterparts and therefore these adjustments occur more often.
Time Synchronization is one reason that it is not recommended to have Active Directory services deployed in an entirely virtualized environment.
Fault Tolerance
In any Active Directory deployment, more than one server with the Active Directory Domain Services role deployed is recommended for fault tolerance. In fact, at least 2 Domain Controllers are recommended as a best practice for every Domain deployed in an Active Directory forest. The reason for this is to ensure that more than 1 server exists at any given time with a copy of the Active Directory database.
Since Active Directory technology is designed such that every domain controller installed is as authoritative as their neighbors. This phenomenon is called multi-master. The term multi-master itself is normally used when referring to Active Directory replication which is the process of copying changes within the Active Directory database from one domain controller to another.
In the case of virtualization, typically one domain controller in every domain should be configured as a physical server to ensure fault tolerance in the event of a failure.
High Availability
Virtualizing of Active Directory does have the distinct advantage of indirectly enabling an Active Directory domain controller to be configured as highly available.
If only physical servers would be used, there is no practical way to make an Active Directory domain controller highly available. To achieve this functionality, the Active Directory database and log files would require careful placement within highly available file share resources which vastly increase the complexity of an environment.
Active Directory domain controllers which have been installed on a virtual server may be installed on a cluster with the virtual machine itself being the highly available workload. This effectively allows Active Directory domain controllers to become highly available quite easily.
FSMO Role Positioning
At a basic level, Active Directory domain services make use of a multi-master model. There are however several Active Directory functions or roles which must be tied to a particular server and cannot be shared amongst all domain controllers. These are referred to as flexible single master operations (FSMO) roles.
In addition to the database and log files, Active Directory requires that these roles be in service and available for communication. If some of these roles are configured on a virtual server, it is recommended that the server not contain any critical workloads other than Active Directory domain services.
The reason for this is because if the virtual server were to fail and not be quickly recoverable, the FSMO roles contained on it would need to be seized by some other Active Directory domain controller server. This process is not clean and if the failed server were to ever be recovered, there would be meta data remaining that pertains to Active Directory which is no longer valid. The recommended course of action to re-establish the server into service would be to reinstall the operating system, rejoin the domain, and then add the Active Directory domain services role and allow it to replicate with other Active Directory domain controller partners. Only once this is done, should any FSMO roles be transferred back to the server.
In the case of a virtual machine, the process of rebuilding or provisioning a new server can be only a few minutes which is a significant improvement over the time needed to bring a physical server back into service.
The recommended course of action for the failed virtual server would be to decommission it as this is no longer useful to rejoin the domain and the repercussions of deleting a file are significantly less than maintaining an expensive physical server asset while not in use.
