Windows Server 2012–Making Domain Controllers IS Easier–Server Manager gives birth to a Powershell Script!

Making a new Domain Controller actually wasn’t a difficult task.   It was a quick “Click, click click,type type type, click click, backspace click, enter,enter” in the GUI

Get what I’m saying?

Promoting roles was actually easy as was adding features.   REPEATEDLY doing those tasks was about as fun as chewing tinfoil while gargling gasoline and singing “Yankee Doodle Dandy” or ANY fun tune.

Until the clouds parted, Jeffrey Snover and the Powershell team’s voice boomed out “Powershell” and Windows Server 2012 began to appear.

You see something wonderful has begun to form in the Development of this new system.  Sample scripts in the Server environment!

Running through the Wizard of adding the Active Directory Domain Services  is slightly different.   The Server Manager completely different than before but oh so much more powerful.  I select a Server or VHD and add the required Active Directory Domain Services role to it.



Then of course begin the promotion to a Domain Controller.   But once you play and began adding it as a Domain Controller the magic starts to flow free


Because at the end of it all – **** DING **** DING **** DING ****



Choosing “View Script” will produce the EXACT Powershell script being used to turn that computer in a Domain Controller.

Below (without anything done on my part) is the exact script Windows Server 2012 generated to create a new Domain Controller in my environment

# Windows PowerShell script for AD DS Deployment

Import-Module ADDSDeployment
Install-ADDSDomainController `
-DoNotConfigureGlobalCatalog:$false `
-CreateDNSDelegation:$false `
-Credential (Get-Credential) `
-CriticalReplicationOnly:$false `
-DatabasePath "C:WindowsNTDS" `
-DomainName "energized.local" `
-InstallDNS:$true `
-LogPath "C:WindowsNTDS" `
-RebootOnCompletion:$true `
-SiteName "Default-First-Site-Name" `
-SYSVOLPath "C:WindowsSYSVOL" `

Now the best part, think about it.   If you like the GUI and are happy with it.  Stay with it and be as productive as you love.   But the best part of the Sample script is when the boss in the organization screams.  “I need a new DC STAT!” you can take this script and just RUN it on the box.

Oh man, the future is getting Cool


The Energized Tech

Windows Server 2012– Easily learn cmdlets to manage Active Directory

I have one phrase to utter to Microsoft.  I know this is Beta but PLEASE oh PLEEEEEEAAAAASSSSEEEEE DON’T (DON’T DON’T DON’T!!!!) remove this feature I found.

In Server 2008R2 Microsoft introduced possibly the easiest way for a Help Desk or an Administrator to manage the common day to day functions in Active Directory.   It’s called the Active Directory Administrative Center.  You’ll have seen it and heard it was built in Powershell.

In Windows Server 2012 the Powers that be kicked this tool into OVERDRIVE. 

They attached a little piece that I initially overlooked in the Active Directory Administrative Center.    A small but incredibly Powerful change for the new Administrator.

They let us see the history of Powershell cmdlets PRODUCED by the Administrative Center.  

Let me state just how unbelievably over the top, Jump up and down, Flip for Joy, Scream to the SKIES amazing this is.  This is the BEST feature they could have introduced.

Let’s take a quick look!


So here is the current version of the “Active Directory Administrative Center”.   Functionally it is identical to the previous version.   I can create a user with the rich interface as I had last time.



With this interface all of the details an Administrator needs are placed directly in front of them in an “At a Glance Scenario” making viewing and editing the user easier

So we click “OK” and create a user and all seems normal… Or does it?

Look right near the bottom of the GUI interface and see if you spot what I almost overlooked.   “Windows Powershell History”.  The BIGGEST and BEST CHANGE offered to an Administrator.


Simply click on “Windows Powershell History” to see the EXACT Cmdlets that were used to produce you action in the GUI!  No more muss and fuss!


You can copy the contents by right clicking and selecting Copy to copy a single line and paste it elsewhere.

You can even do a CTRL-A and CTRL-C to copy the content used directly into a NOTEPAD.EXE instance or better yet, paste it straight to the Powershell ISE for editing and debugging!

You can even (if you choose) have it clear off the history each time so you can see the Cmdlets being used to generate other functions of Active Directory.   How about just adding a user to a group or unlocking a user?  

The guesswork of using the Active Directory modules is now gone!  Just clear the history, execute the action in the “Active Directory Administrative Center”, check the Windows Powershell History and grab a copy of what you just did.

Now this is where Windows Server 2012 really just…well it just KICKS ASS!  I can use the GUI the way I will be comfortable, but if I need to learn to automate it, the very commands being used are place right square in FRONT OF ME!

The Future is looking pretty DAMN GREAT with Windows Server 2012 and Powershell. 


The Energized Tech

Three ways to pass credentials in a Powershell Script

I thought I’d pull together something that might prove interestingly useful for those new to Powershell.   Passing credentials.


Here’s your typical scenario.   You have a script that requires credentials internally.  So to provide those credentials you would do something like

$MyCredentials=GET-CREDENTIAL –credential “CONTOSOUsername”

and you of course see a box like this normally on the screen


Then you would type in the password and life would go on about it’s Merry Little Way…

Build from clear text in a Script

The other method you could leverage would be to embed the credentials in a Powershell script like this.



$SecurePassword=Convertto-SecureString –String $MyClearTextPassword –AsPlainText –force

$MyCredentials=New-object System.Management.Automation.PSCredential $MyUsernameDomain,$SecurePassword

This second method is of course very insecure as the credentials are stored directly and viewable within the script.   But the advantage to this is the ability to work with a legacy setup like a BAT, CMD or vbScript as the calling system.  

You can pass the credentials to a Powershell and have it invoke the Cmdlets (like those in Exchange 2007) with the same flow and no modification to the source script.

Store Credentials in an XML file

Using the EXPORT-CLIXML and IMPORT-CLIXML gives us a better option.   We can store away the entire System.Management.Automation.PSCredential Object as an XML file.   It’s actually VERY easy to use.

Create your credentials in any of the normal manners.   Let’s use the Interactive one as an example

Instead of just doing this for Credentials and keying in the password

$MyCredentials=GET-CREDENTIAL –Credential “CONTOSOUsername”

You can pipe the output EXPORT-CLIXML

$MyCredentials=GET-CREDENTIAL –Credential “CONTOSOUsername” | EXPORT-CLIXML C:ScriptfolderSecureCredentials.xml

Now if you ever need to re-use those credentials it’s just a simple matter of running an IMPORT-CLIXML and bringing the data back in as an Object.

$MyCredentials=IMPORT-CLIXML C:ScriptfolderSecureCredentials.xml

Now wherever this XML file exists SHOULD be a secure location.  That goes without saying.   But the beautiful part here is if you have a series of systems or scripts that may need to have those credentials reset, you’re just into rebuilding a single XML file and just having the scripts use an IMPORT-CLIXML file to bring in the data.

Remember Powershell is just another technology to get you home earlier.   Leverage these credential methods in your environment in whatever suits your organization best.

Remember, the Power of Shell is in YOU

The Energized Tech