Active Directory (AD) Schema is a blueprint or framework that defines the structure of objects (such as users, computers, groups, and other resources) stored in an Active Directory domain. It defines the attributes, classes, and relationships between objects within the directory.
The schema contains the definitions of all objects that can be created in an AD environment, including their properties and attributes. It also determines the types of objects that can be added to the directory and their relationships with other objects.
The schema is an essential component of the AD infrastructure and ensures consistency and integrity of the data stored in the directory. Any changes to the schema must be carefully planned and tested to avoid disrupting the directory’s operation.
Table of Contents
Active Directory Schema Update: An Overview
Typically, the AD schema is extended/upgraded for several reasons. The most common is implementing an application that requires an extension of the schema (for products such as Microsoft Exchange, Lync/Skype for Business, and SCCM) or deploying an additional domain controller with a new version of Windows Server.
Updating the Active Directory schema used to be a daunting task for administrators. Why wouldn’t it? If something goes wrong, there’s no undo button to roll back the changes so quickly. But that’s a thing of the past.
Since the release of Windows Server 2012, the schema update has been integrated into the deployment of the Active Directory Domain Services role. In a gist, here’s the high-level process.
- Install a newer Windows Server version on a separate machine.
- Join the new server to the domain.
- Deploy the Active Directory Domain Services role on the new server.
But it doesn’t mean you cannot update the Active Directory schema using the /adprep and /forestprep switches beforehand. You still can, especially if you plan to install the new Windows Server later.
Checking the Active Directory Schema Version
Before updating the schema, any administrator worth their salt would confirm and document the current schema version. This practice should be the standard. And luckily, there’s a quick way to check the Active Directory schema version using PowerShell.
(Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectVersion).objectVersion
When you run the command above in PowerShell, you’ll get a similar output to the one below.
According to the result, the AD schema version is 87, which is the version in Windows Server 2016 based on the below table.
Source: “ObjectVersion” attribute to Operating System
Version | Operating System | Note |
13 | Windows 2000 Server | |
30 | Windows Server 2003 RTM, Windows 2003 Service Pack 1, Windows 2003 Service Pack 2 | |
31 | Windows Server 2003 R2 | |
44 | Windows Server 2008 RTM | |
47 | Windows Server 2008 R2 | |
56 | Windows Server 2012 | |
69 | Windows Server 2012 R2 | |
87 | Windows Server 2016 | |
88 | Windows Server 2019 | Only one attribute was added to Windows 2019: msDS-preferredDataLocation |
88 | Windows Server 2022 | No schema changes from Windows 2019. |
But instead of manually comparing the version with the above table, you can run the below script instead.
# Get-AdSchemaVersion.ps1 $versionTable = @{ 13 = 'Windows 2000 Server' 30 = "Windows Server 2003 RTM, Windows 2003 Service Pack 1, Windows 2003 Service Pack 2" 31 = 'Windows Server 2003 R2' 44 = 'Windows Server 2008 RTM' 47 = 'Windows Server 2008 R2' 56 = 'Windows Server 2012' 69 = 'Windows Server 2012 R2' 87 = 'Windows Server 2016' 88 = 'Windows Server 2019, Windows Server 2022' } $schemaVersion = (Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectVersion).objectVersion New-Object psobject -Property @{ Version = $schemaVersion OS = $versionTable[$schemaVersion] }
Save the script as Get-AdSchemaVersion.ps1 and run it in PowerShell.
Active Directory Schema Update (Manual with ADPREP)
As mentioned earlier in this post, manually deploying the ADDS role to another Windows Server will also take care of the AD schema update. So why would you want to update the schema manually?
One scenario is when performing an in-place upgrade of the OS, like upgrading Windows Server 2016 to Windows Server 2019. In this scenario, you will get the following message.
Important. Active Directory on this domain controller does not contain Windows Server 2019 ADPREP /FORESTPREP updates.
In this case, you must perform the AD schema update separately by running the following command.
.\adprep.exe /forestprep
Note. The ADPREP.EXE command is in the Windows Server installation media under the <drive>:\support\adprep directory.
Hint. The ADPREP /FORESTPREP can only be executed by a member of all these groups: Enterprise Admins, Schema Admins, and Domain Admins. Also, this command can only be run on the server holding the Schema Master FSMO role.
In the same manner, run the following command to prepare the domain.
.\adprep.exe /adprep
Once the Active Directory Schema update is finished, you can re-run the in-place upgrade.
Active Directory Schema Update (Automatic with DC Deployment)
The schema update is now part of the ADDS role deployment. In this example, a Windows Server 2019 is joined to the domain, where the domain controller runs on Windows Server 2016.
Install the Active Directory Domain Service role on the new server as usual.
Once ADDS is installed, click the Promote this server to a domain controller link.
Next, choose the Add a domain controller to an existing domain option and click Next.
Enter the DSRM password and click Next.
Click Next until you reach the Preparation Options page. As you can see, the wizard says it needs to perform the Forest and schema preparation and Domain preparation steps. Click Next.
Click Next on the Review Options page.
Once the Prerequisites Check passed, click Install.
After the DC promotion, the server reboots. Next, run the following command to confirm that the new domain controller is visible.
Get-ADDomainController -Filter * | Select-Object Name, OperatingSystem
And confirm that the Active Directory Schema version is updated to the Windows Server 2019 version.
Post-Schema Update Tasks
After upgrading the schema by deploying the newest domain controller, you must perform the following steps if you plan to demote the old domain controller.
- Transfer the FSMO role to the new domain controller.
- Demote the old domain controller by running the below command:
Uninstall-ADDSDomainController
- Raise the Forest and Domain Functional levels.
- Run the below command to confirm that the old domain controller has been demoted:
Get-ADDomainController -Filter * | Select-Object Name, OperatingSystem
Extending the Active Directory Schema for Exchange Server Installation
If you deploy Microsoft Exchange in your organization, you must extend the AD and add custom classes and the Exchange attribute. To do this, you need an Exchange Server installation media, such as Exchange Server 2019.
Open an elevated PowerShell and run the below command to extend the Active Directory schema:
.\Setup.EXE /PrepareSchema /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF
If the installer cannot find a domain controller with the Schema Master role, you can specify it by adding the /DomainController parameter:
.\Setup.EXE /PrepareSchema /DomainController:dc2019.theitbros.com /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF
As a result of the schema extension procedure, the Active Directory objects will have new attributes related to Exchange Server.
Now we need to prepare the domain. This procedure consists of creating new Active Directory objects and containers required for the Exchange Server.
.\Setup.EXE /PrepareAD /OrganizationName:"The IT Bros" /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF
The Active Directory Schema is now prepared, and you can install the Exchange Server.
Conclusion
Updating the Active Directory schema is a crucial task that ensures the smooth functioning of an organization’s IT infrastructure. It allows adding new attributes and classes and helps integrate new applications and services.
But, updating the schema requires careful planning, testing, and execution to avoid disrupting the existing systems. With the steps outlined in this blog post, you can confidently update your Active Directory schema and minimize the risk of downtime or data loss.
Remember to test any changes in a controlled environment before implementing them in a production environment whenever possible. With these precautions, you can keep your Active Directory schema up-to-date.