31 Days of Our Favorite Things: Get the Gremlin Out of Your Active Directory Virtualization Infrastructure with Windows Server 2012 (Part 27 of 31)

  • Article

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.

Previous AD Versions

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:

  • Do not pause, stop, or store the saved state of a domain controller in a virtual machine for time periods longer than the tombstone lifetime of the forest and then resume from the paused or saved state. Doing this can interfere with replication.
  • Do not copy or clone virtual hard disks (VHDs).
  • Do not take or use a Snapshot of a virtual domain controller.
  • Do not use a differencing disk VHD on a virtual machine that is configured as a domain controller. This makes reverting to a previous version too easy, and it also decreases performance.
  • Do not use the Export feature on a virtual machine that is running a domain controller.
  • Do not restore a domain controller or attempt to roll back the contents of an Active Directory database by any means other than using a supported backup
  • Do not get them wet, do not give them food after midnight, and no bright light

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.

AD DS Replication Problem

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:

image

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:

  • AD DS pauses the Net Logon service, which prevents user accounts and computer accounts from changing account passwords. This action prevents the loss of such changes if they occur after an improper restore.
  • AD DS disables inbound and outbound Active Directory replication.
  • AD DS generates Event ID 2095 in the Directory Service event log to indicate the condition.

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……..

VM-GenerationID to the rescue!

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:

 

image

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

  • Step 1: Validate that the hypervisor supports VM-Generation ID and therefore, cloning
  • Step 2: Verify the PDC emulator role is hosted by a domain controller that runs Windows Server 2012.

Prepare the source domain controller

  • Step 3: Authorize the source domain controller for cloning
  • Step 4: Remove incompatible services or programs or add them to the CustomDCCloneAllowList.xml file.
  • Step 5: Create DCCloneConfig.xml
  • Step 6: Take the source domain controller offline

Create the cloned domain controller

  • Step 7: Copy or export the source VM and add the XML if not already copied
  • Step 8: Create a new virtual machine from the copy
  • Step 9: Start the new virtual machine to commence cloning

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.