Fix ERROR_DS_CANT_MOVE_RESOURCE_GROUP 0X00002133

This error stops you from moving a resource group across domains when it still has members. I'll show you three fixes, from quickest to most thorough.

What triggers this error

You're trying to move a resource group (a security group that's not universal) from one domain to another using Active Directory Users and Computers or PowerShell. The move fails with ERROR_DS_CANT_MOVE_RESOURCE_GROUP (0X00002133).

The real cause is simple: the group still has members inside it. Active Directory won't let you move a nonempty group across domain boundaries—it's a safety lock. This happens most often when you're reorganizing domains or merging companies, and you forgot to empty the group first.

Here's the fix path. Start with the first one—it takes 30 seconds. If that doesn't work, move to the moderate fix. Only the last one is for stubborn cases.

Quick fix (30 seconds): Move the group when it's empty

Open Active Directory Users and Computers on your domain controller. Right-click the group and pick Properties.
Go to the Members tab. You'll see a list of users, computers, or other groups. Select all members, then click Remove. Confirm when prompted.
After you remove everyone, you should see 0 members listed.
Now right-click the group again and choose Move. Point it to the target domain's OU. Click OK.
If the move succeeds, you're done. If you get the same error, you missed a hidden member—go to the moderate fix.

Expected outcome: After removing all members, the group should move without the 0X00002133 error. If it still fails, the group has nested groups or protected objects inside it.

Moderate fix (5 minutes): Use PowerShell to find and remove hidden members

Sometimes the GUI doesn't show all members—especially nested groups or built-in accounts. Here's a more thorough method.

Open PowerShell as Administrator on a domain controller.
Run this command to see every member (including nested groups):
```
Get-ADGroupMember -Identity "YourGroupName" -Recursive | Select-Object Name, ObjectClass
```
Replace YourGroupName with the actual group name. Hit Enter.
You'll see a list that includes direct and indirect members. Write down or copy the names.

Now remove them all with:

Get-ADGroupMember -Identity "YourGroupName" | ForEach-Object { Remove-ADGroupMember -Identity "YourGroupName" -Members $_.DistinguishedName -Confirm:$false }

This command removes only direct members. Nested group memberships get cleaned up automatically.

Run the move command again:

Move-ADObject -Identity "CN=YourGroupName,OU=SourceOU,DC=SourceDomain,DC=com" -TargetPath "OU=TargetOU,DC=TargetDomain,DC=com"

Adjust the distinguished name paths to match your setup.

If it succeeds, go add your members back manually or with a script. If it still fails, the group has protected objects—see the advanced fix.

Expected outcome: PowerShell should show the group as empty after the removal. The move command should complete without error.

Advanced fix (15+ minutes): Use ADSI Edit to check for protected objects

This is the nuclear option. I use it only when the other two fail. Some groups have protect from accidental deletion turned on, or contain system objects that block moves.

Log into your domain controller. Open ADSI Edit from the Tools menu in Server Manager.
Right-click ADSI Edit and choose Connect to. Keep the default naming context and click OK.
Browse to the group's DN. You can find it by right-clicking the group in ADUC and selecting Properties, then looking at the Distinguished Name field (you may need to enable Advanced Features first).
Right-click the group in ADSI Edit and choose Properties. Look for these attributes:
- member — any values here? Even a single empty value? Delete it.
- groupType — make sure it's set to -2147483646 for a global security group (that's the standard for resource groups). If it's different, change it but write down the original first.
- dSCorePropagationData — if this is missing or corrupted, it can cause ghost members. Don't delete it unless you know what you're doing.
Also check the Security tab of the group (ADUC). Under Advanced, look for any deny entries that block the move. Remove them temporarily, then try moving again.
If you still can't move the group, export its members, delete the group entirely, and recreate it in the target domain. Use this PowerShell to export members:
```
Get-ADGroupMember -Identity "YourGroupName" -Recursive | Select-Object Name, SamAccountName, ObjectClass | Export-Csv C:\GroupMembers.csv -NoTypeInformation
```
Then delete the group with ADUC, recreate it in the target domain, and import the members back.

Expected outcome: ADSI Edit reveals hidden attributes. Deleting the group and recreating it is the blunt fix—but it always works.

One last tip: Before you start, make sure you're running this from a domain controller or a machine with the RSAT tools installed. Also, you need Domain Admin rights in both domains. Without those, you'll get access denied even with an empty group.