Considerations when upgrading Active Directory schema to Windows Server 2016

Every new release of Windows Server provides new schema attributes for Active Directory. If you are running earlier versions of Active Directory, such as Windows Server 2012 R2, in your environment and if you would like to use the new schema attributes that ship with Windows Server 2016, you are required to upgrade your existing schema to Windows Server 2016. This article explains the approach that you will need to follow when upgrading Active Directory schema in a production environment. While the Active Directory schema upgrade process is quite simple, a failure in the schema upgrade might cause downtime for your production environment.

Test schema updates in test environment

Your first task is to ensure that the schema updates you are going to apply to a production environment are tested in a test environment. In a test environment, you would need a domain controller that is running Windows Server 2012 R2 and one more domain controller to ensure the schema changes can be replicated. You will be required to execute the ADPrep tool, located under the Windows Server 2016 media in \Support folder. The following commands need to be executed to upgrade the schema:

  • ADPrep /ForestPrep: Use this command to run a forest-wide schema update operation.
  • ADPrep /DomainPrep: Use this command to run a domain-wide schema update operation.

Once you have executed these commands, verify the schema in Active Directory. To ensure ADPrep /ForestPrep completed successfully, use ADSIEdit and then check the value of “Revision” attribute under ActiveDirectoryUpdate container. The value must be set to 16.

Active Directory schema upgrade approach for a production AD forest

Once you have tested the schema in the test environment, you can follow a steady approach to upgrade the schema in the production environment. Note that it is important to understand that if you decide to restore Active Directory to the previous schema state, you have no option other than restoring the complete Active Directory forest. When updating the schema, an isolated environment must be created that will be used to upgrade the schema. The environment will have a single domain controller running Windows Server 2012 R2. The complete approach is highlighted below:

Step 1: Create a new Active Directory site called “Schema-Upgrade.” You will create this Active Directory in the production Active Directory.

Step 2: Move one production domain controller to the “Schema-Upgrade” AD site.

Step 3: Run KCC (Knowledge Consistency Checker) to ensure connection objects are created between the domain controller in the “Schema-Upgrade” site and domain controllers in the nearest locations. This step is required to ensure an Active Directory replication connection object has been created between domain controllers.

Step 4: Force replication to ensure a “Full Active Directory Replication Cycle” is completed.

Step 5: Remove Active Directory connection objects with other domain controllers. This is to ensure the Schema is applied only the domain controller in the “Schema-Upgrade” AD Site.

Step 6: Once the schema update is successful, verify the update by running the LDP.exe utility and performing the below steps:

  1. Run LDP.exe tool, go to Connection and then click on Bind.
  2. Click Ok. Next click on View, Tree, and then select the following LDAP path from the dropdown list: CN=Schema,CN=Configuration,DC=<DomainName>,DC=<Com>
  3. Click OK to run the LDP query against the above LDAP path.
  4. In the right pane, check objectVersion: 87 attribute. If it is 87, admin ADPrep command successfully extended the schema.

Tip: The ObjectVersion attribute contains the schema version of the Active Directory forest. This attribute is modified when you upgrade the schema of the current Active Directory forest.

At this point, the schema update has been applied successfully to the domain controller running in the “Schema-Upgrade” Active Directory. You might want to execute all necessary tests to ensure new schema attributes have been populated successfully in the domain controller in the “Schema-Upgrade” site. You also need to check Systems, Active Directory and Applications Events to ensure there are no errors or warnings reported. Once you have confirmed and the results are passed for schema testing, enable the replication with other domain controllers.

It’s simple — but be careful

While the Active Directory schema upgrade process is very simple as you would be required to run only a few commands on a domain controller, a failure in the schema upgrade process many completely take your entire Active Directory environment down and may require you to restore the Active Directory forest using the Active Directory forest restore methods.

About The Author

5 thoughts on “Considerations when upgrading Active Directory schema to Windows Server 2016”

  1. Hi
    Mr Nirmal Sharma
    We are planning to raise the Functional Level from 2008 R2 to Server 2012 and then updating the Server 2012 to 2016 and updating the Schema. I would like to have some thought on this. I would appreciate your help.
    Gary

  2. Dear Nirmal ,

    We are planning to schema upgrade from 2012 r2 to 2016 in Prod environment. For that i need to prepare a doc as

    What’s new in AD DS in Windows Server 2016?
    Application compatibility
    Deprecated features and behavior changes related to AD DS in Windows Server 2016
    Required SKUs
    Known issues
    Upgrade plans etc ..

    Can you please help me on that. Thank you.

    Thanks and Regards,
    Jai

  3. Hi Nirmal,

    We are planning to upgrade our AD 2008.
    Can we go directly from 2008 to 2019?
    Are there any other customers who have do this?
    would you be kind enough to share some documentation on what considerations should be made in this case?

    Thanks
    Dinesh

  4. I am in process of upgrading DC from 2008R2 to 2016. i really appreciate if you can advise me on the schema update and process to follow.

  5. Not sure about the extra overhead work necessary to create another site with changes to a production replication topology. Also there is something fundamentally wrong, you can’t just move a Production DC to a site and hope a schema upgrade to it as 99% of chance the DC you moved doesn’t have a writable schema partition. Feels like the author may not have done a schema upgrade practically.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top