So, I’ve been away from blogging for a while. Work has kept me busy during the day and my little daughter, which came last year, did the same at night 🙂
But for this post I’d like to tackle the issue of virtualizing a domain controller.
In the past this could cause some rather unforeseen and dramatic consequences if one was not aware of how to do this properly. Most businesses I’ve visited over the years since virtualization began to ramp of have to a large degree virtualized all servers possible and what are better candidates than domain controllers which most of the time doesn’t use the ressources allocated.
Most of these have also adapted their backup solutions to meet these new scenarios where one of the most seen solutions is based on some form of virtual machine snapshotting.
Well, that works okay for a file server, print server or other applications that are crash-consistent. But what happens if you restore a domain controller from a snapshot?
Let’s take some background information on how domain controllers work at first. They, as we all know, run Active Directory and each one of them holds a copy of the Active Directory database. This database is assigned a value known as an InvocationID and each update (that does not require the involvement of a FSMO role master) is done against the local Active Directory database, which is then synced with its replication partners. This is done using Update Sequence Numbers (USN). These two numbers form a unique identifier on the local database and are used to determine whether updates need to be processed.
Now, take the scenario from before where a domain controller is restored from a snapshot. What happens then?
Well, the domain controller that comes up from a restored state doesn’t know this so it will attempt to sync with its partners. But then comes the problems as the USN it tries to use are already acknowledged by the other domain controllers as used and therefor no sync will happen.
And as stated above, as changes happens towards the local Active Directory database then over the course of time they will become more and more out of sync. An example (in the light end is a user changing his/her password on the restored domain controller, which doesn’t sync to the others. You then have one password on some systems and another on others, depending on which DC they validate against).
This is really not a desired scenario, but thankfully Microsoft has done something about this…
In Windows Server 2012 Microsoft made the domain controller virtualization aware (on supported hypervisors that is). This means that the domain controller now knows it is virtual and can take steps to prevent the above described scenario.
So how is this done…
Well, Microsoft introduced a new attribute to Active Directory, more specifically the VmGenerationID which is a number stored on the domain controller object in Active Directory.
This attribute is then monitored by the Windows operating system to ensure it matches the number the server has stored locally. If this is not the case, then the domain controller assumes it has been restored and take actions the prevent the above scenario.
What happens in this case is that the domain controller resets its InvocationID and discards the issued RID pool effectively preventing the re-use of USN. It then marks its local SYSVOL share for a non-authoritive restore.
This picture shows how the proces is done:
The requirements for using this cool new feature is the following:
- Supported hypervisor platform (Hyper-V 2012 or newer, vSphere 5.02, ESX 5.1)
- Windows Server 2012 domain controller
- PDC emulator running Windows Server 2012