Welcome to part two of this blog where we discuss promoting a Domain Controller with Windows PowerShell. We also discuss how you can do the prerequisites checks before introducing the first Windows Server 2012 Domain Controller.

Promoting a Domain Controller with PowerShell

Just like in the GUI you will want to install the Active Directory Domain Services role.

------------------------Begin PowerShell---------------------------------------------------------

get-windowsfeature AD-Domain-Services

Display Name Name Install State

------------ ---- -------------

[ ] Active Directory Domain Services AD-Domain-Services Available

get-windowsfeature AD-Domain-Services | install-windowsfeature

or just

install-windowsfeature –Name AD-Domain-Services

Success Restart Needed Exit Code Feature Result

------- -------------- --------- --------------

True No Success {Active Directory Domain Services}

WARNING: Windows automatic updating is not enabled. To ensure that your newly-installed role or feature is

automatically updated, turn on Windows Update.

------------------------End PowerShell---------------------------------------------------------

Now in PowerShell we can actually do the prerequisite checks without promoting the machine to a Domain Controller. This will help us in the planning phase to identify issues and properly address them before we hit a potential roadblock installing the first DC. I will cover all three cmdlets here, but since this post is mainly focused on introducing a DC into an existing environment we really only care about the third one.

------------------------Begin PowerShell---------------------------------------------------------

Test-ADDSForestInstallation

cmdlet Test-ADDSForestInstallation at command pipeline position 1

Supply values for the following parameters:

DomainName: pfeadupg.test

SafeModeAdministratorPassword:

Confirm SafeModeAdministratorPassword:

WARNING: Windows Server 2012 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).

------------------------End PowerShell---------------------------------------------------------

You will then be given items that would need to be addressed if you were creating a whole new Active Directory forest.

If you were going to be introducing a new domain into an existing forest the below cmdlet would check for any issues you might run into prior to doing that.

------------------------Begin PowerShell---------------------------------------------------------

Test-ADDSDomaininstallation

cmdlet Test-ADDSDomainInstallation at command pipeline position 1

Supply values for the following parameters:

NewDomainName: child.pfeadupg.test

ParentDomainName: pfeadupg.test

SafeModeAdministratorPassword:

Confirm SafeModeAdministratorPassword:

Message Context RebootRequired Status

------- ------- -------------- ------

Verification of prerequisi... Test.VerifyADPrepPrerequis... False Error

WARNING: Windows Server 2012 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).

 

Verification of prerequisi... Test.VerifyDcPromoCore.DCP... False Error

Test VerifyOutboundReplica... Test.VerifyOutboundReplica... False Success

------------------------End PowerShell---------------------------------------------------------

What is different in this output you will notice is the Test VerifyOuboundReplication however it says Success. Yes we do check to ensure that Outbound Replication is enabled and that you aren’t doing the old isolate the schema master trick. We don’t recommend that and my coworker Doug Symalla wrote a good post about that here.

http://blogs.technet.com/b/askpfeplat/archive/2012/05/28/best-practices-for-implementing-schema-updates-or-how-i-learned-to-stop-worrying-and-love-the-forest-recovery.aspx

We do check this in the GUI as well, but will only flag it if it is disabled.

image_thumb19

The cmdlet we really care about is the one below. This cmdlet will test adding a DC to an existing domain and forest which is the main intent of this post.

------------------------Begin PowerShell---------------------------------------------------------

Test-ADDSDomainControllerInstallation

cmdlet Test-ADDSDomainControllerInstallation at command pipeline position 1
Supply values for the following parameters:
DomainName: pfeadupg.test
SafeModeAdministratorPassword:

Confirm SafeModeAdministratorPassword:


Message                       Context                                      RebootRequired                        Status
-------                       -------                                      --------------                        ------
Test VerifyADPrepPrerequis... Test.VerifyADPrepPrerequis...                         False                       Success
WARNING: Windows Server 2012 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).


Verification of prerequisi... Test.VerifyDcPromoCore.DCP...                         False                         Error
Test VerifyOutboundReplica... Test.VerifyOutboundReplica...                         False                       Success

------------------------End PowerShell---------------------------------------------------------

Now that we have done that we can move forward with promoting the actual DC. We will use that script we had created in the first post. However I have reset this forest and it has never had a Windows Server 2012 DC in it. This is not a continuation of what we did in the GUI. So we are not adding a second Windows Server 2012 DC. We will be preparing the forest and domain again. If this has not already been done the PowerShell cmdlet will also do this (assuming you have the correct permissions).  

#
# Windows PowerShell script for AD DS Deployment
#

Import-Module ADDSDeployment
Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-CreateDnsDelegation:$false `
-CriticalReplicationOnly:$false `
-DatabasePath "C:\Windows\NTDS" `
-DomainName "pfeadupg.test" `
-InstallDns:$true `
-LogPath "C:\Windows\NTDS" `
-NoRebootOnCompletion:$false `
-SiteName "Site-1" `
-SysvolPath "C:\Windows\SYSVOL" `
-Force:$true

 


First you will need to change the PowerShell execution policy.

Set-executionpolicy remotesigned

Then we will run the script which I called newdc.ps1.

.\newdc.ps1

SafeModeAdministratorPassword:

Confirm SafeModeAdministratorPassword:

The first time I ran this it failed. Again because I did not meet the FFL requirement. However the important thing to note here was that none of the prerequisite checks told me about this problem. So I fixed the problem and we will run it again.

image_thumb15

------------------------Begin PowerShell---------------------------------------------------------

.\newdc.ps1

SafeModeAdministratorPassword:

Confirm SafeModeAdministratorPassword:

WARNING: Windows Server 2012 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

"pfeadupg.test". Otherwise, no action is required.

WARNING: Windows Server 2012 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

"pfeadupg.test". Otherwise, no action is required.

Message Context RebootRequired Status

------- ------- -------------- ------

Operation completed succes... DCPromo.General.1 False Success

------------------------End PowerShell---------------------------------------------------------

Since I did not specify a Safe Mode password in my script I was prompted for this. This way no passwords are exposed in a text file. However if you wanted to fully automate this then that can be done.

Just like in part 1 we basically performed /forestprep and /domainprep as part of the DC promotion process. However, we know many of our customers might not want to do this. In this case using the Windows Server 2012 media or a copy of the media you can run the adprep command(s) just like you did in previous versions of Windows. Adprep has also been enhanced so the command does not have to run from the schema master in the case of /forestprep and from the infrastructure master in the case of /domainprep and /rodcprep. It has also been enhanced to fix an invalid infrastructure FSMO reference that some customers hit when running /rodcprep in Windows Server 2008 and Windows Server 2008 R2.

After introduction of the first Windows Server 2012 Domain Controller

Just like in part 1 we can now run the BPA. We can run this via PowerShell just like we were able to in Windows Server 2008 R2. The BPA documentation for Windows Server 2008 R2 is located here and works on Windows Server 2012.

http://technet.microsoft.com/en-us/library/dd378893(v=WS.10).aspx

http://technet.microsoft.com/en-us/library/dd759206.aspx

The below output is only a snip since the PowerShell cmdlet will return all results include passed results. The link above will allow you to exclude and filter the output.

------------------------Begin PowerShell---------------------------------------------------------

invoke-bpamodel –bestpracticesmodelid Microsoft/Windows/DirectoryServices

get-bparesult Microsoft/Windows/DirectoryServices

ResultNumber : 37
ResultId     : 3415681431
ModelId      : Microsoft/Windows/DirectoryServices
SubModelId   :
RuleId       : 45
ComputerName : PARENT-DC3
Context      :
Source       : PARENT-DC3
Severity     : Error
Category     : Configuration
Title        : CN=DES User,OU=ServiceAcccounts,DC=pfeadupg,DC=test should not be configured for DES only
Problem      : A user account or trust for domain pfeadupg.test is configured for Data Encryption Standard (DES) only.
               DES is considered weak cryptography and is no longer enabled by default in Kerberos authentication in
               Windows 7 and Windows Server 2008 R2.
Impact       : User accounts and trusts configured for DES only will have authentication failures.
Resolution   : User accounts and trusts should use Advanced Encryption Standard (AES) or RC4 Kerberos encryption keys.
Compliance   :
Help         :
http://go.microsoft.com/fwlink/?LinkId=168859

Excluded     : False

------------------------End PowerShell---------------------------------------------------------

Just like in the GUI results from the first post the BPA identifies items such as the user account with DES enabled. You want to be aware of these things since it may affect an application or service. The best thing to do is to first test this in a lab, but if for some reason you can’t do this or the lab doesn’t match production you should definitely run this on the first Windows Server 2012 Domain Controller that you introduce.

Summary

So to wrap up this blog post we have covered what it takes to introduce the first Windows Server 2012 Domain Controller in your environment. We have covered using both the GUI as well as Windows PowerShell. We also covered some things you need to consider such as the forest functional level.

 

Thanks,

Greg