Even IT industry is talking about the cloud and everything cool inside of it most of the enterprise organizations still have an on-premises environment, right? There isn’t any significant changes when upgrading Active Directory Domain Services from Windows Server 2012 R2 to Windows Server 2016 level. Here is guidance for AD DS upgrade in a nutshell.

Even Windows Server 2012 came with the feature that allows you to perform all necessary updates to AD DS schema directly from GUI I have always performed schema updates from command prompt manually, I really want to see what’s happening underneath the hood.

Microsoft recommendation to perform schema updates back in the days was “offline” but they changed it several years ago from “offline” to “live”. Reason for this is that when administrators disabled replication from Domain Controllers during schema update they forgot to enable it again and it caused lots of tickets to Premier Support. In general you have two options, go live and trust your disaster recovery plans or perform schema update by disabling replication. Schema update itself is straightforward and safe operation. Keep in mind that operation itself is irreversible so only option to rollback to earlier state is forest recovery.

Couple links below, first one is Best Practice for schema updates and second one is for getting report out of AD DS schema:

My own guidelines to perform schema update are below. If I have possibility and time to perform ADDS forest recovery to an isolated environment I select nowadays “live” option for the update. If it’s working as expected in identical restored environment it will work in production environment for sure.

  • Perform AD DS health check to environment before update
  • Analyse schema classes and attributes, are there any own added classes and attributes at AD DS schema? Tool for schema report
  • Perform ADDS forest recovery to isolated environment and perform schema update first to it. It’s a good way to practise forest recovery processes at same time
  • Disaster recovery plan – DRP! You must have this one
  • Disable replication before making changes (optional)
  • Validate updates from schema master and remember to enable replication (optional)

AD DS Schema versions

Version number Operating System level
13 2000
30 2003
31 2003 R2
44 2008
47 2008 R2
56 2012
69 2012 R2
87 2016

Upgrade

As I said I’m always performing schema updates manually from command line, old fashion way:) Adprep tool is found from W2016 media support\adprep path. Commands below

adprep-commands

In production environment I’ll either disable replication before committing changes  or perform update following Microsoft best practices (live option). Depending changes you are making domain controller roles needed during schema extension can be varied, more information at table below.

Change to replication can be done with repadmin tool: “repadmin /options <DC NAME> +DISABLE_OUTBOUND_REPL”

Table of adprep commands, needed permissions and FSMO roles when performing AD DS schema extension

Command Permission Domain Controller Runtime Number of times to run command
adprep forestprep Schema, Domain Enterprise Admins Schema Master 5-10 mins Once for the entire forest
adprep /domainprep Domain Admins Infrastructure Master Seconds Once in each domain where you plan to install an additional domain controller that runs a later version of Windows Server than the latest version that is running in the domain.
adprep /rodcprep Enterprise Admins Domain Naming Master Seconds Once for the entire forest
adprep /gpprep Domain Admins Infrastructure Master

(If you already ran this command for Windows Server 2008, you do not have to run it again)

Seconds Once in each domain within the forest

Run forest wide preparation – adprep /forestprep command

forestprep

Run domain wide prepation – adprep /domainprep command

Run read-only domain controller preparation – adprep /rodcprep (I had already performed this one earlier as message says)

domainprep

Validate preparations and remember to enable replication

To determine if adprep /forestprep completed successfully, you can use ADSIEdit to verify the value of the “Revision” attribute of the ActiveDirectoryUpdate container.

Verify following revision attribute values from Active Directory and logs from domain controllers after Adprep commands:

  1. CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=ForestRootDomain object is set to 16 (W2012 R2 = 15)
  2. CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=ForestRootDomain object is set to 15 (W2012 R2 = 10)
  3. CN=ActiveDirectoryRodcUpdate,CN=ForestUpdates,CN=Configuration,DC=ForestRootDomain object is set to 2 – set when rodcprep is executed
  4. Enable replication: repadmin /options <DC NAME> -DISABLE_OUTBOUND_REPL (optional)

Install new W2016 Domain Controller

When AD DS schema extension has been performed successfully new Windows Server 2016 domain controllers can be installed to environment. DC promotion can be done in different ways, from GUI or with Powershell. I prefer PS because it has nowadays good support for implementing AD DS and managing domain controllers. Below is short Powershell “one-liner” collection for implementing Domain Controllers. Toolset was originally created by Microsoft PFE and can be modified to fit your needs.

#################################################
# DCPROMO UP: Create a new DC on a member server in the domain
#################################################
# Prompt for credentials to reuse throughout the script

$cred = Get-Credential domain\admin

# Echo the date for reference in the console output
Get-Date

# Query the current list of domain controllers before the new one
Get-ADDomainController -Filter * | Format-Table Name, Site, IPv4Address -AutoSize

# Import the module containing Get-WindowsFeature
Import-Module ServerManager

# List the currently installed features on the remote server
Get-WindowsFeature -ComputerName dc.feta.fi | Where-Object Installed | Format-Table Name

# Install Active Directory Role
Install-WindowsFeature -ComputerName dc -Name AD-Domain-Services -IncludeManagementTools

# Echo the date for reference in the console output
Get-Date

# Query the current list of domain controllers before the new one
Get-ADDomainController -Filter * | Format-Table Name, Site, IPv4Address -AutoSize

# Import the module containing Get-WindowsFeature
Import-Module ServerManager

# List the currently installed features on the remote server
Get-WindowsFeature -ComputerName dc.feta.fi | Where-Object Installed | Format-Table Name
# Promote a new domain controller in the existing domain
# Adjust the parameters to meet your own needs

# Deploy DC to DC
Invoke-Command –ComputerName DC –ScriptBlock {
Import-Module ADDSDeployment
Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-CreateDnsDelegation:$false `
-CriticalReplicationOnly:$false `
-DatabasePath “C:\Windows\NTDS” `
-DomainName “feta.fi” `
-InstallDns:$true `
-LogPath “C:\Windows\NTDS” `
-NoRebootOnCompletion:$false `
-ReplicationSourceDC “DC1.feta.fi” `
-SiteName “Default-First-Site-Name” `
-SysvolPath “C:\Windows\SYSVOL” `
-Force:$true `
-Credential $using:cred `
-Confirm:$false `
-SafeModeAdministratorPassword `
(ConvertTo-SecureString ‘<insert recovery password here>’ -AsPlainText -Force)
}
# Once fully restarted and promoted, query for a fresh list of DCs.
# Notice our new DC in the list.
Get-ADDomainController -Filter * | Format-Table Name, Site, IPv4Address -AutoSize

# Echo the date and time for job completion.
Get-Date

#Validate installation

# Check random services common to DCs
Get-Service adws,kdc,netlogon,dns -ComputerName DC

# Check for presence of SYSVOL
Test-Path \\DC\SYSVOL
Get-ChildItem \\DC\SYSVOL

Happy promoting 🙂