Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to deploy a new Active Directory forest.

Microsoft Scripting Guy, Ed Wilson, is here. Today, I thought I would provide another excerpt from my new Microsoft Press book: Windows PowerShell 3.0 Step by Step, which is available for pre-order now. Today’s excerpt is from the chapter on using Windows PowerShell to deploy Active Directory Domain Services.

Using the Active Directory module to deploy a new forest

Deploying Active Directory Domain Services is not a simple matter. There are prerequisites that must be met and multiple items that need to be configured.

One of the first things that might need to be accomplished is setting the script execution policy. Whereas the easiest way to do this is to set it via Group Policy, if you are configuring the first domain controller in the first domain in a new forest, you do not have that luxury. To set the script execution policy, use the Set-ExecutiionPolicy cmdlet and set it to something like remotesigned. The command is shown here.

Set-ExecutionPolicy remotesigned -force

Note The command must execute with Admin rights, but more than likely you are logged on as Administrator anyway as you are just beginning your configuration.

Some of the infrastructure prerequisites are listed here.

1. Ensure the server has the correct name.
2. Set a static IP address configuration.
3. Ensure DNS is deployed and configured.

In addition to infrastructure prerequisites, there are role-based prerequisites that need to be deployed. These role-based prerequisites are shown here.

1. Active Directory module for Windows PowerShell
2. Active Directory Administrative Center tools
3. AD DS snap-ins and command-line tools

Luckily, all of the above tools are installable via the ServerManager module and the Add-WindowsFeature cmdlet. In fact, from a Windows feature stand point, the RSAT-AD-Tools feature group gets everything you need here. The AddADPrereqs.ps1 script sets a static IP address by using the New-NetIPAddress cmdlet. To determine the interface index, the Get-NetAdapter cmdlet is used. This portion of the script is shown here.

#set static IP address
$ipaddress = “192.168.0.225”
$ipprefix = “24”
$ipgw = “192.168.0.1”
$ipdns = “192.168.0.225”
$ipif = (Get-NetAdapter).ifIndex
New-NetIPAddress -IPAddress $ipaddress -PrefixLength $ipprefix `
-InterfaceIndex $ipif -DefaultGateway $ipgw

After the new IP address is assigned, the Rename-Computer cmdlet assigns a new name to the computer. The Rename-Computer cmdlet has a restart parameter, but the AddADPrereqs.ps1 script holds off rebooting the script until the end, and therefore, the restart parameter is not used. This portion of the script is shown here.

#rename the computer
$newname = “dc8508”
Rename-Computer -NewName $newname –force

Now that the computer has received a new IP address and has been renamed, it is time to add the features. The first thing the script does is create a log file in a directory named poshlog. This log will hold details from adding the features. In addition, once the configuration completes, a Get-WindowsFeature command runs to gather the installed features. The result writes to a log file in the poshlog directory.

The Add-WindowsFeature cmdlet appears to accept an array for the features to install, but when attempting to add multiple features with a single call, the secondary features get trampled. Therefore, it is best to add tools one at a time. This portion of the script installs the RSAT Active Directory Domain Services tools. The command is shown here.

#install features
$featureLogPath = “c:\poshlog\featurelog.txt”
New-Item $featureLogPath -ItemType file -Force
$addsTools = “RSAT-AD-Tools”
Add-WindowsFeature $addsTools
Get-WindowsFeature | Where installed >>$featureLogPath

The last thing to accomplish here is to restart the computer. This is a simple call to the Restart-Computer cmdlet. This command is shown here.

#restart the computer
Restart-Computer

The complete AddAdPrereqs.ps1 script is shown here.

AddAdPrereqs.ps1
#set static IP address
$ipaddress = “192.168.0.225”
$ipprefix = “24”
$ipgw = “192.168.0.1”
$ipdns = “192.168.0.225”
$ipif = (Get-NetAdapter).ifIndex
New-NetIPAddress -IPAddress $ipaddress -PrefixLength $ipprefix `
-InterfaceIndex $ipif -DefaultGateway $ipgw
#rename the computer
$newname = “dc8508”
Rename-Computer -NewName $newname -force
#install features
$featureLogPath = “c:\poshlog\featurelog.txt”
New-Item $featureLogPath -ItemType file -Force
$addsTools = “RSAT-AD-Tools”
Add-WindowsFeature $addsTools
Get-WindowsFeature | Where installed >>$featureLogPath
#restart the computer
Restart-Computer

Once the computer reboots, log on and check things. Immediately, the Server Manager utility launches and provides feedback that the name change and the IP address change completed successfully. Server Manager appears in the image that follows.

The next thing to check is to verify that the roles and features were added properly. To do this, use the FeatureLog.txt log file that was created prior to the reboot. As seen in the following image, the feature and roles were added properly.

Once you have your computer renamed with a static IP address and the Active Directory Domain Services RSAT tools are installed, it is time to add the Active Directory Domain Services role, the DNS Server role, and the Group Policy management feature.

The first thing to do is to add the log path for the report at the end of the script. Once this is done, the script starts a job named addfeature. The use of a job allows the script to wait until the jobs complete prior to executing the next step of the script. Because the script adds the features in the background, no progress bars appear in the foreground. Each of the Add-WindowsFeature commands include all of the feature subfeatures and also include the management tools.This is a great way to ensure you obtain the bits your specific feature needs. You can always fine-tune it at a later time.

Once the job executes, the Wait-Job cmdlet pauses the script until the addfeature job completes. Then, it returns the completed job object. At this time, the final command is a Get-WindowsFeature cmdlet call that writes all installed features to the log file. The complete Add-ADFeatures.ps1 script is shown here.

Add-ADFeatures.ps1
#Install AD DS, DNS and GPMC
$featureLogPath = “c:\poshlog\featurelog.txt”
start-job -Name addFeature -ScriptBlock {
Add-WindowsFeature -Name “ad-domain-services” -IncludeAllSubFeature -IncludeManagementTools
Add-WindowsFeature -Name “dns” -IncludeAllSubFeature -IncludeManagementTools
Add-WindowsFeature -Name “gpmc” -IncludeAllSubFeature -IncludeManagementTools }
Wait-Job -Name addFeature
Get-WindowsFeature | Where installed >>$featureLogPath

Once the script finishes running, the featurelog text file can be examined. The log appears in the following image.

Now it is time to create the new forest, and add the server as the first domain controller in the newly created forest. The tool required appears in the ADDSDeployment module. The InstallNewForest.ps1 script is essentially one cmdlet—the Install-ADDSForest. The domain name and the netbios domain name appear as variables. When the script first runs, it prompts for an Active Directory password. This password becomes the Administrator password for the new domain. Following the installation, the function automatically reboots the computer to complete configuration. The complete InstallNewForest.ps1 script is shown here.

InstallNewForest.ps1
# Create New Forest, add Domain Controller
$domainname = “nwtraders.msft”
$netbiosName = “NWTRADERS”
Import-Module ADDSDeployment
Install-ADDSForest -CreateDnsDelegation:$false `
-DatabasePath “C:\Windows\NTDS” `
-DomainMode “Win2012” `
-DomainName $domainname `
-DomainNetbiosName $netbiosName `
-ForestMode “Win2012” `
-InstallDns:$true `
-LogPath “C:\Windows\NTDS” `
-NoRebootOnCompletion:$false `
-SysvolPath “C:\Windows\SYSVOL” `
-Force:$true

While the script is running, a progress bar appears. This is shown in the image here.

A quick check of the DNS Manager tool reveals that DNS is set up properly. The nwtraders.msft forward lookup zone is configured properly, and an A record, NS record, and even SOA record has been configured. This is shown in the image that follows.

Join me tomorrow when I will talk about more cool Windows PowerShell stuff.

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

Ed Wilson, Microsoft Scripting Guy