Design Considerations of Building a Replica Domain Controller ARM Template

Inside the Cloud Adoption Framework, the first migration pattern surrounds rehosting workloads. Since rehosting means workloads move out of the primary datacenter and into Azure without making too much of a change the first iteration, most customers decide to build out replica domain controllers in Azure after hybrid connectivity is set up. Microsoft even provides an excellent reference architecture surrounding extending your ADDS infrastructure into Azure. The big takeaways are covered in the recommendations section (and we covered some of these pre-requisites during the last blog post). I want to call out a few of the design considerations within this blog post to bring awareness to what winds up deploying if you use my ARM Template:

• Load Balancer vs VM Size – By default, ADDS is designed to handle replication, synchronization, etc. A load balancer is not required to direct requests to each replica domain controller, so my template does not deploy a load balancer to get your environment up and functional. The bigger consideration is ensuring you have the correct VM size allocated to handle the amount of authentication requests. If your company is not sure what size to select, a good rule of thumb is to start monitoring performance of your on-premises ADDS domain controllers (if you are not already), or select a SKU that best matches your VM size on-premises. Note, I tend to deploy D series VMs as domain controllers that hold the Active Directory Domain Services role within my environments.
• Static IPs - ADDS environments in Azure require static IP addresses. The template I will walk you through already has that information sorted within the code. Since ADDS is more of a traditional IT solution, it leans upon static IP addresses, just as many Windows environments have done over the course of time. 
• Availability Set – High availability (HA) is a must for any IT production system. Within Azure, there are two different types of HA configurations: Availability Sets and Availability Zones. For my initial quickstart ARM Template, I place 2 VMs into an Availability Set vs. an Availability Zone. “Well, what is the difference?” you may find yourself asking. An Availability Set allows workloads to be spread over multiple hosts and racks, but still reside in 1 datacenter. The typical design pattern is to place the VMs behind a load balancer, but remember, domain controllers do not need to be behind a load balancer (and as a result, the VMs in my template are not behind a load balancer as I covered). An Availability Set’s service level agreement (SLA) will still be met without a load balancer. Additionally, an Availability Set requires 2 or more VMs to meet the right HA SLA of 99.95% uptime within 1 of Azure’s datacenters inside a given region. An Availability Zone takes the initial concept of an Availability Set but spreads the workloads across different datacenters within a given region. Considering the way domain controllers replicate, an Availability Set is most likely the direction to go, however an Availability Zone configuration means you will have a 99.99% SLA related to uptime. Lastly, an Availability Zone will require a load balancer to unify the workload across multiple datacenter regions.
• Separate Data Disk - Microsoft's best practice recommendation is to store the database, logs, and sysvol folder on a separate drive for ADDS. Azure implements write caching on the OS disk of virtual machines. Write caching can cause some headaches for databases such as the database Active Directory uses. As a result, you will want the separate data disk to not have caching enabled and my template factors in that design consideration.
• Read Only Domain Controllers - A lot of the customers I have worked with become extremely security conscious related to deployments in Azure. RODCs are supported in Azure, but really RODCs are for when you cannot guarantee the physical security of the server. With Azure's tight controls and disk encryption, it's unlikely a domain controller could be "stolen" in a way where a RODC would help.

In working with customers surrounding Azure adoption, there have only been a handful of times when customers chose to build out a cloud island (where nothing talks to on-premises) or built out a brand-new forest in Azure that trusted production (but production did not trust the Azure forest). I would say 85-90% of the time, customers decide to extend their ADDS environment into Azure, as it matches up to where most enterprises land (and where we will be for a bit): hybrid.

Tune in next week as we start exploring the code I have developed so you can start to feel more comfortable with what an automated replica domain controller build looks like using an ARM Template.