Virtualized Domain Controllers and snapshots.
In part 1 of the VM Generation-ID, the basic construction of the msDS-GenerationId attribute was described. In part 2, the various forms of Domain Controller snapshots will be discussed.
At times, generic statements as “Snapshots must never be used on Domain Controllers” are made. However, the general term “snapshots” has several important nuances. On a virtual machine, three typical snapshot operations are possible:
(Example from VMware Workstation.)
A. A snapshot is taken from the hypervisor layer, e.g., Hyper-V or VMware ESXi.
The details will differ depending on the hypervisor model, but typically will a taken snapshot preserve the exact state of the virtual machine hard disks at the very moment the snapshot was taken. All new disk writes will be collected into differencing disks, commonly referred to as “delta files”, depending on hypervisor terminology.
A guest virtual machine is typically not aware that a snapshot was taken, and nothing changes logically on the operating system or Active Directory level.
B. A snapshot is deleted / committed.
The “deletion” of a snapshot typically results in the removal of the possibility to revert back to a specific moment in time. Technically, the deletion of a snapshot is conducted by writing all changes from the delta files into the main virtual hard disk file.
A guest virtual machine is typically not aware that a snapshot was deleted/committed, and nothing changes logically on the operating system or Active Directory level.
The combination of A + B (take snapshot + delete snapshot) is often used by backup software as a means to gain access to a consistent state of a virtual hard disk. After the backup is completed, the snapshot is “deleted”, i.e., the writes committed to the live VM during the backup are written to the main virtual disk.
A + B is not an issue on virtualized Domain Controllers. However, the final snapshot operation is:
C. The virtual machine is reverted to a previous snapshot state.
This action essentially rolls the VM “back in time” to the point when the snapshot was originally taken.
The guest operating system is typically unaware that a snapshot revert has occurred, at least initially. From the guest’s perspective, everything is normal, despite effectively having lost all memory of a certain number of hours or days.
A snapshot revert has a dramatic change logically on the operating system and Active Directory level.
The combination of A + C, (take snapshot + revert to snapshot) however, will destroy the relationship between the Domain Controllers. A Domain Controller being snapshot-reverted will not only “forget” all changes that were replicated inwards from the partners. It will also “forget” all changes the DC itself originally wrote in the local NTDS database and then replicated outwards to partners. This is called the USN-Rollback state.
The USN rollback state will occur no matter if the snapshot was taken “warm” or “cold”, that is, if the Domain Controller was started or shutdown at the time.
A + C is a critical issue on virtualized Domain Controllers.
A snapshot revert must never be conducted on a virtualized DC.
If an administrator, by mistake, reverts a DC to a previous snapshot state, the VM GenerationID feature will attempt to save the DC from failure. This operation will be described in part 3 of the series.
Summary of part 2:
- Snapshot can be both taken as well as deleted on Domain Controllers without issues.
- Snapshot must not be reverted on Domain Controllers.
Read part 3 of the VM GenerationID series here.