We're designing a disaster recovery plan for an Azure environment that contains domain controllers providing custom DNS for the virtual network, several member servers, and a SQL database server. We're considering Azure Site Recovery for failover during a zone or region outage, but I've read that replicating domain controllers with ASR can create problems. What's the recommended architecture for protecting the domain controllers, DNS, and SQL, and what should we plan for when testing a failover?
4 Answers
Avoid using Azure Site Recovery to replicate domain controllers. Deploy domain controllers in the target zone or region and let Active Directory replication keep them synchronized. DNS zones should be available across the domain controllers as well. For SQL, native SQL options such as Availability Groups, log shipping, or a managed database failover group are generally preferable to treating the database VM as a simple ASR workload. ASR is best reserved for systems that don’t have a suitable native redundancy option. Keep DNS TTLs low, avoid hard-coded server addresses, prepare failover runbooks, and test the entire process regularly.
First clarify whether you’re protecting against a single availability-zone failure or a complete regional outage. For zone resilience, place domain controllers across multiple zones and make sure the application can tolerate losing one zone. For regional resilience, maintain at least a small landing environment in another region, deploy a domain controller there, and let it replicate from the existing environment rather than using ASR for AD.
A practical setup is to have domain controllers in both regions. Each region can use its local controller as preferred DNS and the remote region’s controller as secondary DNS. Keep the domain controllers focused on AD DS and DNS; avoid adding unrelated roles such as DHCP or certificate services unless you have a separate recovery design for them.
For SQL, consider a managed database failover group or SQL Availability Groups if the workload supports them. Those options provide database-aware failover and connection redirection, which is usually more reliable than restoring a whole SQL VM. Whatever approach you choose, validate application connection strings, DNS behavior, authentication, and the order of operations in a documented recovery exercise.
ASR can work for moving or recovering some SQL VMs, but I’d still favor database backups, log shipping, or a native replica where possible. Rebuilding a failed domain controller is usually simpler than recovering one from a replicated VM image.