Virtualization is the default way to deploy servers in most environments. It's more economical than bare metal installations and most virtualization platforms come with the benefits of enterprise management tools and advanced monitoring. There are some considerations when virtualizing a domain controller. However, Active Directory Domain Services or  AD DS uses a multi-master data store and relies on a logical clock-based replication scheme. Updates are made to multiple copies of the domain directory partition. Those updates are then replicated to other copies of the data store in the directory.

The database relies on an increasing value called the Update Sequence Number or USN. A USN is assigned to each transaction on the domain controller. In addition, each database on the domain controller has a unique identity known as an invocation ID. The invocation ID and the USN combined to make a unique identifier for each write transaction performed on each domain controller. Each transaction ID is unique in the forest. The  AD DS replicas rely on the invocation ID and the USN to determine the changes that need to be replicated to other domain controllers. Let's say for example, User A changes their password and that creates a unique ID on that domain controller's database. That transaction is replicated to all other domain controllers.

Now, something happens on that server and it rolls back to a state prior to User A's password change. Next, another user, User B enters the wrong password too many times and that account is locked out on that same domain controller. But because that domain controller was rolled back, it uses the same ID as User A's password change. Because the invocation ID and the USN are the same, User B's lockout is not replicated to the rest of the domain controllers. They already have that transaction ID in their database.

Imagine how messy this would be in large environments. How could that roll back take place? There could be a couple of causes. It's easy to roll back a virtual machine in a virtualized environment with snapshots. That's one of the benefits of a virtualized environment. But rolling a domain controller back outside of its awareness could cause a database rollback. The good news is that starting with Windows Server 2012, virtualized domain controllers take advantage of an identifier called the VM generation ID. This ID

can detect and provide safety measures to protect virtualized domain controllers in the event of a rollback. Another instance where a rollback could take place is when disk caching is used on disks that store the  AD DS database. If the transaction is written to cache for example, then power is lost or some other issue, shuts down the domain controller before that transaction is committed to the disk, that could cause a rollback. That's why it's recommended to disable write caching on disks that store Active Directory Domain Service's databases.

A USN rollback can be hard to detect. One way to identify the problem is to look for event 2095 in the domain controller event log. This indicates that the source Domain Controller sent a previously acknowledged USN. There's also a registry key that will indicate the directory system agent or DSA is not writable. This indicates that a USN rollback has occurred. The best way to safeguard against the USN rollback, is first, disable write caching.

Second, don't rely on snapshot backups for domain controllers. Use a Windows AD aware backup instead, such as Windows server backup. Always have at least two copies of domain controllers. If one should become unavailable, replace it with a new server and allow the most recent copy of the  AD DS database to replicate to the new server. If the Active Directory Domain Service's database becomes corrupt, use an active directory aware backup to recover the database. Of course, that requires routine backups of the Active Directory Domain Services database. It's also recommended to test these backups on an isolated network to verify they work.