So, what will we be building? To keep things relatively simple in explanation, the template itself focuses on the actual Active Directory domain controllers in the red outlined box:

As you can see though, there are a few other things to the left in the diagram that I did not reference inside the template I created. As you probably guessed, there are a few pre-requisites you should ensure are met before running the template. I will outline all pre-requisites here to help demystify the pieces you need configured ahead of time:



Hybrid Connectivity – Site-to-site connectivity needs to be established from on-premises to Azure. This can be achieved by creating a site-to-site VPN or building out ExpressRoute with private peering. For the VPN and ExpressRoute, Microsoft offers up several instructions to follow for configuration:

VPN configuration: portal , PowerShell , Azure CLI , and the ARM Template quickstart .

ExpressRoute circuit configuration: portal , PowerShell , Azure CLI , and ARM Template .

ExpressRoute peering configuration: portal , PowerShell , and Azure CLI .

– Site-to-site connectivity needs to be established from on-premises to Azure. This can be achieved by creating a site-to-site VPN or building out ExpressRoute with private peering. For the VPN and ExpressRoute, Microsoft offers up several instructions to follow for configuration: portal PowerShell Azure CLI ARM Template quickstart portal PowerShell Azure CLI ARM Template portal PowerShell Azure CLI DNS – In order for the template to work, DNS needs to point to the on-premises domain controller environment. When the servers come online, they will need to know how to resolve DNS in order to both join the domain and be promoted as a replica domain controller. This custom DNS server setting is configured within your virtual network (VNet), which you can configure by following this link.



– In order for the template to work, DNS needs to point to the on-premises domain controller environment. When the servers come online, they will need to know how to resolve DNS in order to both join the domain and be promoted as a replica domain controller. This custom DNS server setting is configured within your virtual network (VNet), which you can configure by following this link. Secret Management – A Key Vault needs to exist within the subscription and hold secrets for the local admin username, local admin password, domain admin username, and domain admin password. In order to configure Key Vault and add secrets to reference during a template deployment, please refer to the following documentation: portal , PowerShell , Azure CLI . As enterprises develop more Infrastructure as Code strategies, there should be a mandate where no sensitive data exists within any code checked into source control. Using this template will help you adhere to a stronger security policy and protect you from exposing any vulnerabilities that could possibly leave you compromised. In order to reference the Key Vault secret, you will need to stage all values within the parameters file (early foreshadowing - we will not dig too much into this aspect right now, but save this tidbit below for the future). By using the template, you will need to adjust the following components when the time comes (I have highlighted the code in my example):







9f27316b-43a0-4f1b-9449-3d798ebdd43f is a random GUID I created, but for purposes of illustration, think of that value as my subscription GUID. kv-6e6dnpt2p5fxi is the randomly generated Key Vault name I built within my environment. For the ARM Template to pull each secret out, you will need to adjust those two values to match your environment (you may want to also adjust the secret name). Running the following command will get the subscription ID of your active context and even copy it to your clipboard: (Get-AzContext).Subscription.Id | clip If you paste in a wrong GUID, simply run Get-AzSubscription to receive a listing of all GUIDs you have access to with your profile: Get-AzSubscription

– A Key Vault needs to exist within the subscription and hold secrets for the local admin username, local admin password, domain admin username, and domain admin password. In order to configure Key Vault and add secrets to reference during a template deployment, please refer to the following documentation: portal PowerShell Azure CLI As enterprises develop more Infrastructure as Code strategies, there should be a mandate where no sensitive data exists within any code checked into source control. Using this template will help you adhere to a stronger security policy and protect you from exposing any vulnerabilities that could possibly leave you compromised. In order to reference the Key Vault secret, you will need to stage all values within the parameters file (early foreshadowing - we will not dig too much into this aspect right now, but save this tidbit below for the future). By using the template, you will need to adjust the following components when the time comes (I have highlighted the code in my example): 9f27316b-43a0-4f1b-9449-3d798ebdd43f is a random GUID I created, but for purposes of illustration, think of that value as my subscription GUID. kv-6e6dnpt2p5fxi is the randomly generated Key Vault name I built within my environment. For the ARM Template to pull each secret out, you will need to adjust those two values to match your environment (you may want to also adjust the secret name). Running the following command will get the subscription ID of your active context and even copy it to your clipboard: If you paste in a wrong GUID, simply run Get-AzSubscription to receive a listing of all GUIDs you have access to with your profile: IAM – the account running the template would need to have the right levels of permissions to run through the deployment. Within all tests I’ve run, I am the Account Owner for my subscription. A Contributor and Virtual Machine Contributor should have the right access as well. If there are more flavors of granularity or you use custom RBAC roles, there may need to be some experimentation on if a role can run this template successfully.



– the account running the template would need to have the right levels of permissions to run through the deployment. Within all tests I’ve run, I am the Account Owner for my subscription. A Contributor and Virtual Machine Contributor should have the right access as well. If there are more flavors of granularity or you use custom RBAC roles, there may need to be some experimentation on if a role can run this template successfully. Active Directory Sites and Services - ensure Active Directory Sites and Services is set up within your ADDS environment on-premises before provisioning the Azure replica domain controller environment. AD Sites provides a great solution for managing ADDS environments that have different geographical locations yet fall under the same domain. AD Sites are groupings of well-connected IP subnets that are used to efficiently replicate information among domain controllers. AD Sites help to achieve cost-efficiency and speed, along with letting enterprises exercise better control over the replication traffic and the entire authentication process. When there is more than one DC in the associated site that is capable of handling client logon, services, and directory searches, AD Sites locates the closest DC to perform those actions.



Once these pre-requisites are met and verified, you should be able to move forward with deployment of the ARM Template. In the next post, we will discuss architecture considerations for deploying replica domain controllers in Azure.