Fix ERROR_DS_DRA_INVALID_PARAMETER (0x000020F5) in AD replication

1. Stale metadata from a dead domain controller

This is the one I see most often. You’ll get the 0x000020F5 error when a domain controller that was removed improperly still has lingering metadata in Active Directory. Happened last month with a client who yanked a DC out of the rack without demoting it first. The replication partner tries to contact that dead DC, gets back garbage, and throws this error.

How to check: Open an elevated command prompt and run:

repadmin /showrepl

Look for any entries that say last success is never or show a server name that no longer exists.

The fix: Clean up that stale metadata using ntdsutil. Here’s the fast way:

1. Open an elevated command prompt.
2. Type ntdsutil and press Enter.
3. Type metadata cleanup and press Enter.
4. Type connections and press Enter.
5. Type connect to server <YourWorkingDC> (replace with your good DC’s name).
6. Type quit to go back.
7. Type select operation target.
8. Type list domains, note the domain number (usually 0).
9. Type select domain 0.
10. Type list sites, note the site number.
11. Type select site 0.
12. Type list servers in site. Find the dead DC’s number.
13. Type select server <number>.
14. Type remove selected server. Confirm yes.
15. Type quit twice to exit.

After that, force replication with repadmin /syncall /AdeP. Usually clears the error within a minute.

2. Schema partition mismatch

Less common but nasty. If the schema master DC has a different schema version than the replication partner, you’ll see this error. I saw this when a client applied a schema update to only one DC in a multi-domain forest. The DCs didn’t agree on what’s valid, so the replication call failed with the invalid parameter error.

Check schema version: On each DC, run this in PowerShell:

Get-ADObject -Identity "CN=Schema,CN=Configuration,DC=forest,DC=root" -Properties objectVersion | fl objectVersion

Or use ADSI Edit. Navigate to CN=Schema,CN=Configuration,DC=forest,DC=root. Look at the objectVersion attribute. All DCs in the same forest should show the same number. Common versions: 13 (2003), 30 (2008), 39 (2008 R2), 44 (2012), 56 (2012 R2), 69 (2016), 87 (2019), 89 (2022).

Fix it: If one DC has a higher schema version, you need to update the others. Run adprep /forestprep from the schema master. Then run adprep /domainprep on each domain. Reboot the DCs. Then force replication. If the version is lower on the schema master, well, you’ve got a bigger problem – contact Microsoft support, because you can’t roll back a schema update without a backup.

3. Replication link targeting a different naming context

This one’s trickier. The error can pop up if a replication link points to a partition that doesn’t match between the source and destination. I had a client who manually created a connection object in Sites and Services and got the partition wrong. The replication engine tried to sync the Domain partition with a Configuration partition – instant 0x000020F5.

How to find it: Run:

repadmin /showconn *

Look for any connection that has a transportType or enabledConnection that looks weird. Also check the repsFrom and repsTo attributes:

repadmin /showrepl * /ncwithtype

Compare the Source DSA and Naming Context values. They should match across all partners.

Fix it: Delete the bad connection object in Active Directory Sites and Services. Expand the site, the server, the NTDS Settings. Right-click the bad connection and delete it. Then either let AD automatically create a new connection or manually create a new one with the correct partition selected. After that, run repadmin /syncall /AdeP again.

If you’re in a pinch and just need replication working now, you can also try clearing the replication queue on the affected DC:

repadmin /queue *

Find the hung replication tasks and use repadmin /options +DISABLE_OUTBOUND_REPL then repadmin /options -DISABLE_OUTBOUND_REPL to flush it. But that’s a band-aid – still need to fix the root cause.

Quick-reference summary table

Most of the time it’s the stale metadata. Start there. If that doesn’t work, check the schema version, then the connection objects. This error is almost always a configuration problem – not a network or permissions issue – so don’t waste time chasing dns or firewall logs.