As part of the many updates to Active Directory, one of the most interesting is virtualization safeguarding in Windows Server 2012.

Active Directory Domain Controllers running Windows Server 2012 can now identify if they are virtualized and have been improperly restored or cloned (copied). Windows Server 2012 introduces a new feature called the VM Generation ID which is used to track the virtual machine (VM) on which the OS is running. When a new VM is created in a hypervisor that supports the feature (Hyper-V 2012 & VMWare vSphere 5.1), a VM Generation ID is created by the hypervisor and associated with the VM as the unique VM guest identifier. The VM Generation ID is a 128-bit cryptographically random  integer that changes when the VM’s configuration file changes. The virtual machine’s BIOS provides the VM Generation ID to the OS in an 8-byte aligned buffer in guest RAM, ROM, or device memory space which can be queried via ACPI namspace with a compatible ID of “VM Gen Counter” (also a DOS Device Name of “VM_Gen_Counter”. When the generation ID changes, there is an ACPI Notify operation on the generation ID device ID device using notification code 0x80 (an ACPI GPE can triger this notification).

Each Domain Controller has a unique identifier called the Invocation ID for the Active Directory database instance on that DC. When a DC is backed up and restored, the Invocation ID changes. Each DC tracks changes it makes to its local AD database, NTDS.dit, using an incremental counter called the Update Sequence Number (USN). Active Directory replication leverages a combination of the InvocationID and the USN in order to determine what data a DC requests from other DCs. The USN normally only increases in value; however, there are circumstances where a “USN rollback” occurs such as when a DC’s VM snapshot is restored. With a USN roollback, the DC is improperly restored to a point in time “rolling back” the USN to a previous value. The DC doesn’t have AD data that other DCs have and believe that it has (for more information, read my article on the subject: USN rollback). The new VM Generation ID protects against this scenario.

At first boot-up, a virtualized Windows Server 2012 Domain Controller queries the hypervisor for the VM Generation ID and stores it in in the Active Directory database file (NTDS.dit). Each time the DC is rebooted, the VM’s current VM Generation ID is compared with the value in the DC’s NTDS.dit file (ms-DS-Generation-Id). If the values are different, the DC resets the invocation ID, discards the RID pool, and updates the value in the DC’s NTDS.dit file.  The DC also non-authoritatively synchronizes the SYSVOL folder to ensure proper operation and replication.

NOTE: The ms-DS-Generation-Id computer attribute does not replicate – to view a specific DC’s Generation ID, query for it on that DC.

Here’s the value when viewed in ADUC on the DC:

Powershell command to view the VM Generation ID associated with a 2012 DC:
Import-module activedirectory ;
(Get-ADObject “CN=MCLABDC01,OU=Domain Controllers,DC=MCLAB,DC=net” -server mclabdc01.mclab.net -property msds-generationid).’msds-generationid’

You may notice in the graphic above that when querying DC02 for DC01’s msds-generationid attribute value, it is blank. Since this value does not replicate, you have to query for the value on the DC that stores the value.

This feature also provides the capability to clone (copy) Domain Controllers.

Scenarios where the VM Generation ID is changed:

• Virtual machine starts executing a snapshot.
• Virtual machine is recovered from a backup.
• Virtual machine is failed over in a disaster recovery environment.
• Virtual machine is imported, copied, or cloned.
• Virtual machine’s configuration changes (depending on change).
• Virtual machine is moved from a hypervisor host not supporting VM Generation ID to one that does.

Only Domain Controllers running Windows Server 2012 on a Hyper-V 2012 or VMWare vSphere 5.1 VM support this feature.

VMWare VM-Generation-ID support:

• VMware vSphere 5.0 Update 2 (vCenter Server and ESXi must both be at 5.0 Update 2)
• VMware vSphere 5.1 (ESXi must be at least 5.0 Update 2)

Some key caveats:

With this new capability come several requirements and limitations:

* A restored domain controller must be able to contact a writable DC.

If restored, a domain controller must have connectivity to a writable domain controller; a read-only domain controller cannot send the delta of updates. The topology is likely correct for this already, as a writable domain controller always needed a writable partner. However, if all writable domain controllers are restoring simultaneously, none of them can find a valid source. The same goes if the writable domain controllers are offline for maintenance or otherwise unreachable through the network.

* All domain controllers in a domain must not be restored simultaneously.

If all snapshots restore at once, Active Directory replication works normally but SYSVOL replication halts. The restore architecture of FRS and DFSR require setting their replica instance to non-authoritative sync mode. If all domain controllers restore at once, and each domain controller marks itself non-authoritative for SYSVOL, they all will then try to synchronize group policies and scripts from an authoritative partner; at that point, though, all partners are also non-authoritative.

* Any changes originating from a restored domain controller that have not yet replicated outbound since the snapshot was taken are lost forever.

Here’s an excerpt from Microsoft Article: Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100):

Safe virtualization of domain controllers:

Virtual environments present unique challenges to distributed workloads that depend upon a logical clock-based replication scheme. AD DS replication, for example, uses a monotonically increasing value (known as a USN or Update Sequence Number) assigned to transactions on each domain controller. Each domain controller’s database instance is also given an identity, known as an InvocationID. The InvocationID of a domain controller and its USN together serve as a unique identifier associated with every write-transaction performed on each domain controller and must be unique within the forest.

AD DS replication uses InvocationID and USNs on each domain controller to determine what changes need to be replicated to other domain controllers. If a domain controller is rolled back in time outside of the domain controller’s awareness and a USN is reused for an entirely different transaction, replication will not converge because other domain controllers will believe they have already received the updates associated with the re-used USN under the context of that InvocationID.

For example, the following illustration shows the sequence of events that occurs in Windows Server 2008 R2 and earlier operating systems when USN rollback is detected on VDC2, the destination domain controller that is running on a virtual machine. In this illustration, the detection of USN rollback occurs on VDC2 when a replication partner detects that VDC2 has sent an up-to-dateness USN value that was seen previously by the replication partner, which indicates that VDC2’s database has rolled back in time improperly.

A virtual machine (VM) makes it easy for hypervisor administrators to roll back a domain controller’s USNs (its logical clock) by, for example, applying a snapshot outside of the domain controller’s awareness. For more information about USN and USN rollback, including another illustration to demonstrate undetected instances of USN rollback, see USN and USN Rollback.

Beginning with Windows Server 2012, AD DS virtual domain controllers hosted on hypervisor platforms that expose an identifier called VM-Generation ID can detect and employ necessary safety measures to protect the AD DS environment if the virtual machine is rolled back in time by the application of a VM snapshot. 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. This identifier can be sampled by services and applications running inside the virtual machine to detect if a virtual machine has been rolled back in time.

How do these virtualization safeguards work?

---

During domain controller installation, AD DS initially stores the VM GenerationID identifier as part of the msDS-GenerationID attribute on the domain controller’s computer object in its database (often referred to as the directory information tree, or DIT). The VM GenerationID is independently tracked by a Windows driver inside the virtual machine.

When an administrator restores the virtual machine from a previous snapshot, the current value of the VM GenerationID from the virtual machine driver is compared against a value in the DIT.

If the two values are different, the invocationID is reset and the RID pool discarded thereby preventing USN re-use. If the values are the same, the transaction is committed as normal.

AD DS also compares the current value of the VM GenerationID from the virtual machine against the value in the DIT each time the domain controller is rebooted and, if different, it resets the invocationID, discards the RID pool and updates the DIT with the new value. It also non-authoritatively synchronizes the SYSVOL folder in order to complete safe restoration. This enables the safeguards to extend to the application of snapshots on VMs that were shutdown. These safeguards introduced in Windows Server 2012 enable AD DS administrators to benefit from the unique advantages of deploying and managing domain controllers in a virtualized environment.

The following illustration shows how virtualization safeguards are applied when the same USN rollback is detected on a virtualized domain controller that runs Windows Server 2012 on a hypervisor that supports VM-GenerationID.

In this case, when the hypervisor detects a change to VM-GenerationID value, virtualization safeguards are triggered, including the reset of the InvocationID for the virtualized DC (from A to B in the preceding example) and updating the VM-GenerationID value saved on the VM to match the new value (G2) stored by the hypervisor. The safeguards ensure that replication converges for both domain controllers.

With Windows Server 2012, AD DS employs safeguards on virtual domain controllers hosted on VM-GenerationID aware hypervisors and ensures that the accidental application of snapshots or other such hypervisor-enabled mechanisms that could ‘rollback’ a virtual machine’s state does not disrupt the AD DS environment (by preventing replication problems such as a USN bubble or lingering objects). However, restoring a domain controller by applying a virtual machine snapshot is not recommended as an alternative mechanism to backing up a domain controller. It is recommended that you continue to use Windows Server Backup or other VSS-writer based backup solutions.

References:

• Microsoft Article: Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100)
• Microsoft Virtual Machine Generation ID Whitepaper document
• Virtualize your Windows Server 2012 domain controllers
• Things to consider when you host Active Directory domain controllers in virtual hosting environments
• Virtualized Domain Controller Deployment and Configuration
• Windows Server 2012 VM-Generation ID Support in vSphere
• ms-DS-Generation-Id Attribute