New features in Active Directory Domain Services in Windows Server 2012, Part 12: Virtualization-safe Active Directory

In organizations with different teams being responsible for Active Directory management and management of the virtualization/hypervisor layer, it is not uncommon to seriously damage contents in Active Directory with snapshots. Virtualization Admins can easily cripple Active Directory by reverting a snapshot of a virtual Active Directory Domain Controller, since Active Directory, currently, is not virtualization-aware.

Microsoft has been advising people not to use snapshots or any of the fancy server virtualization features on virtual Domain Controllers, for that reason. But then, virtualization admins might not know which virtual servers are Domain Controllers. It's not entirely their fault, either, because sometimes Active Directory admins don't know which servers are Domain Controllers because of overly complex server naming, change after change in an undisclosed change management process and/or merger/acquisition scenarios.

Making Active Directory virtualization-aware and making Active Directory virtualization-safe, therefore, is a welcome feature for these organizations. Also, for less knowledgeable Active Directory Admins virtualizing Active Directory Domain Controllers, those features would prevent them from inadvertently introducing USN Rollbacks and Lingering Objects.

USN Rollbacks

Domain Controllers replicate changes. Whenever a change occurs on a Domain Controller, the Unique Serial Number (USN) of that Domain Controller increases. Each Domain Controller records the USNs it sees of its replication partners. This is recorded in the High Watermark Table. Replication partners are denoted using Invocation IDs in this table. The combination of USN and Domain Controller is captured as the up-to-dateness vector.

When you restore a Domain Controller to an earlier state, you would restore the USN to an earlier state. This is called an USN rollback.

Since its replication partners have seen a future USN for the Domain Controller and objects in Active Directory record the Domain Controller they originated on in the replication metadata, no changes on objects will be replicated out until the restored Domain Controller reaches the USN recorded in the High Watermark Table. This effect, called an USN Bubble, causes user accounts and computer accounts that are created on the restored domain controller to not exist on replication partners. Or, the password updates that originated there do not exist on replication partners.

Lingering Objects

When you delete an object in Active Directory it doesn't really get deleted, it gets tombstoned. In this process all but its most critical attributes (objectGUID, objectSid, nTSecurityDescriptor, uSNChanged and sIDHistory) are stripped and the changes are replicated between Domain Controllers. Only after the tombstone lifetime, the object gets deleted. This deletion takes place every 12 hours by the Garbage Collection process per Domain Controller.

In normal situations, the tombstone process allows Domain Controllers to have sufficient time to replicate the tombstones. However, when you restore a Domain Controller to a point in time beyond the tombstone lifetime, the process may fail and objects that you expect to have been deleted may still exist on some Domain Controllers. These objects are called lingering objects.

More information on both these problems can be found in the free whitepaper I wrote earlier this year:

What's New

Active Directory Domain Services is the first Windows Server Role to take advantage of the VM-GenerationID. This random 128bit identifier is a new feature of Hyper-V in Windows Server 2012 and is placed in the RAM of each virtual machine (VM). Every VM gets its own VM-GenerationID from the virtualization platform. The virtualization platform keeps the VM-GenerationID the same for a VM, unless the VM is reverted back to a snapshot.

A virtual Domain Controller, running Windows Server 2012 reads this value when it starts and before every write to the Active Directory database. It stores the value of VM-Generation ID in the msDS-GenerationID attribute of its object in the local Active Directory database.

For every write, the Active Directory service compares the VM-GenerationID in RAM with the ms-DS-Generation-Id attribute in the Active Directory database. If they match, no problem. If they don't match, the Domain Controller has either been reverted to a previous snapshot, or the virtual disk of the Domain Controller has been reused for a different Domain Controller.

In the case of a snapshot, the invocationID is renewed and the RID Pool block in use is discarded. This effectively designates the Domain Controller as a new replication partner for other Domain Controllers, so they can replicate in necessary changes to avoid USN Rollbacks and Lingering Objects.   

Exposing the VM-GenerationID

There are two ways to see the VM-GenerationID. The difficult way is to look in the Device Manager. When you fulfill the requirements (below) you will see a device called Hyper-V Generation Counter under System Devices:

As stated in the Virtual Machine Generation ID whitepaper, there is a way to substract the parts of the VM-GenerationID and construct it.      

Requirements

The virtualization safeguards incorporated around VM-GenerationID will help Domain Controllers prevent USN Rollbacks and Lingering Objects when you fulfill the following requirements:

• The virtualization platform used to run virtual Domain Controllers needs to support the VM-GenerationID feature.
• Virtual Domain Controllers need to run Windows Server 2012.