The recovery operations.
In part 1, the basic operations of the VM Generation-ID was presented. In part 2, the definitions of, and issues with, snapshots on virtualized Domain Controllers were discussed. In this part of the series, we will describe how the VM GenerationID feature will be used to attempt to save the DC from a replication failure.
As presented in part 1, the hypervisor will initially create a value called the VM GenerationID. The value is unique to each virtual machine. The number will be “exposed” into the guest operating system through a virtual system device, which appears to the guest as a physical device attached to the guest’s motherboard.
The device will, inside the guest, be called “Microsoft Hyper-V Generation Counter“. Note that VMware environments (and possibly other hardware virtualisation platforms) also present this device using the same Hyper-V name.
During the normal lifetime of the Domain Controller, the VM GenerationID is expected to stay the same.
On the first VM restart after the Domain Controller promotion, the GenerationID is written to the attribute msDS-GenerationId on each Domain Controller object.
On every succeeding VM reboot, the Active Directory engine will read the value on the “hardware” device and compare it with the NTDS value. This will be recorded by the event-id 2172 in the Directory Service EventViewer log.
The Domain Controller is now responsible to continuously verify that the GenerationID, exposed through the “hardware” device, is not changed from the LDAP value stored on the DC object. The DC will read the value not only at each reboot, but on every Active Directory write / modification operation. This is because the guest operating system has no inherent way of knowing if a snapshot revert has occurred at any given moment in time.
The hypervisor owns the current GenerationID number. The hypervisor is responsible to change the GenerationID number under very specific conditions.
The number should NOT be changed when:
- The virtual DC is restarted.
- The virtual DC is live migrated.
- The virtual DC hardware configuration is changed.
- The virtual DC is being snapshoted.
- The virtual DC snapshot is deleted/committed.
However, the hypervisor MUST change the GenerationID when:
- The virtual DC is reverted to a previous snapshot.
- The virtual DC is cloned.
Let us now examine the events that will take place if an administrator, unwisely, do revert a Domain Controller to an older snapshot state.
Above, after the snapshot restore, a new GenerationID is created by the hypervisor.
Suppose a virtual Domain Controller was reverted to a previous snapshot by the administrator. This action is performed by the hypervisor, which simultaneously generates a new GenerationID, which is written to the VM configuration file. The new value is then “pushed” into the virtual hardware through the VM GenerationID device.
The guest operating system, running the DC service, will, at its next database modification, notice the change on the virtual device, thereby realizing that a snapshot revert must have occurred.
Event-id 2170 will be triggered when this, most serious, state has been detected by the guest.
(Note in the event description how the new GenerationID inside the guest matches the ID created in the VM config file in the picture above.)
To be able to “survive” as a functional Domain Controller, the reverted DC must now take two critical actions:
- Create a new Domain Controller Invocation ID.
- Release the current RID pool and request a new pool.
Successfully completing these two actions effectively puts the DC into a position very similar to being restored from an Active Directory-aware backup software.
Note, the Invocation ID number is not the same as the GenerationID. The Invocation ID is the internal “true identifier” of a Domain Controller in the replication topology, known to all partner DCs. The VM GenerationID is a number only relevant to the local Domain Controller. All DCs will always have an Invocation ID, but only a virtual Domain Controller will have a VM GenerationID.
While the VM GenerationID is a hypervisor-level value used to detect snapshot events locally, the Invocation ID is a forest-level replication identifier known to other DCs, ensuring that replication metadata remains consistent after a reset or restore.
Initially, the Domain Controller had a certain Invocation ID. This could be read, for example, with the “repadmin /showrepl” command.
The Domain Controller is now reverted to a previous snapshot. The guest DC detects this otherwise invisible event through the change of the GenerationID. The DC creates a new Invocation ID for itself, which can be verified with the same “repadmin /showrepl” command.
When the Invocation ID changes, replication partners will start treating the DC as a newly restored peer.
The allocated RID pool must now be managed.
Display the current RID pool:
The current RID pool for a Domain Controller can be verified with the command: “dcdiag /test:RIDmanager /v“. In the image above, the DC’s RID pool before the snapshot revert is displayed.
Now, the snapshot revert has been detected and the DC immediately requests a new RID pool from the FSMO RID Master.
The reverted Domain Controller is now again a functional replication partner in the domain.
Although Active Directory, with the help of the hypervisor, can recover from a snapshot revert, it is only considered a method to save the domain replication from failure. Snapshot reverts should never intentionally be used on Domain Controllers.
Summary of part 3:
- The hypervisor can signal to the guest DC that a snapshot revert has taken place.
- The DC is made aware of the event through the “hypervisor signal”, i.e., the change of the GenerationID on the virtual hardware device.
- Once aware, the DC can take corrective actions to be able to survive as a Domain Controller. These actions include generating a new database Invocation ID as well as acquiring a new RID pool.
In part 4, the possibility of disabling the protective feature will be described.