Virtualization can be a smart move for Domain Controllers. Typically, these servers don’t consume many resources, making them a perfect fit atop a hypervisor.
However, virtualizing your Domain Controllers adds an insidious capability that at first blush might seem like a good idea: Snapshots.
To be frank, here is the advice you should follow regarding snapshots and virtualized DCs: Never, never, never, never, never, never…never…do it. Never. Ever.
Creating and then reapplying a snapshot to a virtualized DC can create a situation known as Update Sequence Number (USN) rollback. Previously only a problem when you brought online Domain Controllers that were down for very long periods of time (like, literally, a half-year or more), USN rollback comes back with a vengeance when DCs are restored using snapshots.
Here’s what happens:
- At some point, you create a snapshot of the Domain Controller.
- After taking that snapshot, the DC then going about processing is usual changes to the AD database. Those changes are then replicated to other DCs in the forest. With each change is an increase to the USN, which serves as a sort of up-to-date measurement answering the question of, “Who’s got the most recent version of the database?”.
- Sometime later, you restore the DC by using the snapshot you took earlier. This restore also restores the value of the USN to its previous number. After the restoration, the DC then goes about making changes again to its database, incrementing the USN. But, this time the USN isn’t correct. Its the old USN.
Two things can happen at this point.
First, if by the next replication cycle the value of the USN on the restored DC hasn’t reached the value it had before the restore operation, any inbound replication partner will detect that the DC was improperly restored. It will signal to the forest to quarantine the DC. This is done to protect the forest.
Second, if the USN has surpassed that previous value, the DC will replicate only those changes that correspond to the USN values between the value stored in its up-to-dateness vector and the new value. This creates a situation where data on different DCs is now different, even though replication believes it to be the same. Due to the way replication is handled through USN numbers and up-to-dateness vectors, the differences in data cannot be detected, and likely cannot be corrected. In short, you’ve got an exceptionally big problem that you might not be able to fix!
So, in short, never snapshot a DC. It could create a catastrophic Resume Producing Event.
Get more virtualization tips just like this one at http://windowsitpro.com/go/gregshieldsvirtualization.
