Virtualisation | Cloud | Strategy

Deploy a VM add to an existing AD Domain and Network in IaaS with Azure ARM

The story so far.

Tools installed and scripts configured! In the post we ran through the step by step creation of an IaaS AD controller, deployed to Azure using ARM and DSC.  One of the elements that I didn’t focus in on was the heavy that was done during the IaaS AD controller deployment to create and configure the Virtual Network.

If you care to revisit that code for a moment and delve into the resources section of ‘WindowsVirtualmachine.json‘. You will very quickly see that in the same way the ‘VirtualMachine‘, ‘PublicIPAddress‘ and ‘NetworkInterface‘ resources have been created a resource exists for ‘VirtualNetwork‘.

The resource references the variables to configure the virtual networks and subnets, presented using CIDR notation.

By default this network is going to be created to use Azure domain name services.  The problem with this is that Azure DNS, has no idea about your random IaaS domain name – nor does it want to know about it.  Therefore before proceeding it is worth re-configuring the created network to point toward the DNS services on the freshly deployed domain controller.

Deploy the next IaaS VM

Start with a Blank Azure Resource Group Project.  This is going to provide the three files that are needed for a successful deployment, all be it blank. ‘AzureDeploy.json’, ‘AzureDeployParameters.json’ and ‘Deploy-AzureResourceGroup.ps1’ – our template files and the script to deploy against them.

Cut and paste the following into ‘AzureDeploy.json’;

Ok.  Lets explain a little whats going on in the JSON.


Parameters are by definition “a numerical or other measurable factor forming one of a set that defines a system or sets the conditions of its operation“.  In this context we can think of parameters here being the non changing configuration definitions that define the environment being deployed into.

So the parameters that are captured above work for the environment I’m deploying into; be that Development, Testing or Production.  Or in this case Lab.

You’ll notice this parameter list is extended from the default list we worked with previously.  This should all be fairly initiative, if not there is a description included with each parameter.


Variables are where you construct values that can be used through a template. So if we continue the train of thinking from above, this is where we are going to store elements that might change from deployment to deployment within the same environment.  There are no definitions within the template here, but again these should be intuitive enough.


In simple terms (probably over simplifying it) resources are where the parameters and variables are applied.

Most of these resources will be familiar.  Running from top to bottom we have ‘Microsoft.Network/publicIPAddresses‘, ‘Microsoft.Storage/storageAccounts‘, ‘Microsoft.Network/networkInterfaces‘ and ‘Microsoft.Compute/virtualMachines‘.  Each of these resources was discussed in greater or lesser detail in a previous post.

The section added here as part of ‘Microsoft.Compute/virtualMachines/extensions‘ is ‘JsonADDomainExtension‘. This extension can take all the required parameters above to join the VM to an AD domain and then reboot it post join operation. which as luck would have it is exactly what we are trying to achieve here.


With the ‘AzureDeploy.json‘ template complete the parameters file needs to be addressed so that the parameters in the deploy file have values.

The syntax and pattern here should be familiar now.  Take the parameter name created in the ‘AzureDeploy.json‘ and feed in the required value.  All but one of the values within this file are free text the only exception being ‘domainJoinOptions‘ which is configured here with a value of 3.  You can read more about these options on the MSDN website for the NetJoinDomain function.

To keep the information on this page Option 3 refers to;

‘lpAccountOU [in]

Optionally specifies the pointer to a constant null-terminated character string that contains the RFC 1779 format name of the organisational unit (OU) for the computer account. If you specify this parameter, the string must contain a full path, for example, OU=testOU,DC=domain,DC=Domain,DC=com. Otherwise, this parameter must be NULL.’


For the purposes of this demonstration there was no further customisation of the deployed VMs outside of the domain join handled by the extension.  Therefore no requirement for DSC.

Validation and Completion

As before the project can be validated and deployed from within Visual Studio.

Next up how to deploy multiple machines and join them to a domain.