We have all at some time or another virtualized a domain controller, either for test or production. Most likely sometime during that time your reverted the system back from a snapshot and wondered why did the system stop replicating process. In other words why did your DC stop acting like a DC. You probably had to go through extensive steps to fix it. Well if you wanted to successfully virtualize your DC’s then this article is for you! Inside Windows Server 2012 Active Directory services (AD DS) there is an amazing safeguarding technology in the form of VM-GenerationID that will allow you to safely snapshot and restore your virtual DC’s. To understand the importance of this feature lets take a quick look at the past and how replication works.
In previous versions of AD (Windows Server 2008, 2008 R2), you could virtualize your DC’s but there was a lot of perspective guidance on how to properly virtualize your DC. You can find the guidance here: Running Domain Controllers in Hyper-V The article really boils down to not really recommended to virtualize your DC’s. Based on your infrastructure you may not have any choice and that is why have the prescriptive guidance in the article. To allow you to do this successfully. If you have not seen the article, here are some of the highlights of what not to do with a virtual DC:
Okay that last rule only applies to the classic 1984 movie, but if you did break any of the rules when virtualizing your domain controllers you did get a nasty gremlin, event ID 2095. Event ID 2095 usually indicates a USN rollback for the DC. Before we talk about the nasty consequences of a USN rollback. Let’s take a brief look at how DC’s replicate with one and another.
In AD there are two ID’s to help track and keep your directory healthy. One ID tracks changes in the domain database, Update Sequence Number or USN, and the other tracks the instance of the database on each DC, the invocationID. When you modify the directory database the invocationID of the DC and it’s USN are combined into a unique identifier associated with the write-transaction performed and this must be unique within the forest. So every time you modify AD, these numbers are happily maintained and increased sequentially to maintain uniqueness. The problem comes into play when a DC tries to reuse a USN, which can occur very easily when you use a virtual machine snapshot. When you use a snapshot you essentially take your DC back in time, and in terms of the USN the DC thinks it USN number is lower than what reality says it actually is probably dramatically different. When that DC tries to replicate the first time you will result in conflict, because that DC has roll backed it’s USN id, hence the term USN rollback Here is a graphic on how that looks:
Now, I know your thinking, you may have used backup and restore technologies in the past, and with those technologies that is where the invocationID comes into play. When you properly restore a AD database the invocationID will get reset, and even though the USN number be an older number, combined with the new invocationID it will create a unique identifier. This will allow the DC to resume replication and happily move a long. Now this is a very brief look and there is more to the story, if you want to learn more about USN’s take a look here: USN and USN Rollback.
So in a nutshell USN rollback means the DC being restored(or brought from a snapshot) is in conflict with the other DC’s. Which is a bad thing for that DC. When the first DC that detects this problem it will take measures to protect the domain and take the following actions on the restored DC:
So you can avoid a USN rollback, but there is a clear set of guidelines to follow when you virtualized your DC’s as mentioned in this article: Running Domain Controllers in Hyper-V. Which brings us to……..
Windows Server 2012 AD DS introduces a new attribute, the VM-GenerationID which is used to help us with USN rollback. During the installation of a domain controller the VM-GenerationID is generated and stored in the directory information tree (DIT),located here: %SystemRoot%\ntds\NTDS.DIT. The VM-GenerationID design uses a hypervisor-vendor independent mechanism to expose this identifier in the address space of the guest virtual machine, so the safe virtualization experience is consistently available of any hypervisor that supports VM-GenerationID. Did you see that important part “any hypervisor”, do you mean this is available for other hypervisors, like VMware and Citrix? Yes, we have shared the information with them, but let me be very clear today Hyper-V is the only hypervisor that supports it now, the other hypervisors have not implemented it yet! So download Hyper-V today! The VM GenerationID is tracked by a Windows driver inside the virtual machine, which can be used by services and applications that may be inside the virtual system. The main purpose is to detect if the virtual machine has been rolled back.
When the system is restored to a previous snapshot the VM-GenerationID in the virtual machine driver is compared to the value in the DIT. If the values are different the invocationID is reset, the RID pool is discarded this prevents USN reuse, and updates the DIT with the new value. This helps prevents a USN rollback. If the values are the same, the systems will continue to replicate as usual. The VMGeneration-ID is checked EVERY time a write is performed to the AD database, and I mean every time to insure domain integrity. The graphic below shows how the replication now works to avoid USN rollback:
What is clever these same mechanisms are used to not only to safeguard your AD environment but can also be leveraged when you want to clone your DC’s. You may need to clone for disaster recovery scenarios, and the VM-GenerationID makes this process happen. There are several steps involved in the process to successfully clone a DC. The overall process looks will follow these high level procedures:
Prepare the environment
Prepare the source domain controller
Create the cloned domain controller
To learn more behind the details of virtual DC’s and deeper dive into cloning a DC take a look here: Virtualized Domain Controller Technical Reference
As you can see the VM-GenerationID allows use to really leverage to full power and features of our hypervisor technologies and provides support for scenarios customers like yourself have wanted for years. To learn more about the Virtualization safeguards and cloning of DC’s in Windows Server 2012 take a look at this article: Introduction to Active Directory Domain Services (AD DS) Virtualization
We hope you are enjoying the series and check out Windows Server 2012 by taking a look at these downloads:
If you missed any of the parts you can find the rest of the series here: 31 Days of Our Favorite Things in Windows Server 2012.