Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

4. Deploying Domain Controllers > Lesson 3: Deploying domain controllers using ...

Lesson 3: Deploying domain controllers using Windows PowerShell

Windows PowerShell provides a way to automate the deployment of Windows Server 2012 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.

After this lesson, you will be able to

  • Prepare your environment for domain controller deployment using Windows PowerShell.

  • Use Windows PowerShell to verify the prerequisites for installing new forests, domains, and domain controllers.

  • Use Windows PowerShell to install AD DS on servers and promote them as domain controllers in both new and existing forests.

  • Use Windows PowerShell to demote domain controllers.

Estimated lesson time: 30 minutes

Preparing for domain-controller deployment

Similar to how domain controllers can be deployed using Server Manager as described in the previous lesson, the steps for preparing to deploy Windows Server 2012 domain controllers using Windows PowerShell differ depending on the scenario being considered.

Note

REAL WORLD Windows PowerShell and Server Core installations

The Server Core installation option for Windows Server 2012 is ideal for data-center environments because of its smaller servicing footprint, disk space requirements, and attack surface. The Server Core installation option also supports installing the AD DS role, so using Windows PowerShell to deploy Server Core domain controllers is an ideal combination for a data center.

Preparing for deploying the first domain controller in a new forest

To deploy the first Windows Server 2012 domain controller in a new forest using Server Manager, 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, however, is to use Windows PowerShell remoting, which lets you run Windows PowerShell commands on one or more remote computers simultaneously by using the WS-Management protocol.

As explained previously in Chapter 3, the remote-management capability is enabled by default on Windows Server 2012 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: Windows PowerShell automation 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 yet to join! In other words, the remote server that will be promoted to a domain controller is initially in a workgroup, not a domain. And the local computer you will be performing the deployment from might also be in a workgroup.

The solution is to prepare your environment by enabling the two standalone computers to talk to each other using the WS-Management protocol. If the computer you are performing the deployment from is also running Windows Server 2012, you simply 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.

Important

Adding remote servers to the TrustedHosts list on your computer

When you add a remote server to the TrustedHosts list on your computer, you are allowing your credentials to be sent to the remote server without verifying the server’s identity. So add remote servers to this list only if you are certain the network path from your computer to the remote server machine is completely secure.

To illustrate how to do this, consider a scenario where you have two standalone servers running Windows Server 2012: 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 and do this on the local server, you get the error highlighted 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 first 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
...

Note

Tips for running Set-Item wsman:\localhost\Client\TrustedHosts

If you need to add another remote server to the TrustedHosts list on your local computer, include the –Concatenate parameter when you use Set-Item the second time so that you don’t end up overwriting the current contents of the list. You can also suppress the Yes/No prompt with the Set-Item cmdlet by adding the –Force parameter to it.

Preparing for deploying additional domain controllers in the new forest

Deploying additional domain controllers in a new forest is easier 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 domain controller in your forest, or from a Windows 8 client computer on which the Remote Server Administration Tools for Windows 8 have 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

Deploying Windows Server 2012 domain controllers in a forest whose domain controllers are running an earlier version of Windows Server can also be done using Windows PowerShell as follows:

  1. Install a Windows Server 2012 server, and join the server to an existing domain.

  2. Use the Install-WindowsFeature cmdlet to install the AD DS role together with its role-management tools as follows:

    Install-WindowsFeature -name AD-Domain-Services -IncludeManagementTools
  3. Run commands from the ADDSDeployment module on the server to remotely install AD DS on other domain-joined Windows Server 2012 servers.

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 together with its role-management tools on a server, regardless of whether the server has been promoted to a domain controller or not. 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 standalone Windows Server 2012 server 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 Windows Server 2012 server 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 Windows Server 2012 domain controller for a new forest is equivalent to installing a new forest and involves two steps:

  1. Adding the AD DS role to the server.

  2. Promoting the server as a domain controller.

Using Windows PowerShell, these actions can be combined into a single script you can execute on remote servers. The following scenario uses two standalone Windows Server 2012 servers: 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:

  1. Begin by logging on to a local server running Windows Server 2012 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.)

  2. Change the script execution policy on the local server to RemoteSigned by running the following command:

    Set-ExecutionPolicy RemoteSigned
  3. This will allow you to run Windows PowerShell scripts (.ps1 files) on the local server. By using Windows PowerShell remoting, you will also be able to run scripts on the remote server.

  4. 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 together 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.

  5. 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
  6. 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 needed so that you can 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 followed by ENTER by including the –Force parameter in the second line of your script.

    Remote server SEA-SRV-1 is now being promoted to be the first domain controller in a new forest.
    Figure 4-12. Remote server SEA-SRV-1 is now being promoted to be the first domain controller in a new forest.
  7. 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 now 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}

Note

Multiple line commands

The backtick character is an escape character in Windows PowerShell that is appended to a line to indicate that the command continues on the next line.

First domain controller in a 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 become 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 the RODC account has been created, 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.

Note

MORE INFO Installing and promoting domain controllers

For additional examples and guidance concerning the deployment of domain controllers in different scenarios, see the following topics in the TechNet Library:

See also Lesson 4: Windows PowerShell automation of Chapter 3.

Quick check

  • What do you need to do before you can use one standalone Windows Server 2012 server to remotely execute Windows PowerShell commands on another standalone Windows Server 2012 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 with 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 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

Note

MORE INFO Using the BestPractices module

For more information on how to use Windows PowerShell to perform BPA scans, see the topic “Run Best Practices Analyzer Scans and Manage Scan Results” in the TechNet Library at http://technet.microsoft.com/en-us/library/hh831400.aspx.

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

  • Windows PowerShell can be used to deploy Windows Server 2012 domain controllers. This procedure is mainly intended for large enterprises, data centers, and cloud-computing environments where automation of this process is a requirement.

  • You can use Windows PowerShell to install and promote a remote standalone server running Windows Server 2012 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 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.

  1. Which of the following Windows PowerShell commands adds the remote server SRV-A to the TrustedHosts list on the local server?

    1. Get-Item wsman:\localhost\Client\TrustedHosts –Value SRV-A

    2. Set-Item wsman:\localhost\Client\TrustedHosts –Value SRV-A

    3. Get-Item wsman:\localhost\Server\TrustedHosts –Value SRV-A

    4. Set-Item wsman:\localhost\Server\TrustedHosts –Value SRV-A

  2. Which of the following is not a cmdlet from the ADDSDeployment module?

    1. Install-ADDSDomain

    2. Install-ADDSDomainController

    3. Uninstall-ADDSDomainController

    4. Get-ADForest

  3. Which Windows PowerShell command should you use to run a prerequisites check before attempting to deploy an additional domain controller in an existing forest?

    1. Install-ADDSDomainController –Prerequisites

    2. Invoke-BpaModel –ModelId Microsoft/Windows/DirectoryServices

    3. Test-ADDSDomainControllerInstallation

    4. Install-ADDSDomainController –Whatif

  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint