Quick and easy Active Directory test lab using PowerShell DSC and AzureRM

That Active Directory Test Lab You Have Always Wanted

As a Microsoft Premier Field Engineer I have visited countless customers to assess and assist their Active Directory environment. Sadly, the majority of those customers do not have an Active Directory test environment. Today I am going to show you how to quickly deploy and destroy your own Active Directory test lab using Azure Resource Manager and PowerShell.

Build 10 new AD labs a day if you want. It is crazy easy and crazy fast using this script. Imagine going to your morning status meeting, and then coming back to an Active Directory domain ready for you to do your worst. When you are done, a single line of PowerShell erases the entire environment.

PowerShell and DevOps Global Summit 2016

Watch the demo and explanation of this code from the 2016 PowerShell Summit.

Quickly? Azure? In the same sentence?

Wait! Keep reading! I promise this is painless. I have done all the heavy lifting for you. All you need is an Azure subscription.

This solution is a mash up of the following technologies:

  • Azure
  • Azure DSC extension
  • PowerShell DSC
  • Azure Resource Manager (ARM) templates

Gone are the days of stumbling through the Azure interface to provision network, storage, compute, and sanity. Now using ARM templates you can spin up a complete environment with a couple lines of PowerShell. Yes, it can be that easy.

What’s in the secret sauce?

I started out by snagging a copy of a free AzureRM template for a domain controller. There is a large repository of sample templates on GitHub. Check it out.

I wanted to build my own DSC configuration for the domain, so I started with the included DSC configuration and added my own twist using a newer version of the xActiveDirectory DSC resource module (available on PowerShell Gallery and GitHub).

I watched Trevor Sullivan’s presentation on deploying AzureRM templates with PowerShell.

I asked my PFE buddy Ben Wilkinson for a head start with the calling code. He showed me how to get the Azure cmdlets installed and launch the template build.

I read a bunch of blog posts and documentation. You know how it is learning something new. You bang your head against the docs and your keyboard until you get a breakthrough. Here are some links that helped me:


Then I hacked at it for a day until it worked.  :–)>  Now you get the benefit of a fully-functional solution.

After you install the Azure cmdlets you have just three commands to deploy your lab, and then one to blow it away when you are done:

  • Login-AzureRmAccount
  • New-AzureRmResourceGroup
  • New-AzureRmResourceGroupDeployment
  • Remove-AzureRmResourceGroup

Anyone working with AzureRM templates will probably tell you to use Visual Studio to create and edit them. And that is probably the easier way. However, I know many of you as infrastructure ops are not comfortable with Visual Studio dev tools. I wanted to prove that it can be done without the overhead of a massive Visual Studio install and license. I did some of my editing in the free, light-weight editor Visual Studio Code, but you could just as easily use Notepad or the PowerShell ISE to edit the json file.

How do I make my AD lab?

Usually my blog posts go into great detail and documentation for each script that I publish. In this case you can watch the video above for all the details. You will need WMF 5.0 installed before you get started.

I put the whole thing on GitHub for you to learn from. All you have to do is download CallingScript.ps1, edit the naming strings for uniqueness, and then run it a few lines at a time. The comments in the script will guide you. In 30 minutes you will have a populated AD test lab in Azure that you can connect to with RDP (remote desktop protocol). You could even copy and paste more scripts into the VM for further configuration or testing. Below is a screenshot of the finished domain controller.

RDP screenshot from the mobile client just for fun.

When you have more time, download all the files from my GitHub and dive into the DSC configuration and azuredeploy.json parts. Using the techniques I demonstrate in this code, you can tweak the domain sample data however you like. Then you can host your own version of these files on GitHub or Azure storage. You could even take just the DSC piece to build your own test lab in a local VM.

One parting piece of advice…

If you do not destroy the Azure resource group at the end of the day, then be sure to shutdown and deprovision the VMs in Azure. You pay for them as long as they are running. You can do this via the Azure portal or script. Consider yourself warned. Enjoy!

Comments (5)

  1. JJ says:

    Great job Ashley, I’m working on something similar to build also the AD FS environment, this will speed up my work! lol to this :-)> is it the happy Goatee face?

  2. Steve Burkett says:

    Managed to get this one up and running fairly easily, thanks Ashley! Is there a way to validate the CreateADDomainWithData.ps1 content and syntax without having to go ahead and deploy? Bit of a pain to wait 30 minutes for it to choke because you had a extraneous squiggly bracket in there somewhere…

    1. Hi Steve,
      To test I actually run the configuration against a VM in my local lab first. Once it is working there, then I put the code up on GitHub.

  3. computingbee says:

    Can do I add additional Domain Controllers once the first DC is deployed without modifying these scripts?

    How do I add child domains in the forest without modifying scripts?

    1. Hi ComputingBee,
      You could deploy additional DCs manually or modify the ARM template to include multiples (including child domains).
      See the link for additional ARM templates on GitHub.

Skip to main content