Fix ERROR_DS_CROSS_DOM_MOVE_ERROR (0x2018) cross-domain move fails

Quick answer for advanced users

Check that the source object hasn't had its sAMAccountName or userPrincipalName changed recently. Then verify AD replication is current between all domain controllers. If those look good, the real fix is running repadmin /syncall /AdeP from both sides, then retrying the move with -AllowSchemaMismatch on ADMT if you're using that tool.

Why this error happens

I see 0x00002018 most often when someone tries to move a user or group between two domains in the same forest, but one of these things is out of sync:

• The object's sIDHistory attribute has a stale entry from a previous move.
• The schema master hasn't replicated the latest object class changes to all domain controllers.
• The target domain doesn't have the same schema extensions as the source (common after an Exchange or Skype upgrade on one side).

You'll usually hit this during a migration project, not day-to-day operations. It's especially common when using Active Directory Migration Tool (ADMT) version 3.2 or earlier, where it complains about a missing msExch* attribute even though Exchange is long gone.

Step-by-step fix

1. Open a command prompt as Administrator on a domain controller in the source domain. Don't do this from a workstation — we need replication tools.
2. Type repadmin /showrepl. Look for any lines that say "last success" more than 15 minutes ago. If you see failures, you need to fix replication first. Nothing else will work until that's clean.
3. Force a full sync by running repadmin /syncall /AdeP. Wait for it to complete. You should see "SyncAll completed successfully" with no error messages.
4. Check the object's security descriptor — this is the most common root cause. Open ADSI Edit, connect to the source domain's partition, and find the object you're trying to move. Right-click it and choose Properties. Find nTSecurityDescriptor. It should be present and not corrupted. If it's blank or shows an error, the object has a broken ACL.
5. If the security descriptor is bad, you can't fix it in-place. The safest path is to delete the object and recreate it in the target domain. I know that sounds harsh, but trying to repair a broken descriptor on a cross-domain move almost always fails. Take a screenshot of the group membership first.
6. If the descriptor looks fine, try the move again using Active Directory Users and Computers with the -AllowSchemaMismatch flag. In ADMT v3.2, that flag is under the Advanced options when you run a User Migration Wizard. It tells the tool to skip schema comparison checks.
7. Still failing? Open the Event Viewer on the domain controller that's handling the move. Look under Directory Service for event ID 1988 or 1699. Those will tell you exactly which attribute is causing the conflict.

Alternative fixes if the main steps don't work

1. Disable SID history on the source object. Use dsmod user "CN=John Doe,CN=Users,DC=source,DC=com" -sidhistory $null. Then retry the move. You can re-enable SID history after the move completes.
2. If you're using ADMT and the error mentions msExchMailbox, go to your Exchange server (or the last one that existed), run Get-Mailbox -Identity "John Doe" | Disable-Mailbox, then wait for replication and try again. That attribute gets orphaned sometimes.
3. As a last resort, rebuild the object manually in the target domain. Export the source object's attributes using csvde -f export.csv -r "(cn=John Doe)", then import to the target domain with csvde -i -f export.csv. This skips the move logic entirely.

How to prevent this error

Before any cross-domain move, run repadmin /syncall /AdeP on every domain controller in both domains. Also check that all domain controllers run the same schema version — repadmin /schema will show you. If you see version mismatches, seize the schema master role to the DC with the highest version. That'll catch 90% of these failures before they happen.