Windows Server 2012 : Deploying domain controllers using Windows PowerShell (part 1)

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.

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.

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: