Fix Active Directory Error 0X0000208B

What's Actually Happening Here

This error pops up when Active Directory decides it can't create an object under a parent container because the two don't match on something called "replication type." One's a master object, the other's a replica. AD hates that. I had a client last month whose entire print queue setup failed because they tried to create a printer object under a replicated organizational unit that was actually a master copy from another domain controller. Took me 20 minutes to untangle.

The error message: ERROR_DS_CANT_MIX_MASTER_AND_REPS (0X0000208B) — "The object and parent must be of the same type, either both masters or both replicas."

Ninety percent of the time this is a metadata mismatch after a failed replication or a bad ADSI Edit change. Here's the flow to kill it.

The 30-Second Fix: Check Object Types

Before you dive into anything else, rule out the dumb stuff. Open ADSI Edit (make sure you're connected to the right domain — I've seen people connect to the wrong one and waste an hour).

Launch ADSI Edit (mmc > Add/Remove Snap-ins > ADSI Edit).
Right-click ADSI Edit > Connect to... > Select a well-known Naming Context: Configuration.
Navigate to CN=Partitions,CN=Configuration,DC=yourdomain,DC=local.
Find the partition that's causing trouble — usually the one where you're trying to create the object.
Check the attributes msDS-Replication-Type and msDS-Replica. If the parent object has msDS-Replication-Type: 0 (master) and the child you're creating is set to replica (type 1), that's your mismatch. The fix: change the child object's replication type to match the parent. Right-click the child object > Properties > find msDS-Replication-Type and set it to 0 (master).

If you don't see the child object at all because you can't create it, then skip to the moderate fix.

Real-world trigger: This usually happens when someone manually created a partition via ADSI Edit instead of using the proper GUI tools, or after a domain controller demotion that left orphaned metadata.

The 5-Minute Fix: Clean Replication Metadata with Repadmin

If the simple check didn't work, replication metadata is probably stale. Use repadmin — you don't need third-party tools.

Open Command Prompt as Administrator on a domain controller that's seeing the error.

repadmin /showobjmeta * "DC=yourdomain,DC=local" | findstr /i "0X0000208B"

That dumps metadata for the entire domain partition. Pipe it through find or findstr if you're hunting for a specific object. Look for anything with msDS-Replication-Type or msDS-Replica that shows version mismatch — different version numbers on different domain controllers.

If you spot a mismatch, force replication:

repadmin /syncall /AdeP

Then check if the error's gone by trying to create the object again. If not, you need to remove the stale metadata.

repadmin /removeholding DC=yourdomain,DC=local /cleanup

Caution: This command can nuke the object if you're not careful. Use it only when you're sure the metadata is orphaned — meaning the object doesn't exist on any other domain controller. I've used this on a client's server after a failed domain rename. Worked like a charm.

After running that, close the command prompt and try creating the object again. If it still fails, move to the advanced fix.

The 15+ Minute Fix: Rebuild the Object and Parent Relationship

This is the nuclear option — for when the metadata is so hosed that ADSI Edit and repadmin can't sort it. This happened to me on a Server 2019 DC after a borked in-place upgrade.

Step 1: Identify the exact object and parent. You need both DNs. Use LDP or ADSI Edit to browse the partition and note the distinguished names. For example:

Parent: OU=Printers,DC=contoso,DC=local
Child: CN=PrinterConfig,OU=Printers,DC=contoso,DC=local

Step 2: Export the problem object's attributes. Use LDIFDE to create a backup before you delete anything.

ldifde -f childobject.ldf -d "CN=PrinterConfig,OU=Printers,DC=contoso,DC=local"

Step 3: Delete the orphaned child object. In ADSI Edit, right-click the child object > Delete. If it won't delete because of permissions, use dsrm with the -subtree flag from an elevated command prompt.

dsrm "CN=PrinterConfig,OU=Printers,DC=contoso,DC=local" -subtree -noprompt

Step 4: Recreate the object with the correct replication type. Use ADSI Edit to create the child object again. Right-click the parent > New > Object. Choose the correct class (e.g., printQueue). Before you click OK, edit the msDS-Replication-Type attribute to match the parent's value. If the parent is master (type 0), set the child to master too.

Pro tip: If you're creating an object that needs to be a replica (like a system container), set the type to 1. But 99% of the time with this error, the parent is master and you're trying to create a replica child. Switch it to master.

Step 5: Import the attributes you exported earlier.

ldifde -i -f childobject.ldf

This restores the original attributes without the replication type conflict. Verify the object appears and no error pops up when you try to modify it.

Still broken? Sometimes the issue is deeper — a schema mismatch across domain controllers. Run dcdiag /test:replications /v to check for other DCs with conflicting replication metadata. If you find one, either force sync or demote and promote that DC. I've had to do that only twice in ten years, but when it's needed, it's the only fix.

That's it. Start with the 30-second check, escalate if you have to. Most people stop after the repadmin step. You're welcome.