I'm getting conflicting guidance about moving a Hyper-V virtual machine that runs a domain controller to a new host. Microsoft documentation warns against using Hyper-V Export for domain controllers because of possible USN rollback, but other guidance suggests that Windows Server 2012 and later can detect a changed virtual Generation ID and handle the move like a nonauthoritative restore.
Is live migration safe? What about shutting down the VM and copying its files to another host? Does the answer change if the hosts aren't part of a cluster? Is demoting the existing domain controller and building a new one the only fully safe option? I'd like to understand the supported recovery and migration methods for situations where rebuilding a domain controller isn't convenient.
4 Answers
The documentation is confusing because it discusses several scenarios in different sections. On supported Windows Server versions, Generation ID lets the domain controller recognize certain VM restore or import operations and take nonauthoritative recovery steps, which helps prevent USN rollback. However, an Export/Import operation can still trigger extra recovery work, so it isn’t the preferred way to perform a routine hardware move. Live migration or a clean shutdown and file move is less disruptive.
A planned shutdown followed by moving or copying the VM files is also normally fine. The important part is that the domain controller is shut down cleanly rather than restored from an old snapshot or copied while it is running. After bringing it up on the new host, verify Active Directory replication, DNS, and SYSVOL.
Live Migration is generally the cleanest option. The VM stays intact, and the virtual Generation ID should not change during a normal migration. Shared-storage and shared-nothing live migration are both commonly used for domain controllers, and clustering isn’t required for the basic principle to work. Make sure the guest OS and Hyper-V hosts support Generation ID and that you have a current system-state backup.
If the VM is imported or restored, treat it as a recovery event rather than assuming everything is unchanged. With multiple domain controllers, don’t restore several old copies independently; restore one and rebuild or resynchronize the others as needed. For a normal hardware replacement, keeping another healthy domain controller available and rebuilding the old one is often the simplest and lowest-risk approach, but it isn’t the only valid option.
Having only one domain controller makes recovery riskier, not safer. There may be no partner to replicate from, so a system-state backup and a tested recovery plan are especially important in that situation.