Deploying Windows Server 2012 and Windows Server 2012 R2 Domain Controllers
- 4/24/2014
- Before you begin
- Lesson 1: Preparing for deploying domain controllers
- Lesson 2: Deploying domain controllers using Server Manager
- Lesson 3: Deploying domain controllers using Windows PowerShell
- Practice exercises
- Suggested practice exercises
- Answers
Lesson 3: Deploying domain controllers using Windows PowerShell
Windows PowerShell provides a way to automate the deployment of Windows Server 2012 and Windows Server 2012 R2 domain controllers. This approach to domain controller deployment can be particularly useful in large enterprise environments, data centers, and cloud-computing scenarios. This lesson demonstrates how to use Windows PowerShell to deploy domain controllers in both new and existing forests.
Preparing for domain controller deployment
Like deploying domain controllers using Server Manager as described in the previous lesson, the steps for preparing to deploy Windows Server 2012 and Windows Server 2012 R2 domain controllers using Windows PowerShell differ depending on the scenario.
Preparing for deploying the first domain controller in a new forest
To deploy the first Windows Server 2012 or Windows Server 2012 R2 domain controller in a new forest, you can run Windows PowerShell commands directly on the server by either logging on locally to the server or connecting to it using Remote Desktop. Another option is to use Windows PowerShell remoting, which enables you to run Windows PowerShell commands on one or more remote computers simultaneously by using the WS-Management protocol.
As explained previously in Chapter 3, “Server remote management,” the remote management capability is enabled by default on Windows Server 2012 and Windows Server 2012 R2 to make it easy to remotely manage servers using both Server Manager and Windows PowerShell. For more information, see the section “Configuring remote management” in Lesson 4 of Chapter 3.
The difficulty, however, is that Windows PowerShell remoting is primarily intended for remotely managing domain-joined computers, and if you are preparing to deploy the first domain controller in a new forest there is no domain to join! In other words, the remote server that will be promoted to a domain controller is initially in a workgroup, not a domain. In addition, the local computer from which you will be performing the deployment might also be in a workgroup.
The solution is to prepare your environment by enabling the two stand-alone computers to talk to each other using the WS-Management protocol. If the computer from which you are performing the deployment is also running Windows Server 2012 or Windows Server 2012 R2, you just need to add the name of the remote server to the TrustedHosts list in the local computer’s WinRM configuration. Doing this enables the local computer to connect to the remote server using NTLM as the authentication mechanism instead of Kerberos, which is used in domain-based environments.
To illustrate how to do this, consider a scenario in which you have two stand-alone servers running Windows Server 2012 or Windows Server 2012 R2: a local server named SEA-HOST-2 and a remote server named SEA-SRV-1. You want to use the Get-WindowsFeature cmdlet on the local server to display a list of installed and available roles and features on the remote server, but when you try to do this on the local server, you get the error indicated in the following code:
PS C:\> Get-WindowsFeature -ComputerName SEA-SRV-1 -Credential SEA-SRV-1\Administrator Get-WindowsFeature : The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config. At line:1 char:1 + Get-WindowsFeature -ComputerName SEA-SRV-1 -Credential SEA-SRV-1\Administrator + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : DeviceError: (Microsoft.Manag...rDetailsHandle):CimException) [Get-WindowsFeature], Exception + FullyQualifiedErrorId : UnSupportedTargetDevice, Microsoft.Windows.ServerManager.Commands.GetWindowsFeatureCommand
The error occurs because the remote server SEA-SRV-1 is not domain-joined and therefore must be added to the TrustedHosts list on the local server before you can manage the remote server from the local server. You can use the Set-Item cmdlet to do this:
PS C:\> Set-Item wsman:\localhost\Client\TrustedHosts -Value SEA-SRV-1 WinRM Security Configuration. This command modifies the TrustedHosts list for the WinRM client. The computers in the TrustedHosts list might not be authenticated. The client might send credential information to these computers. Are you sure that you want to modify this list? [Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y
You can then use the Get-Item cmdlet to verify the result:
PS C:\> Get-Item wsman:\\localhost\Client\TrustedHosts WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Client Type Name SourceOfValue Value ---- ---- ------------- ----- System.String TrustedHosts SEA-SRV-1
Running the Get-WindowsFeature cmdlet now no longer throws an error:
PS C:\> Get-WindowsFeature -ComputerName SEA-SRV-1 -Credential SEA-SRV-1\Administrator
Display Name Name Install State
------------ ---- -------------
[ ] Active Directory Certificate Services AD-Certificate Available
[ ] Certification Authority ADCS-Cert-Authority Available
[ ] Certificate Enrollment Policy Web Service ADCS-Enroll-Web-Pol Available
...
Preparing for deploying additional domain controllers in the new forest
Deploying additional domain controllers in a new forest is easier than deploying the first domain controller because you already have a domain environment, which means Windows PowerShell remoting will work without any further configuration. By running your Windows PowerShell commands from an existing Windows Server 2012 or Windows Server 2012 R2 domain controller in your forest or from a Windows 8 or Windows 8.1 client computer on which the appropriate version of RSAT has been installed, you are able to deploy additional domain controllers to existing domains, install new child domains, and install new tree domains as long as you have the appropriate credentials for the task you are going to perform.
Preparing for deploying domain controllers in an existing forest
You can also deploy Windows Server 2012 or Windows Server 2012 R2 domain controllers in a forest whose domain controllers are running an earlier version of Windows Server by using Windows PowerShell as follows:
- Install Windows Server 2012 or Windows Server 2012 R2 on a server and join the server to an existing domain.
Use the Install-WindowsFeature cmdlet to install the AD DS role with its role-management tools as follows:
Install-WindowsFeature -name AD-Domain-Services –IncludeManagementTools
- Run commands from the ADDSDeployment module on the server to remotely install AD DS on other domain-joined servers running Windows Server 2012 or Windows Server 2012 R2.
Using Windows PowerShell to deploy domain controllers
The Windows PowerShell cmdlets for installing a forest, installing domains, deploying domain controllers, and performing similar deployment tasks are found in the ADDSDeployment module. This Windows PowerShell module is installed by default when you add the AD DS role with its role-management tools on a server, regardless of whether the server has been promoted to a domain controller. To see a list of the available cmdlets in this module, use the Get-Command cmdlet as follows:
PS C:\> Get-Command -Module ADDSDeployment CommandType Name ModuleName ----------- ---- ---------- Cmdlet Add-ADDSReadOnlyDomainControllerAccount ADDSDeployment Cmdlet Install-ADDSDomain ADDSDeployment Cmdlet Install-ADDSDomainController ADDSDeployment Cmdlet Install-ADDSForest ADDSDeployment Cmdlet Test-ADDSDomainControllerInstallation ADDSDeployment Cmdlet Test-ADDSDomainControllerUninstallation ADDSDeployment Cmdlet Test-ADDSDomainInstallation ADDSDeployment Cmdlet Test-ADDSForestInstallation ADDSDeployment Cmdlet Test-ADDSReadOnlyDomainControllerAccountCreation ADDSDeployment Cmdlet Uninstall-ADDSDomainController ADDSDeployment
Verifying prerequisites
You can use the Test-ADDS* cmdlets to run a prerequisites check before attempting to install a new forest, install a new domain, deploy a writeable domain controller, or deploy an RODC in your environment. The output of this command will help you determine whether your environment is ready for the operation you intend to perform or whether additional configuration might be required. The example here shows some output from running the Test-ADDSForestInstallation cmdlet on a stand-alone server running Windows Server 2012 or Windows Server 2012 R2 to determine whether the server satisfies the prerequisites for becoming the first domain controller of the forest root domain of a new forest:
PS C:\> Test-ADDSForestInstallation -DomainName corp.adatum.com SafeModeAdministratorPassword: ******** Confirm SafeModeAdministratorPassword: ******** WARNING: Windows Server 2012 Release Candidate domain controllers have a default for the security setting named "Allow cryptography algorithms compatible with Windows NT 4.0" that prevents weaker cryptography algorithms when establishing security channel sessions. For more information about this setting, see Knowledge Base article 942564 (http://go.microsoft.com/fwlink/?LinkId=104751). WARNING: This computer has at least one physical network adapter that does not have static IP address(es) assigned to its IP Properties. If both IPv4 and IPv6 are enabled for a network adapter, both IPv4 and IPv6 static IP addresses should be assigned to both IPv4 and IPv6 Properties of the physical network adapter. Such static IP address(es) assignment should be done to all the physical network adapters for reliable Domain Name System (DNS) operation. WARNING: A delegation for this DNS server cannot be created because the authoritative parent zone cannot be found or it does not run Windows DNS server. If you are integrating with an existing DNS infrastructure, you should manually create a delegation to this DNS server in the parent zone to ensure reliable name resolution from outside the domain "adatum.com". Otherwise, no action is required. Message Context RebootRequired Status ------- ------- -------------- ------ Operation completed succes... Test.VerifyDcPromo... False Success
To determine whether a remote server running Windows Server 2012 or Windows Server 2012 R2 satisfies these requirements, use the Invoke-Command cmdlet to execute the Test-ADDSForestInstallation cmdlet on the remote server as follows:
Invoke-Command -ComputerName SEA-SRV-1 {Test-ADDSForestInstallation -DomainName corp
.adatum.com}
First domain controller in new forest
Deploying the first domain controller running Windows Server 2012 or Windows Server 2012 R2 in a new forest is equivalent to installing a new forest and involves two steps:
- Adding the AD DS role to the server
- Promoting the server as a domain controller
Using Windows PowerShell, you can combine these actions into a single script you can execute on remote servers. The following scenario uses two stand-alone servers running Windows Server 2012 or Windows Server 2012 R2: a local server named SEA-HOST-2 and a remote server named SEA-SRV-1. The goal is to run a script on SEA-HOST-2 that will install a new forest, with SEA-SRV-1 being the first domain controller in the forest root domain. To accomplish this, you could proceed as follows:
- Begin by logging on to a local server running Windows Server 2012 or Windows Server 2012 R2 using your administrator credentials and open an elevated Windows PowerShell prompt. (If you are logged on with the built-in Administrator account, any Windows PowerShell prompt you open will be elevated.)
Change the script execution policy on the local server to RemoteSigned by running the following command:
Set-ExecutionPolicy RemoteSigned
- Changing the execution policy enables you to run Windows PowerShell scripts (.ps1 files) on the local server. By using Windows PowerShell remoting, you are also able to run scripts on the remote server.
Open Notepad and type the following two commands:
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools Install-ADDSForest -DomainName corp.adatum.com -InstallDNS
The first command installs AD DS with the role-management tools on the targeted server. The second command promotes the targeted server as the first domain controller in the forest root domain corp.adatum.com. Note that the name of the targeted server has not been specified in this script. Use Notepad to save the script with the file name script1.ps1 in the folder C:\scripts or some other suitable location on the local server.
Run the following command on the local server to execute your script on the remote server SEA-SRV-1:
Invoke-Command -ComputerName SEA-SRV-1 -FilePath C:\scripts\script1.ps1
When the AD DS role has finished installing on SEA-SRV-1, you will be prompted to specify a Safe Mode Administrator Password. This password is necessary because it enables you to log on to the new domain controller in Directory Services Recovery Mode when needed. After entering a password and confirming it, press Y and then ENTER to confirm that you want to promote the server as a domain controller. The promotion process begins, as shown in Figure 4-12. Note that you can eliminate the need to press Y and then ENTER by including the –Force parameter in the second line of your script.
FIGURE 4-12 Remote server SEA-SRV-1 is being promoted to be the first domain controller in a new forest.
Command output like the following will be displayed if the promotion process is successful:
PSComputerName : SEA-SRV-1 RunspaceId : dd268942-f430-43c9-9830-7c547d1a4b73 Message : Operation completed successfully Context : DCPromo.General.3 RebootRequired : False Status : Success
The server will then be restarted to complete the promotion process. If the remote server is a Server With A GUI installation, logging on to the server and launching Server Manager will confirm that the AD DS and DNS Server roles have been installed and the server is the first domain controller in the corp.adatum.com forest.
)
Additional domain controller in domain
You can use the Install-ADDSDomainController cmdlet to install an additional domain controller in an existing domain. For example, the following command installs and promotes a new domain controller and DNS server in the corp.adatum.com domain using domain administrator credentials:
Install-ADDSDomainController -InstallDns -Credential ` (Get-Credential CORP\Administrator) -DomainName corp.adatum.com
You will be prompted to provide and confirm the Directory Services Restore Mode (DSRM) password during the installation process.
If you want to use local administrator credentials instead of domain administrator credentials for this process, omit the –Credential parameter as follows:
Install-ADDSDomainController -InstallDns -DomainName corp.adatum.com
If you want to be prompted to supply the credentials needed to install and promote the domain controller, use the following command instead:
Install-ADDSDomainController -InstallDns -Credential ` (Get-Credential) -DomainName corp.adatum.com
You can use the Invoke-Command cmdlet to install several additional domain controllers at once, like this:
Invoke-Command -ComputerName SEA-SRV-2, SEA-SRV-3 -ScriptBlock `
{Install-ADDSDomainController -InstallDns -DomainName corp.adatum.com}
First domain controller in child or tree domain
You can use the Install-ADDSDomain cmdlet to install a new child or tree domain in an existing forest by deploying the first domain controller for the new domain. For example, to install and promote a server to be the first domain controller of a child domain hq in the parent domain corp.adatum.com, use this command:
Install-ADDSDomain -Credential (Get-Credential CORP\Administrator) ` -NewDomainName hq -ParentDomainName corp.adatum.com -DomainType ChildDomain ` -InstallDNS -CreateDNSDelegation
For more information on the syntax for this command, use the Get-Help cmdlet.
Read-only domain controllers
You can use the Add-ADDSReadOnlyDomainControllerAccount cmdlet to create an RODC account that can be used to install an RODC in your forest. After you have created the RODC account, you can use the Install-ADDSDomainController cmdlet with the –ReadOnlyReplica parameter to deploy a new RODC in an existing domain. For more information on these cmdlets, use the Get-Help cmdlet.
Quick check
What do you need to do before you can use one stand-alone Windows Server 2012 R2 server to remotely execute Windows PowerShell commands on another stand-alone Windows Server 2012 R2 server?
Quick check answer
- Add the second server to the TrustedHosts list on the first server.
Verifying domain controller deployment
You can also use Windows PowerShell to verify the results of installing AD DS on remote servers and promoting them as domain controllers. For example, you can use the cmdlets of the BestPractices module to perform BPA scans on remote servers. To illustrate this and continue the preceding scenario, begin by using Invoke-Command on local server SEA-HOST-2 to execute the Invoke-BPAModule cmdlet on remote server SEA-SRV-1:
PS C:\> Invoke-Command -ComputerName SEA-SRV-1 -ScriptBlock `
{Invoke-BpaModel -ModelId Microsoft/Windows/DirectoryServices}
ModelId : Microsoft/Windows/DirectoryServices
SubModelId :
Success : True
ScanTime : 6/20/2012 9:30:05 PM
ScanTimeUtcOffset : -07:00:00
Detail : {SEA-SRV-1, SEA-SRV-1}
You can then execute the Get-BPAResult cmdlet on the remote server to display the results of the scan you performed by using this command:
PS C:\> Invoke-Command -ComputerName SEA-SRV-1 -ScriptBlock `
{Get-BpaResult Microsoft/Windows/DirectoryServices}
The output from this command will be quite extensive, so you might try piping it into the Where-Object cmdlet to display only results whose severity level is Error:
PS C:\Users\Administrator> Invoke-Command -ComputerName SEA-SRV-1 -ScriptBlock `
{Get-BpaResult Microsoft/Windows/DirectoyServices} | Where-Object Severity -eq Error
ResultNumber : 28
ResultId : 513979436
ModelId : Microsoft/Windows/DirectoryServices
SubModelId :
RuleId : 36
ComputerName : SEA-SRV-1
Context :
Source : SEA-SRV-1
Severity : Error
Category : Configuration
Title : The PDC emulator master SEA-SRV-1.corp.adatum.com in this forest should
be configured to correctly synchronize time from a valid time source
Problem : The primary domain controller (PDC) emulator operations master in this
forest is not configured to correctly synchronize time from a valid
time source.
Impact : If the PDC emulator master in this forest is not configured to
correctly synchronize time from a valid time source, it might use its
internal clock for time synchronization. If the PDC emulator master in
this forest fails or otherwise becomes unavailable (and if you have not
configured a reliable time server (GTIMESERV) in the forest root
domain), other member computers and domain controllers in the forest
will not be able to synchronize their time.
Resolution : Set the PDC emulator master in this forest to synchronize time with a
reliable external time source. If you have not configured a reliable
time server (GTIMESERV) in the forest root domain, set the PDC emulator
master in this forest to synchronize time with a hardware clock that is
installed on the network (the recommended approach). You can also set
the PDC emulator master in this forest to synchronize time with an
external time server by running the w32tm /config /computer:SEA-SRV-
1.corp.adatum.com /manualpeerlist:time.windows.com
/syncfromflags:manual /update command. If you have configured a
reliable time server (GTIMESERV) in the forest root domain, set the PDC
emulator master in this forest to synchronize time from the forest root
domain hierarchy by running w32tm /config
/computer:SEA-SRV-1.corp.adatum.com /syncfromflags:domhier /update.
Compliance :
Help : http://go.microsoft.com/fwlink/?LinkId=142195
Excluded : False
PSComputerName : SEA-SRV-1
Uninstalling AD DS
Finally, you can use the Uninstall-ADDSDomainController cmdlet to remove the AD DS role and demote a domain controller to a member server in the domain. You will be prompted to set and confirm the local Administrator password before the completion of the removal process. For more information on using this cmdlet, use the Get-Help cmdlet.
Lesson summary
- You can use Windows PowerShell to deploy domain controllers running Windows Server 2012 or Windows Server 2012 R2. This procedure is mainly intended for large enterprises, data centers, and cloud-computing environments in which automation of this process is a requirement.
- You can use Windows PowerShell to install and promote a remote stand-alone server running Windows Server 2012 or Windows Server 2012 R2 to a domain controller after taking some preparatory steps to enable Windows PowerShell remoting to work properly in a workgroup environment.
- To use Windows PowerShell to install the AD DS role on a remote server, use the Invoke-Command cmdlet to remotely execute the Install-WindowsFeature cmdlet.
- To use Windows PowerShell to promote a remote server that already has the AD DS role installed, use the Invoke-Command cmdlet to remotely execute the appropriate cmdlet from the ADDSDeployment module.
- To use Windows PowerShell to run a prerequisites check before attempting to install a new forest, install a new domain, deploy a writeable domain controller, and use the Test-ADDS* cmdlets from the ADDSDeployment module.
- To use Windows PowerShell to run a Best Practices Analyzer (BPA) scan on remote servers after installing AD DS and promoting them to domain controllers, use the Invoke-Command cmdlet to remotely execute the appropriate cmdlet from the BestPractices module.
Lesson review
Answer the following questions to test your knowledge of the information in this lesson. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
Which of the following Windows PowerShell commands adds the remote server SRV-A to the TrustedHosts list on the local server?
- Get-Item wsman:\localhost\Client\TrustedHosts –Value SRV-A
- Set-Item wsman:\localhost\Client\TrustedHosts –Value SRV-A
- Get-Item wsman:\localhost\Server\TrustedHosts –Value SRV-A
- Set-Item wsman:\localhost\Server\TrustedHosts –Value SRV-A
Which of the following is not a cmdlet from the ADDSDeployment module?
- Install-ADDSDomain
- Install-ADDSDomainController
- Uninstall-ADDSDomainController
- Get-ADForest
Which Windows PowerShell command should you use to run a prerequisites check before attempting to deploy an additional domain controller in an existing forest?
- Install-ADDSDomainController –Prerequisites
- Invoke-BpaModel –ModelId Microsoft/Windows/DirectoryServices
- Test-ADDSDomainControllerInstallation
- Install-ADDSDomainController –Whatif