Over the past couple of years, I’ve seen many organization starting to virtualize their domain controllers. It’s interesting, I remember when vSphere was still a fresh product and many companies still preferred to keep some servers physical, Active Directory being one of them. Now, however, things have changed, Business Critical Applications are being virtualized with full support from the vendors. So, in most environments, the majority of the servers are virtualized. But what does virtualizing these servers have to offer? well we all know the advantages of virtualization, but Domain Controllers are not just any servers, the architecture and the back-end infrastructure is a complex beast. Because of that, up until Windows Server 2012, Domain Controllers could not be cloned or used to take snapshots. This prevented these applications from taking full advantage of what virtualization had to offer and relied on old fashioned methods of backups, restores, and provisioning.
So why can we not snapshot or clone a domain controller? the simple answer, USN rollback. With the release of Windows Server 2012, Microsoft has lifted these limitations to allow for a much deeper integration with the virtualization layer. Now, let’s get a little bit more technical.
In order to understand what’s been introduced in Server 2012, we need to understand a bit about how Active Directory replication works. Active Directory is a centralized system used to manage access to resources. Each domain controller contains a database that can easily contain thousands of objects (Computers, Users, Groups, OUs, etc). When updates occur such as adding a new computer to the domain or making changes to Active Directory attributes, these changes need to be synchronized with the rest of the domain controllers through a replication process. So how does one domain controller know when to replicate these changes? Well, when a change actually occurs, the source domain controller will notify it’s partners (destination domain controllers) of the change. The destination domain controllers will then prompt the source domain controller for the changes, at which point the source domain controller will either place the request in the queue for later processing or permit the replication to occur. Only one replication can occur at a time and the remaining requests will be put on hold until each and every one of them is processed.
Below is a diagram taken from the Microsoft site to demonstrate the replication process
Now we need to understand the impact of applying old snapshots to domain controllers. When the old snapshot is applied, the domain controller is put back to the same state it was when the snapshot was first taken. You might think that this is good, exactly what we wanted, but actually it’s not good at all, simply because of the way domain controllers function. Putting back the domain controller to it’s previous state causes the replication to fail due to the database version being older than that of its replication partners. This will cause all kinds of nightmares with replication and access issues.
So now that we understand how domain controller replication functions and what would happen if we were to revert to a snapshot, let’s take a look at what VM-Generation ID support has to offer.
With Windows Server 2012, a new attribute was introduced, VM-Generation ID (msDS-GenerationId) that is only set on application such as Active Directory.
The same VM-Generation ID is set on the virtual machine itself. When a snapshot is reverted, the first thing that happens when the virtual machine is booted up, it compares the VM-Generation ID of the Active Directory computer object to the virtual machine’s ID. If it detects a change, then both the RID pool and USN are rejected to protect the integrity of Active Directory.
The following versions of vSphere are supported:
- VMware vSphere 5.0 Update 2 (vCenter + ESXi)
- VMware vSphere 5.1
- VMware vSphere 5.5
Also, it is important to note that the VMware Tools should always be up to date..