Part I : Building an AD Domain Testlab with DSC


I often rebuild my testlab from the ground up, and have gotten to the point that setting up my Domain, DHCP, DNS and the like all is a very quick and easy task., But it wasn’t always this way, in fact, I used to spend hours trying just to get DHCP and Domain Controller working.

This is post one of a projected three part series in which we’ll use the magical power of infrastructure as code and embrace the DevOps lifestyle using PowerShell Desired State Configuration. In post one, we’ll start easily and just change the name of our machine and the workgroup, then configure a local admin account in the same doc.

In part II – we’ll configure some Windows Roles, and make this system into a Domain Controller.
In part III – we’ll pull out all of the stops and ensure that our DSC configuration handles DHCP and DNS as well, giving us a one-click DSC Testlab.

System Prerequisites

Using Hyper-V or VMware, make a VM with Two NICs, one connected to an external, and one an internal virtual switch, for ease, make it a Server 2012 R2 VM.

Then we’ll apply WMF 5.0 to our server, found here.

Kick that bad boy off, and let ‘er reboot. Uh..let him rebot. What I’m trying to say is, regardless of the sex of your system, reboot it.



We’ll need to provide the DSC resources we need to install, so the next step is to download the xServer script module, provided here.

Now, download and extract this to the following path : $env:ProgramFilesWindowsPowerShellModules folder

Making our first configuration

In the ISE, we can run the Get-DSCResource cmdlet to see if PowerShell detects our new xResource. If you don’t see the following, stop now and make sure you downloaded the xComputerManagement resource before proceeding.


Now deeply under the covers, we can see that making a PowerShell configuration is really quite similar to creating a Function. All we’ve got to do is use the Configuration Keyword in a format that should look quite familiar.

Configuration TestLab {
Import-DscResource -Module xComputerManagement

Node $nodeName {


When we run this, we’ll end up with a compiled Configuration in memory, just like we would when we run a Function. We can call it by typing TestLab and it will accept a parameter of -NodeName, which will be the computer to apply to configuration too.

We’ll compile our Configuration, then execute it, which makes a .mof configuration. Finally, we run Start-DSCConfiguration -Path .Pathtoconfiguration.mof to apply the changes to our system.

Adding Configuration Items to our Configuration

So far, we’ve got the skeleton of a config but it isn’t making any changes to our system.

We’ll now rely on one of the cool features of the ISE is Intellisense, I.e. super mega auto-complete. Right underneath Node $nodename, let’s start by typing xComputer then hitting Control+Space to pop-up Intellisense and see which configuration options we can use from this resource.


We see that we can configure a lot of things:

  • Credential : If you need special rights to implement this change
  • DependsOn : We’ll use this in Part II to order the application of our changes
  • DomainName : if we want to add to a new Domain, we’d use this configuration
  • UnjoinCredential : if we need special rights to pull our machine off of an existing domain
  • WorkGroupName: to specify a new workgroup, you specify this setting

So, for part I of our DSC walk-through, we only want to change the MachineName and the WorkGroupName, lets drop these values in under $nodeName.  I want to name my new system DSCDC01, and my new WorkGroup to be called TestLab

xComputer NewNameAndWorkgroup
            Name          = DSCDC01
            WorkGroupName = TestLab

The Next step…wait, That’s all!

Just to reiterate, this is our total script, making some small changes to add parameter support.

configuration TestLab
        [string[]]$NodeName ='localhost',

    #Import the required DSC Resources
    Import-DscResource -Module xComputerManagement 

    Node $NodeName
        xComputer NewNameAndWorkgroup
            Name          = $MachineName
            WorkGroupName = $WorkGroupName

To implement this, all that we have to do is go to our new DSC client, and execute the code, just like we would with a Function. We then run it like we do a cmdlet and provide some params.

TestLab -MachineName DSCDC01 -WorkGroupName TESTLAB -Verbose

That will create an output file in .mof format

    Directory: C:TestlabDCTestlabDCxComputer

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        3/19/2015   2:23 PM           1670 localhost.mof

The final step here is to apply the configuration to our machine and see what happens.

Start-DscConfiguration -ComputerName localhost -Path .xComputer `
 -Wait -Force -Verbose

And watch the beautiful colors scroll by


Our log output says that a reboot is needed to kick things off, but we can take a look at System Management to see what the setting will be after a reboot.


That’s it!

Now, join us in our next post on this series to see how we add a few extra paragraphs to make this into a Domain Controller and get our TestLab really going.

7 thoughts on “Part I : Building an AD Domain Testlab with DSC

  1. theguern June 12, 2015 / 10:42 pm

    You say, “Using Hyper-V or VMware, make a VM with …”.
    Can I use Azure, instead?


    • FoxDeploy June 13, 2015 / 7:55 am

      Sure you can! But keep in mind that Azure has its own DHCP and DNS mechanisms, and it might not ‘just work’ as readily.


      • theguern June 14, 2015 / 9:51 am

        Thanks, Stephen .
        I’ve been trying to follow examples of PowerShell remoting, things like creating a dev test AzureVM web server [] for autodeploying a web site, etc. I can create an Azure server with PowerShell, but I can’t seem to get the examples to work and I think it is because I don’t have a domain server for [WebTest01] to join and the #PowerShell client on my laptop is not trusted or something. I can’t get my servers to play nicely with each other, I think because they are not joined to the same domain.
        I know there is something missing in my understanding of #Azure, #PowerShell remoting and Domain Controllers and I am hoping that this series is going to be the thing that finally brings it all together for me. My plan is to follow your instructions to create an AzureVM domain controller, then all my test VMs (as well as my laptop) will be able join the domain and all my problems will be solved.
        Can you tell if I am barking up the right tree?


        • FoxDeploy June 14, 2015 / 9:55 am

          So Azure offers a dns element which helps with name resolution form on prem to the cloud. That being said, if your whole env is going to live in Azure and not span back to another datacenter somewhere, this dsc approach should work.

          I’d recommend you hop over to part 4 in the series, where the completed dsc script lives now. When you hit a problem, lemme know and I’ll try to help!


        • FoxDeploy June 14, 2015 / 10:10 am

          Ahh I understand your problem! You need to go to both the remote and your pc and add the other computer as a trusted host. If you Google ‘non domain powershell remoting’ you’ll see how to do it.


Have a code issue? Share your code by going to and pasting your code there, then post the link here!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.