Fix ERROR_DS_SRC_SID_EXISTS_IN_FOREST (0X0000215B)

Quick answer for advanced users

Run Get-ADObject -Filter {SIDHistory -like '*'} -Properties SIDHistory in the target forest to find the object that already has the SID, then clear its SIDHistory or delete the object. Then retry the migration.

What this error means

You're trying to migrate a user or group from one Active Directory forest to another (probably using ADMT or a script that copies SIDHistory). The error says the source object's SID already exists in the destination forest's SIDHistory attribute on some other object. Active Directory won't let you create a duplicate — it's a safety check to prevent two objects from claiming the same security principal. This commonly happens when you migrate an object, then try to migrate it again (re-migration) or when a previous migration attempt partially completed but left a ghost object behind.

I've seen this exact error when someone ran ADMT, the migration failed halfway, and the target object stuck around with a partial SIDHistory. The second attempt hit the wall. Another real scenario: you migrate a user named JohnDoe from Forest A to Forest B, then later try to migrate another user (maybe JaneDoe from a different domain in Forest A) whose SID happens to match an old SID already in Forest B. Rare, but possible if SIDs were recycled or manually assigned.

Step-by-step fix

1. Identify the duplicate SID. The error message in the event log or ADMT log should tell you the SID value. If it doesn't, open the migration log file (usually in C:\Windows\ADMT or C:\ADMT) and search for "0x215B" or "0X0000215B". Write down the exact SID, which looks like S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx.
2. Open PowerShell on a domain controller in the destination forest. Run as Administrator. You'll query the entire forest, so make sure you have Enterprise Admin rights or at least read access across all domains.
3. Find the object that already has this SID. Run this command, replacing S-1-5-21-xxx...-xxxx with the actual SID you found:

   Get-ADObject -Filter {SIDHistory -like '*S-1-5-21-xxx...-xxxx*'} -Properties SIDHistory, Name, ObjectClass | Format-List Name, ObjectClass, DistinguishedName, SIDHistory

   If the command returns nothing, the SID might be the object's primary SID (not SIDHistory). Check with:

   Get-ADObject -Filter {ObjectSID -eq 'S-1-5-21-xxx...-xxxx'} -Properties Name, ObjectClass, DistinguishedName | Format-List Name, ObjectClass, DistinguishedName

4. Decide how to handle the matching object. You have two choices:
   • Remove the SIDHistory entry from the object (if the object itself is valid and you don't need that SID in its history). Use this PowerShell command on the target object's DistinguishedName:

     Set-ADObject -Identity 'CN=JohnDoe,OU=Users,DC=target,DC=com' -Remove @{SIDHistory='S-1-5-21-xxx...-xxxx'}

     After running it, verify the SIDHistory is gone:

     Get-ADObject -Identity 'CN=JohnDoe,OU=Users,DC=target,DC=com' -Properties SIDHistory | Select-Object -ExpandProperty SIDHistory

     You should see either nothing or other SIDs that aren't the duplicate.

   • Delete the entire object if it's a leftover from a failed migration and you don't need it. Use:

     Remove-ADObject -Identity 'CN=JohnDoe,OU=Users,DC=target,DC=com' -Confirm:$true

     Type Y to confirm. I recommend this only if you're sure the object isn't being used for anything else. Check group memberships and any service dependencies first.

5. Retry the migration. Go back to ADMT or your migration tool and run the same migration again. It should proceed past the SID conflict check this time. If you still get the error, repeat step 3 — there might be more than one object with the same SID (unlikely but possible in a messy forest).

What if the SID belongs to a well-known or system object?

Sometimes the duplicate SID is on a built-in account like Administrator or Domain Admins. You can't delete those. Don't try to remove SIDHistory from them either — you'll break things. Instead, change the source object's SID before migration. That's an advanced move. You'd need to rename the source object's SIDHistory or create a new source user with a different SID. Honestly, it's easier to use a different target OU or container and do a fresh migration with a new target object. Or, if you can, modify the migration tool to use a different name mapping that skips the conflict.

Alternative fix: Use ADSI Edit to manually delete the SIDHistory

If PowerShell isn't available (e.g., on a Server Core install with limited modules), you can use ADSI Edit:

1. Open ADSI Edit from Administrative Tools.
2. Connect to the domain partition in the target forest.
3. Navigate to the object found in step 3.
4. Right-click the object, choose Properties.
5. Find the attribute sIDHistory, click Edit, select the duplicate SID, and Remove.
6. Click OK, close ADSI Edit.
7. Retry migration.

Be careful with ADSI Edit — it's a low-level tool. One wrong click and you corrupt an object. Stick with PowerShell unless you can't.

Prevention tip

Before any forest migration, run a full SIDHistory audit across both forests. Use this script to export all SIDHistory values from the target forest:

Get-ADObject -Filter {SIDHistory -like '*'} -Properties SIDHistory, Name, ObjectClass |
    Select-Object Name, ObjectClass, @{n='SIDHistory';e={$_.SIDHistory}} |
    Export-Csv -Path C:\TargetSIDHistory.csv -NoTypeInformation

Compare that to the source SIDs you plan to migrate. If any match, clean them up before starting. Saves you a call to the help desk at 2 AM.