Upgrading AD DS Schema to Windows Server 2016

Even the 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 aren’t any significant changes when upgrading Active Directory Domain Services from Windows Server 2012 R2 to Windows Server 2016 level. Here is a 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 a 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 the second one is for getting the report out of AD DS schema:

• Excellent blog about Schema update best practices
• Active Directory schema report by Ashley McGlone

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 an identical restored environment it will work in a production environment for sure.

• Perform AD DS health check to the environment before update
• Analyze 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 an isolated environment and perform schema update first to it. It’s a good way to practice forest recovery processes at the 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 the command line, old fashion way:) Adprep tool is found from W2016 media support\adprep path. Commands below

In a 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 the 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

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)

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

Happy promoting 🙂