Fix ERROR_DS_FOREST_VERSION_TOO_HIGH (0X00002173)

What This Error Means

You're staring at ERROR_DS_FOREST_VERSION_TOO_HIGH (0X00002173) on a domain controller. The forest's schema version is higher than what this DC supports. It can't replicate or promote until you fix the mismatch. I've seen this most often when someone tries to add a Windows Server 2012 R2 DC into a forest that's been updated to Windows Server 2016 or 2019 schema levels. Or when a forest upgrade using adprep /forestprep failed partway through.

The culprit here is almost always schema version drift. You upgraded the schema on one DC, but the other DCs haven't caught up. Or the new DC's OS version is too old for the current forest functional level.

Don't bother with rebooting or running dcdiag first — that rarely helps here. Start with the simplest check.

Fix 1: 30-Second Check — Verify Forest Functional Level

Open Active Directory Domains and Trusts on any working DC. Right-click the root domain, choose Raise Forest Functional Level. If you see a higher level than the DC you're stuck on supports, you've found the mismatch.

Here's the blunt truth: you can't lower the forest functional level. Microsoft doesn't allow it. The only way out is to either update the failing DC's OS or fix a stalled schema update.

If you're trying to add a Server 2008 R2 or 2012 R2 DC into a forest at Windows Server 2016 level, stop. You need to upgrade that server to a supported OS first. If the forest is at 2012 R2 and you're seeing this, move to Fix 2.

Fix 2: 5-Minute Moderate Fix — Rerun adprep /forestprep

This error often pops up when adprep /forestprep didn't complete successfully on all replicating DCs. Here's how to fix it:

1. Log into the Schema Master FSMO role holder. Find it with netdom query fsmo.
2. Open an elevated command prompt on that DC.
3. Run:

adprep /forestprep

If it completes without error, run:

adprep /domainprep /gpprep

Now force replication. Use:

repadmin /syncall /AeD

Wait 5 minutes and try whatever operation gave you the 0X00002173 error again. This fixes maybe 60-70% of cases I've handled.

If you get an error like "Adprep cannot contact the schema master" or "The schema version is already the target", then your schema version is already correct — the problem is elsewhere. Move to Fix 3.

Fix 3: 15+ Minute Advanced Fix — Schema Version Check and Manual Update

When adprep won't run and the error persists, you need to check the actual schema version number. This is the heavy lift.

Step 1: Find the Current Schema Version

On a working DC, open ADSI Edit. Connect to the Schema partition. Right-click CN=Schema,CN=Configuration,DC=yourdomain,DC=com, choose Properties. Look for objectVersion. Here are the values:

If the version is higher than what your problem DC's OS supports, you've got a forest that requires a newer OS. For example, objectVersion 87 means the forest needs at least Server 2016. Your Server 2012 R2 DC can't join.

Step 2: Repair a Stalled Schema Update

If the schema version is correct but the error still occurs, the update may be stuck on a specific DC. Force replication with:

repadmin /replicate <problemDC> <sourceDC> CN=Schema,CN=Configuration,DC=yourdomain,DC=com

Replace the placeholders with actual DC names.

If replication still fails, check the problem DC's DSRM directory services restore mode password. Then boot into DSRM and run:

ntdsutil
activate instance ntds
files
integrity
quit
quit

This checks the database integrity. A corrupt database can block schema updates. If it finds errors, run repair from the same menu.

Step 3: Last Resort — Force Schema Update via Registry

Only try this if you're desperate and have a full forest backup. On the problem DC, open Regedit. Navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Look for a value named Schema Version. If it exists and is lower than the actual forest schema version, you can update it to match — but this is dangerous. One typo and the DC won't boot. I've done this maybe 5 times in 14 years. Only do it if you have no other option.

After any schema fix, always run repadmin /replsummary to confirm replication is healthy. Then verify the error is gone by attempting the original operation.

If none of this works, you're looking at a demotion and clean reinstall of that DC. It's rare, but sometimes corruption runs too deep. You did take a system state backup before starting, right?