ERROR_DS_DRA_REF_ALREADY_EXISTS (0x2100) Fix – AD Replication

You're trying to promote a new domain controller, maybe reusing the same hostname as an old one, and boom – you get ERROR_DS_DRA_REF_ALREADY_EXISTS with hex code 0x00002100. The full message says "The replication reference information for the target server already exists". This happened to a client of mine last month who had a server crash mid-demotion and then tried to rebuild the exact same box.

The root cause is simple: Active Directory still thinks there's a domain controller with that name or NTDS Settings object somewhere. When you try to add another one, DRA (Directory Replication Agent) sees the reference and refuses to create a duplicate. Most of the time it's from a failed uninstall of AD DS, a reimaged server with the same name, or a lingering server object in sites and services.

Fix it with metadata cleanup

Don't waste time checking DNS or replication – the fix is cleaning up the old reference. Here's the step-by-step, straight from the console.

Step 1: Identify the offending server object

Open Active Directory Users and Computers. Go to the Domain Controllers OU. Look for the server name you're trying to promote. If it's there and grayed out or still listed, that's your problem. If not, it might be in the Sites and Services console under the default-first-site-name or wherever your servers live.

Also check Active Directory Sites and Services – expand Sites > your site > Servers. If the server name shows up there with an NTDS Settings object, that's the reference causing the error.

Step 2: Use ntdsutil to remove the metadata

This is the nuclear option but it's what works. Open an elevated command prompt on any domain controller (doesn't have to be the one with the error).

ntdsutil
metadata cleanup
connections
connect to server <existing_dc_name>
quit
select operation target
list domains
select domain 0
list sites
select site 0
list servers in site
select server 0 (choose the problematic one)
quit
remove selected server

Type yes when prompted. Then quit ntdsutil. This removes the old NTDS Settings object and the replication reference. I've done this dozens of times – it's safe if you're sure the server is gone for good.

Step 3: Delete leftover objects manually

After the metadata cleanup, go back to AD Sites and Services. Delete the server object from under Servers if it's still there. Also check AD Users and Computers – delete the computer account from the Domain Controllers OU. Don't forget the LostAndFound container – I've seen orphaned objects hide there.

Step 4: Verify DNS

Open DNS Manager. Look under Forward Lookup Zones > your domain > _msdcs. Check for old A records or CNAME records pointing to the removed server. Delete any that reference the old hostname. Also check the _tcp and _udp folders – clean out old SRV records for that server.

Run a quick repadmin /syncall /AdeP after cleanup to push the changes.

Step 5: Retry the promotion

Now go back to your new server and try promoting it. On a clean system with no lingering references, it should work. I've seen this fix work even when the old server was literally still powered on but corrupt.

If it still fails

Double-check you're not dealing with a lingering object in the Configuration partition. Run this in PowerShell as admin:

Get-ADObject -Filter {Name -like "*yourServerName*"} -SearchBase "CN=Configuration,DC=yourdomain,DC=com" | fl Name,DistinguishedName

If you find something, delete it with Remove-ADObject – but be sure it's not a real DC. Also verify replication is healthy between all existing DCs – run repadmin /replsummary. If there's a replication backlog, the metadata cleanup might not have synced. Wait a few minutes or force replication with repadmin /syncall.

Last resort: check the Sysvol folder for stale entries. But 9 times out of 10, the ntdsutil steps above will kill this error. Had a client once who spent two days reinstalling before I cleaned it in ten minutes.