A lot has happened in the Azure world since I last published this short series on deploying an Active Directory forest with ARM templates:
- Part 1: Using the template
- Part 2: Understanding the template structure
- Part 3: Visualizing the template
Since that time we have had a major advance in the Virtual Machine world with the addition of managed disks. These disk do not require you to manage a storage account, which is especially important in large deployments. The storage account is still there, but Azure takes care of the configuration.
Another advance, related to ARM templates, is the introduction of the "condition" property. This small addition greatly reduces the complexity of templates that allow the user to choose between various configurations. Previously, you had to add one or two extra templates for each choice, and if these choices depend on each other, the number of files increases even faster.
My older template to create a forest with two domains would benefit from both of these developments, so I decided to rewrite them, and at the same time, try to get them published with the Azure QuickStart templates. These QuickStart templates are hosted on GitHub, and to add or change something you need to fork the entire repository. After making your changes, you submit a pull request. In the spirit of DevOps, this pull request immediately triggers an integration test using the custom Travis agent: a new temporary deployment is created using your submitted template, and you need to fix or explain any deployment failures. A maintainer of the repo will look at it and discuss with you, and if you are found worthy your addition is accepted.
Here is one way to deploy the template. You will need an Azure subscription for this to work.
- Browse to: https://azure.microsoft.com/en-us/resources/templates
- In the search box, type: forest child
- Select the template (should be only one hit): Create new Active Directory forest with optional subdomain
- Click "Deploy to Azure"
- This will redirect you to the Azure portal, and displays template parameter entry as follows.
These are the main parameters, allowing you create various configurations:
- single domain, one DC.
- single domain, two DCs.
- root and child domain, one DC each
- root and child domain, two DCs each.
This flexibility is enabled by the condition property. Without it, I would have to maintain four template sets. And now, just one. To see how this works, check out the azuredeploy.json file on GitHub and search for "condition".
Besides the forest, the template creates a new VNET and you get to pick its IP range, for instance to make it play nice with other VNETs through peering. Important for corporate deployments: be aware that there are public IP addresses for the VMs.
You can also specify VM names as you like. Each domain is deployed in an availability set. You get a choice of operating system, anything from Windows Server 2012 R1 and higher. Each VMs gets two managed disks, one for the OS, and a second one for AD data. You do not get a free choice of VM size. I restricted the list to the sizes that make sense for a DC in a test lab. Smaller VMs than the ones in the list do not deploy the forest reliably, and larger ones are simply overkill.
If your needs differ, just fork it on GitHub and roll your own!