Active Directory error 0x00002039 when moving objects between OUs

When this error shows up

You're in Active Directory Users and Computers (ADUC), you right-click a user or group, choose Move, pick a different Organizational Unit (OU) — and get slapped with:

Operation failed with error 0x00002039:
The operation affects multiple DSAs

I've seen this most often on Windows Server 2019 domain controllers when someone tries to move a user from the Users container to a new OU under the same domain. But it also happens with groups, computers, and even GPO links. The exact trigger is any move operation that AD's internal consistency check flags as spanning multiple directory system agents (DSAs).

What's actually happening here

The error name ERROR_DS_AFFECTS_MULTIPLE_DSAS tells you the story. AD is built on partitions — each domain is its own partition, and each domain controller hosts replicas of those partitions. When you move an object, AD checks if the source and target OU live in the same naming context. If they don't, the move touches more than one DSA (directory system agent), and AD blocks it.

The common gotcha? You're trying to move an object between OUs that look like they're in the same domain, but one of them is actually a referenced object from another domain. For example, a user from Domain A that has a manager attribute pointing to Domain B. AD sees the move as affecting both Domain A's and Domain B's DSAs. It says no.

Another case: the target OU itself is a cross-domain reference (like a foreign security principal). AD doesn't support moving objects across domain boundaries — even if the UI shows both in the same console.

The fix: force the move with PowerShell and check attributes

1. Check if the object can be moved normally

   Open ADUC, right-click the object, choose Properties, go to the Object tab. Look at the Canonical Name — that shows the full path. If it says domain.com/Users/ObjectName and you're moving to domain.com/NewOU, same domain = should work. If you see a different domain, you're trying a cross-domain move. That won't work with standard Move.

2. Use PowerShell with -AllowCrossDomainMove

   Open PowerShell as Domain Admin. Run:

   Move-ADObject -Identity "CN=JohnDoe,CN=Users,DC=domain,DC=com" -TargetPath "OU=NewOU,DC=domain,DC=com" -AllowCrossDomainMove

   The -AllowCrossDomainMove flag forces AD to do a cross-domain move. But be warned: this only works if the target is actually in the same forest. If the target is in a different forest entirely, you need ADMT (Active Directory Migration Tool).

3. Check for lingering cross-domain references

   If the move still fails, the object might have attributes pointing to other domains. Run:

   Get-ADUser -Identity "JohnDoe" -Properties * | Select-Object manager, memberOf, directReports

   If manager points to a user in another domain, temporarily clear it:

   Set-ADUser -Identity "JohnDoe" -Manager $null

   Do the same for any attribute that references outside the source domain. After the move, you can re-add them.

4. Move using ADSI Edit as last resort

   Open ADSI Edit, connect to the domain partition. Navigate to the object, right-click, choose Move. Browse to the target container. ADSI Edit doesn't do the consistency check that ADUC does. This works when everything else fails. But be careful — that check exists for a reason. Cross-domain moves can break group memberships.

What to check if it still fails

• Are you hitting a schema conflict? Some objects (like Exchange recipients) have schema extensions that tie them to specific OUs. Check if the object belongs to an application partition (like Microsoft Exchange or Lync). Those can't be moved without the app's tools.
• Do you have replication issues? Run repadmin /replsummary on the domain controller. If replication is broken, the move might fail because the target DC doesn't have the latest partition info.
• Is the target OU in a different site? AD doesn't care about sites for moves, but if the target OU is in a different domain tree (same forest), you're doing a cross-domain move. Use ADMT or third-party tools.
• Check the security on the target OU. If you don't have write permissions on the target, you'll get a different error (access denied), but sometimes AD masks it as this code. Verify your account has Create All Child Objects permission on the target OU.

Bottom line: 0x00002039 is AD saying "I think you're crossing boundaries." If you're confident you're not, the PowerShell workaround gets you there. If you actually are crossing domains, use ADMT or re-think the directory design.