Azure, Azure Resource Manager, Azure Stack
comments 8

Building Azure Resource Manager Templates – Using Domain Join Extension

The scenario that we used to understand and build ARM templates contained a domain controller VM along with one or more VMs that joined the domain service hosted by the DC VM.

demo

To make sure the VMs join the domain, we used PowerShell DSC configuration. One of the biggest quirks, at least what I faced, with DSC extension with ARM templates is that it takes little longer to complete. For example, the complete scenario deployment took almost 48 minutes to deploy. I am not making up that number. Here is the proof.

dsc-deploy-time

Now, 48 minutes may not sound that worse but imagine deploying tens of VMs that need to join the domain using the DSC configuration as we saw in the earlier example in this series.

This is where the new JsonADDomainExtension helps! Instead of using DSC configuration to add VMs to a AD domain, we will now use this VM extension. Within the earlier template that deployed this scenario, we will remove the domainJoin resource definition and replace that with JsonADDomainExtension.

Here is how that new resource definition looks.

In this extension settings, I am re-using a few parameters such as adDomainName, adminUserName, and adminPassword. I added a new parameter called OUPath. This specifies the organization unit for the VM computer account and it is not mandatory to specify this. Let’s take a quick look at the properties of this resource.

Property Name Description
Name Name of the Active Directory Domain to join
User Administrator account name to authenticate
Restart Specifies if the VM should restart after domain join. Possible values: true or false
Options Domain join options. Default option is 3.

Refer to NetJoin options on MSDN.

OUPath Organization Unit for the VM computer account. It is not mandatory to specify this value.

Example specification: OU=testOU; DC=domain; DC=Domain; DC=com

The complete template that uses this new extension is rather lengthy. So, click on the below Deploy to Azure button to deploy this template.

As compared to the DSC way of joining a domain, the new domain join extension method took only 31 minutes. This is it for now! Try this template and let me know what you think.

Filed under: Azure, Azure Resource Manager, Azure Stack

by

Ravikanth is a principal engineer and the lead architect for Microsoft and VMware virtualized and hybrid cloud solutions within the Infrastructure Solutions Group at Dell EMC. He is a multi-year recipient of Microsoft Most Valuable Professional (MVP) award in Windows PowerShell (CDM) and Microsoft Azure. Ravikanth is the author of Windows PowerShell Desired State Configuration Revealed (Apress) and leads Bangalore PowerShell and Bangalore IT Pro user groups. He can be seen speaking regularly at local user group events and conferences in India and abroad.

  • Neither of these seem acceptable to me. 30 minutes to join a domain? SCVMM deployments, SCCM OSD task sequences, MDT, these all take no longer than the reboot… That’s seconds in a VM, minutes on metal.

    IMO I’d not settle for either: these times are unacceptable.

  • @Justin, Not sure if I gave you that impression that this is only domain join. However, this is a complete deployment with storage account, vnet, vnics, load balancer, load balancer rules, AD VM creation, AD creation, and three VM creation and joining those to the AD Domain.

  • Not sure if I gave you that impression that this is only domain join. However, this is a complete deployment with storage account, vnet, vnics, load balancer, load balancer rules, AD VM creation, AD creation, and three VM creation and joining those to the AD Domain.

  • That’s certainly a better time then, I thought you were only measuring domain join time 🙂

    I also find it interesting that the extra minutes were for wmf5 install. For security reasons that might be worth the extra couple minutes (IIRC wmf4 has a security bug)

  • Agree! depends on what you need WMF 5.0 for. Security related fixes are a must!

  • Pingback: Luper's Learnings - Azure Technical Community for Partners (March 2016) - Luper’s Learnings - Site Home - TechNet Blogs()

  • Oliver

    I will have to try this! I am running into issues passing credentials into a DSC script from my JSON templates – keep getting username/pass is incorrect, but I am passing the same credentials as everything else. I had the same issues with the xWaitforADDomain module, so I am probably doing something wrong there, but I can’t for the life of me figure out what.

  • Oliver

    Now that I think of it, what I am doing is using a KeyVault secret for my password, that’s linked via the parameters file, and the main template is calling that and supposedly passing that to the DSC template. Do you know if that should work or not? I would think it would have something to do with what has access to the keyvault – right now it’s just my azure account, which is doing the deployment from the template, but if the DSC script is run as another account that might pose problems. Do you know what account a DSC extension would run as? If you do know, please shoot me an email! I would really appreciate it.