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.

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

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.

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:

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}

Deploying the first Windows Server 2012 domain controller for a new forest is equivalent to installing a new forest and involves two steps:

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:

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}

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.

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.