Deploying a Virtualized DC
Start course
1h 3m

Windows Active Directory Domain Services (AD DS) is a leading identity management solution for organizations of all sizes. At the core of Windows AD DS is the domain controller. The domain controller provides login services, group policies, domain naming services (DNS), and other identity management services for users and computers in a domain along with other enterprise management services.

In this course, we start by reviewing the Windows AD DS environment including forests and domains. Then we review considerations for deploying domain controllers in a virtualized environment, on-premises, and in Azure. Next, we look at use cases for deploying read-only domain controllers at locations where physical security cannot be guaranteed. Lastly, we examine flexible single master operations roles and how to locate and move them to support troubleshooting efforts.

Learning Objectives

  • Deploy and manage domain controllers on-premises
  • Deploy and manage domain controllers in Azure
  • Deploy read-only domain controllers (RODCs)
  • View, manage, and troubleshoot flexible single master operations (FSMO) roles

Intended Audience

  • System administrators with responsibilities for managing hybrid identities
  • Subject matter experts in configuring and managing Active Directory workload on-premises and in Azure
  • Anyone preparing for the Azure AZ-800 Administering Windows Server Hybrid Core Infrastructure exam



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.


About the Author

Travis Roberts is a Cloud Infrastructure Architect at a Minneapolis consulting firm, a Microsoft MVP, MCT, and author. Travis has 20 years of IT experience in the legal, pharmaceutical, and marketing industries and has worked with IT hardware manufacturers and managed service providers. In addition, Travis has held numerous technical certifications throughout his career from Microsoft, VMware, Citrix, and Cisco.