Building a Demo Active Directory: Part 1

Summary: Leverage Windows PowerShell in Windows Server 2012 to create a new Active Directory forest.

Hey, Scripting Guy! Question Hey, Scripting Guy!

I often have to put together demo environments, and I need a new empty Active Directory forest. Is there any way I can do this faster than by using the GUI…maybe with Windows PowerShell?


Hey, Scripting Guy! Answer Hello TM,

Honorary Scripting Guy, Sean Kearney here, filling in for our good friend, Ed.

I’ve also had to build demo environments—sometimes as a proof of concept for a client, and sometimes as an environment when I’m doing presentations.

In the old days, the way I had to do it was either by using the GUI or learn the DCPromo command. But in Windows Server 2012, life got so much better. The GUI and Windows PowerShell produce a far better team.

So here we have a blank server. The only thing that has been done is that the static IP address has been configured, and it has been named CONTOSO-DC.

Promoting this to a domain controller by using Windows PowerShell is actually pretty easy. I can do this with the GUI of course, but that would be about five or six pretty pictures, which I can replace with a few lines in Windows PowerShell.

Our first process is to enable the Active Directory Domain Services on the server. In Windows PowerShell, we can just execute this command:

Install-WindowsFeature AD-Domain-Services –IncludeManagementTools –IncludeAllSubFeature

Now I need to show you a really cool feature that was introduced in Windows Server 2012—which is why I love using it more than previous versions. Let’s run through the wizard and turn this into a full domain controller in a new domain called…well…CONTOSO.LOCAL.

After the domain services are added, you’ll see a yellow triangle with an exclamation point near the top of the new Server Manager. Click that, and you’ll see a Post Deployment Configuration option. Click Promote this server to a domain controller.

Image of menu

We’ll expand this task and select the hyperlink under Action.

Image of menu

From this point, we should see some familiar screens. We’re going to add the new forest called CONTOSO.LOCAL.

Image of menu

We’re also going to go cutting edge and choose our forest and domain functional level at Windows Server 2012. We’ve also populated our Directory Services Restore Mode password. And now the most insecure thing ever! Here’s the password: Secret321!

There is no previous domain, so of course we’ll be skipping by that screen. We’ll verify the NETBIOS name for our domain as shown in the following screen.

Image of menu

And verify our paths. (OK! You in the back! Stop yawning.)

Image of menu

And now the coolest screen of all in Windows Server 2012—the Review Options screen:

Image of menu

The reason for its coolness is the View Script button in the lower-right. Clicking it shows us the Windows PowerShell script that is about to run.

Image of command output

What we’re going to do now is cancel the wizard and paste this into our Windows PowerShell Console to see what it does. I’m looking, and I don’t see my password anywhere.

Image of command output

Aha! It’s prompting for the password. But I’ll bet there is a parameter we can supply the password to. Because the prompt is SafeModeAdministratorPassword, that would usually be the missing parameter.

I’m going to guess that we have to convert this password to a secure string because most commands from Microsoft won’t accept a clear text password directly. So we’ll drop the following command inside our parameter called -SafeModeAdministratorPassword:

(CONVERTTO-SecureString “Secret321!” –asplaintext –force)

So the really cool part with this prebuilt script is that we can easily modify it to have our variables at the top of the script to simply substitute into the command. With it designed in this way, a person with no administrative knowledge could actually spin up their own domain controller in a lab by only to knowing three key details:

  • New domain name
  • New NetBIOS name
  • Default password for Administrator




Now there is, of course, one additional piece to remember. When we promote to a domain controller in a new domain, it will grab the local Administrator password and set that as the default. To ensure our new domain accepts the password defined by the user in our script, we’ll need to reset the local Administrator password.

Now I could use the [ADSI] accelerator for this, but I love the fact I can use legacy solutions to this day in Windows PowerShell:

NET USER Administrator $Password

Now with all of this in place, we can have a nice little script to spin up a new test domain:






Import-module ADDSDeployment


# Add Domain Services to Server

INSTALL-WindowsFeature AD-Domain-Services –IncludeManagementTools -IncludeAllSubFeature


# Reset local Administrator password to

# One defined in Script

NET USER Administrator $Password


# Install our Shiny new Forest. It’s a good place for SQuirreLs to see *’s


Install-ADDSForest –SkipPreChecks –CreateDnsDelegation:$False `

–DatabasePath ‘C:\Windows\NTDS’ –DomainMode ‘Win2012’ `

–DomainName $DomainName –DomainNetbiosname $DomainNETBIOSName `

–ForestMode ‘Win2012’ –InstallDns:$True –Logpath ‘C:\Windows\NTDS’ `

–NoRebootOnCompletion:$True –SysvolPath ‘C:\Windows\SYSVOL’ `

–SafeModeAdministratorPassword (CONVERTTO-SecureString $Password –asplaintext –force) `



# Restart and Get ‘er done


Tomorrow we’ll expand on this domain controller, and we’ll work on prepopulating that environment without us doing all the typing!

I invite you to follow the Scripting Guys on Twitter and Facebook. If you have any questions, send email to, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Sean Kearney, Honorary Scripting Guy and Windows PowerShell MVP

Comments (3)

  1. Vandrey Trindade says:

    The "Import-module ADDSDeployment" command is before installing the "AD-Domain-Services" Windows Feature in the complete script.

    Need to be after install that feature.

Skip to main content