Fix ERROR_DS_ADD_REPLICA_INHIBITED (0X0000206E)

You're in the middle of promoting a new domain controller. You run dcpromo or use Server Manager – maybe even Install-ADDSDomainController in PowerShell. Everything looks good until you get hit with:

ERROR_DS_ADD_REPLICA_INHIBITED
0X0000206E
The add replica operation cannot be performed.

I've seen this on Server 2016 and 2019 mostly. Had a client last month whose entire print queue died because of this – well, not directly, but the new DC they were adding was for a remote office that couldn't authenticate, and this error stalled the whole rollout. The trigger is usually one of two things: you're trying to add a replica to a domain where the schema master hasn't fully replicated, or the target domain controller doesn't have the necessary updates to act as a source.

Root Cause

Active Directory is picky about who can host a replica. The error means the source domain controller (the one you're replicating from) says 'I can't serve this replica right now'. That's not a permissions thing – it's a consistency thing. Specifically, the schema or naming context on the source DC hasn't finished replicating from the schema master. Or the source DC itself is missing critical updates that the schema master has applied. Think of it like trying to copy a file from a computer that hasn't finished downloading it. AD won't let you propagate a half-baked directory partition.

The fix is straightforward: make sure the source DC you're targeting has fully replicated from the infrastructure master and schema master. Also check the msDS-AllowedToCreateReplica attribute – though that's rare in small environments.

The Fix – Step by Step

Identify a healthy source DC – Don't use the PDC emulator if it's overloaded. Pick a DC that shows no replication errors. Run repadmin /replsum from an elevated command prompt. If any DC shows errors (like 8606 or 8453), fix those first.
Force replication from schema master – On your chosen source DC, open PowerShell as admin and run:
```
repadmin /syncall /AdeP
```
That forces a full replication across all directory partitions. Wait for it to complete. You'll see 'SyncAll completed' with no errors.
Check the schema version – On the source DC, run:
```
dsquery * cn=schema,cn=configuration,dc=yourdomain,dc=com -scope base -attr objectVersion
```
Compare that to your schema master. If they don't match, run adprep /forestprep on the schema master, then replicate again.
Verify the source DC is a global catalog – The source DC you're using must be a GC. Check in Active Directory Sites and Services under NTDS Settings. If it's not, tick the box and wait for replication.
Retry the promotion – Now go back to the new server and run the promotion again. In Server Manager, specify the source DC by name. Use the FQDN. In PowerShell:
```
Install-ADDSDomainController -DomainName yourdomain.com -ReplicationSourceDC source-dc.yourdomain.com -Credential (Get-Credential)
```

If It Still Fails

If you're still getting the error after that, check these three things:

DNS – The new server must point to an existing DNS server in the domain. Run nslookup yourdomain.com – if it fails, fix DNS delegation first.
Firewall – Port 389 (LDAP) and 135 (RPC) must be open between the new server and source DC. Also 445 (SMB) for initial replication.
Time sync – If the new server's clock is off by more than 5 minutes, Kerberos fails and so does replication. Use w32tm /resync against a domain DC.

Had one case where someone had renamed a DC but didn't demote it first. The lingering server object blocked the replica add. If you suspect orphaned DCs, run repadmin /options +DISABLE_NTDSCONN_XLATE to see hidden objects, then clean them with ntdsutil. That's advanced, but sometimes necessary.

Bottom line: this error is AD's way of saying 'hold up, I'm not ready'. Force replication, check schema version, and use a healthy GC source. That'll clear it 90% of the time.