Fix AD object class mismatch error 0x0000215C when moving users

When does this error hit you?

You're in Active Directory Users and Computers (ADUC), dragging a user account from one OU to another, or maybe running an ADMT migration script. Suddenly, you get slapped with a modal dialog: "The source and destination object must be of the same type" — error code 0x0000215C. I've had this pop up at 3 PM on a Friday when I was moving a batch of disabled users to a "To Delete" OU. It's frustrating because the move operation looks perfectly valid.

Root cause in plain English

Active Directory is strict about object class inheritance. You can't move a user object into a container that expects computer objects, or a group into a printQueue container. The error means the destination container's objectClass (or poss-superiors list) doesn't allow the type you're trying to move there. Think of it like trying to put a square peg into a round hole — AD won't let you do it.

The most common trigger is moving a user into an OU that was originally created for computers, often because someone used a template script or bulk-created OUs with wrong class restrictions. Another scenario: you're using ADMT across forests and the destination container has a different systemFlags or objectCategory that blocks the move.

Step-by-step fix

1. Identify the destination container type. Open ADSI Edit (it's part of RSAT — install it if you haven't). Connect to the domain partition, then browse to the destination container. Right-click it → Properties. Look at the objectClass attribute. Typical ones: organizationalUnit, container, builtinDomain. If it says computer or printQueue, you're targeting the wrong container.
2. Check the source object type. In ADSI Edit, find the source object you're trying to move. Check its objectClass too. If it's a user (user or inetOrgPerson), the destination must allow that class. If the destination is a computer-only container, you can't move a user there.
3. Fix the destination container type if needed. If you must move the object to that specific container (maybe it's a legacy OU), you can change the container's systemFlags or objectClass using ADSI Edit, but don't modify objectClass directly — that can break AD. Instead, remove the restrictive systemFlags that disallows certain objects. Look for systemFlags value 0x00000001 (which means "this container only holds objects of type X"). Set it to 0x00000000 or remove it entirely. I've done this maybe three times in 20 years — it's rare but works.
4. Use ADUC with advanced features. In ADUC, go to View → Advanced Features. Right-click the destination container → Properties → Attribute Editor tab. Find systemFlags and verify it's not set to restrict object types. If it's 0x00000001, you can set it to 0 (zero). Apply and retry the move.
5. Move via PowerShell as a quick test. Run Move-ADObject -Identity "CN=John Doe,OU=OldOU,DC=domain,DC=com" -TargetPath "OU=NewOU,DC=domain,DC=com". If it still fails, PowerShell will give you a more detailed error than ADUC. I saw this once where the target path had a typo — ADUC hid it, PowerShell didn't.

What if it still fails?

If you've verified the destination container type and it still bombs, check these:

• Protected from accidental deletion. Right-click the source object → Properties → Object tab. Is the checkbox "Protect from accidental deletion" checked? Uncheck it, then try the move again. ADMT sometimes throws this error when the source object is protected.
• Replication lag. If you just created the destination OU on another domain controller, changes might not have replicated. Run repadmin /syncall from an elevated command prompt. Wait 30 seconds, then retry. Had a client last month whose entire print queue died because of this — they created a new OU on a remote DC and tried to move objects instantly.
• ADMT version mismatch. If you're doing cross-forest migration, ADMT 3.2 is finicky about object class mapping. Update to the latest version from Microsoft's download center, and make sure the source and destination forests have matching schema (run adprep /forestprep and adprep /domainprep on the target).
• Third-party tools. Some backup/restore tools or identity management systems create custom containers with weird objectClass values. If you see msExch* or msFVE-RecoveryInformation in the container's class list, you're dealing with Exchange or BitLocker recovery data — don't move standard user objects there.

One last piece of advice: before you start clicking around in ADSI Edit, take a domain-level backup of Active Directory. You're poking at attributes that can send your domain into a boot loop if you mistype a value. I learned that the hard way in 2018 — had to restore from a week-old backup because I changed an objectClass to organizationalUnit on a container that was holding all your Exchange mailbox databases. Don't be that guy.