Windows Server 2019 reached GA although the certified hardware from equipment makers is yet to come (status at early October).
This ADDS version is something different than before because there are only a few new features. It’s even more obvious where development currently resides (Azure AD). That said, the guideline for upgrade process remains the same, Detailed instructions found from this link. I wrote a blog post about the upgrade process a couple years ago and things haven’t changed since.
What’s new in ADDS Windows Server 2019? Basically nothing but at least something.
- One new attribute with an as-yet-unknown function (
- No new functionality levels (first time in ADDS history)
- Backward compatibility should be better than ever
- Improvement of handling ADDS version store (memory buffer for handling database transactions)
What’s new in Active Directory 2019
Active Directory ESE Version Store Changes in Server 2019
Assuming that you already are familiar with the pre-requisites, options and recovery regarding update here is a guidance for the manual process.
ADDS Schema Version Numbers
|Version number||Operating System-level|
Performing ADDS Schema update
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 ADDS Health Check before commit updates
- Analyze schema classes and attributes, are ther any own added classes and attributes to ADDS schema? Tool for report found from here
- Perform ADDS forest recovery to isolated environment and perform schema update first in there. It’s a good way to practice recovery process at same time and verify that you backups are working
- Disaster Recovery Plan – DRP! This is mandatory in any environment and can save your in case of disaster
ADPREP is found from installation media from support\adprep folder
In production environment I’ll either disable replication before committing changes or perform update following Microsoft best practices (via server manager installation wizard aka live option).
If live option is selected make sure that your ADDS Forest Recovery plan is up to date and you know what to do in case of a disaster. Depending of schema update changes 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
Run forest wide preparation – adprep /forestprep command
Run domain wide prepations
- adprep /domainprep
- adprep /rodcprep (if haven’t ran earlier)
Validate preparations and remember to enable replication if it was disabled
To determine if adprep /forestprep completed successfully, you can use ADSIEdit and Event Viewer 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:
- CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=ForestRootDomainobject is set to 16 (remains same than in W2016)
- CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=ForestRootDomain object is set to 16 (W2016 = 15)
- CN=ActiveDirectoryRodcUpdate,CN=ForestUpdates,CN=Configuration,DC=ForestRootDomainobject is set to 2 – set when rodcprep is executed
- Enable replication: repadmin /options <DC NAME> -DISABLE_OUTBOUND_REPL (optional)
Search events 1898 and 1899 from Directory Services log to find corresponding events related to Schema update. There is only one new attribute for user, contact and group classes.
Event there aren’t basically new features or even new forest or domain levels I always recommend to update latest version to your on-premises infrastructure. Attribute which is created is ms-DS-Preferred-Data-Location which might be related to O365 Preferred Data Location feature which were published earlier in this year.
According to the Microsoft website, the schema level is 88, not 89. In my own testing that has also been the case.
You are absolutely right. It’s my mistake and I’ll fix it to the post. Thanks for raising this up. Those damn typos😊