Fix 0X000021C8: Duplicate UPN in Active Directory Forest

What Triggers 0X000021C8

This error slaps you across the face when you try to modify a user or computer object in Active Directory, and something else in the forest already claims that User Principal Name (UPN). Had a client last month whose entire HR onboarding pipeline broke because two contractors got assigned the same UPN — one was a shadow account from a merger nobody cleaned up. The forest won't let you proceed until you kill the duplicate.

The error code 0X000021C8 maps to ERROR_DS_UPN_VALUE_NOT_UNIQUE_IN_FOREST. It hits in Windows Server 2012 R2 through 2022, and it can also appear during realm joins or Azure AD Connect syncs if UPNs collide across domains.

Simplest Fix (30 Seconds) — Check the UPN You're Entering

Before you dive into the weeds, verify you're not accidentally typing a UPN that already belongs to another user. This is stupid and happens more than you'd think.

1. Open Active Directory Users and Computers (dsa.msc).
2. Right-click your domain and select Find (or hit Ctrl+F).
3. In the Find dropdown, choose Users, Contacts, and Groups.
4. In the In field, pick Entire Directory (this searches the whole forest).
5. Enter the full UPN you're trying to assign — e.g., jsmith@contoso.com — in the User Logon Name field.
6. Click Find Now.

If you get any result, that UPN is taken. Pick something unique, or move to the moderate fix. If no results appear, you might have a replication delay or the duplicate is in a different forest (unlikely if it's the same forest).

Also check User Logon Name (pre-Windows 2000) — that's a different field, but sometimes people confuse them. Had a guy once type his UPN into the pre-2k field by accident. The error doesn't fire for that, but it's worth a glance.

Moderate Fix (5 Minutes) — Find and Remove the Duplicate Object

If the UPN isn't a typo, you've got a real duplicate somewhere. The fastest way to find it is with PowerShell. Run this as a domain admin from any DC or a management machine with RSAT tools.

Get-ADForest | Select-Object -ExpandProperty Domains | ForEach-Object {
    Get-ADObject -Filter "UserPrincipalName -like '*yourdomain.com'" -Properties UserPrincipalName -Server $_ |
        Group-Object UserPrincipalName | Where-Object { $_.Count -gt 1 } |
        Select-Object @{Name="UPN";Expression={$_.Name}}, Count, @{Name="Objects";Expression={$_.Group.DistinguishedName}}
}

Replace yourdomain.com with your actual UPN suffix. This script iterates every domain in the forest and spits out any UPN that appears more than once. You'll get something like:

UPN                  Count Objects
jsmith@contoso.com     2   {CN=John Smith,OU=Users,DC=contoso,DC=com, CN=JS1234,CN=Users,DC=sub,DC=contoso,DC=com}

Once you have the two objects, decide which one is bogus. Usually it's a stale user, a disabled computer, or a service account that was copied instead of created fresh. Delete or disable the duplicate — or change its UPN to something unique.

To change the UPN on the duplicate object, use:

Get-ADUser "CN=JS1234,CN=Users,DC=sub,DC=contoso,DC=com" | Set-ADUser -UserPrincipalName "jsmith-stale@contoso.com"

Or delete it clean:

Remove-ADUser -Identity "CN=JS1234,CN=Users,DC=sub,DC=contoso,DC=com" -Confirm:$false

If it's a computer object, use Get-ADComputer and Set-ADComputer instead.

Advanced Fix (15+ Minutes) — Forest-Wide UPN Conflict from Replication or Schema Issues

Sometimes the duplicate isn't obvious because replication hasn't caught up, or the UPN suffix itself is misconfigured. You'll know you're here if the moderate fix found nothing, but the error still fires.

Step 1: Force Replication Across All Domain Controllers

If you just deleted a user and the error persists, other DCs might still have the old object in their local copy. Force a sync:

repadmin /syncall /AdeP

Run this from your PDC emulator (the DC holding the PDC role). Wait 30 seconds and try your UPN change again. If it works, you're done. If not, move on.

Step 2: Check All UPN Suffixes in the Forest

Sometimes the duplicate is across alternate UPN suffixes. For example, two domains might use @company.com but one object has a typo like @cimpany.com. Run:

Get-ADForest | Select-Object -ExpandProperty UPNSuffixes

If you see suffixes that don't match your routing domain or that are duplicates (shouldn't happen, but I've seen it), remove the bad one:

Set-ADForest -UPNSuffixes @{Remove="bad-suffix@dead.com"}

Then re-add the correct suffix if needed:

Set-ADForest -UPNSuffixes @{Add="company.com"}

Step 3: Dump All UPNs and Look for Hidden Conflicts

Some objects — like service accounts in the System container or Disabled Users hidden from normal ADUC views — don't show up in standard searches. Run a forest-wide dump:

$allUPNs = @()
Get-ADForest | Select-Object -ExpandProperty Domains | ForEach-Object {
    $allUPNs += Get-ADObject -Filter "UserPrincipalName -like '*'" -Properties UserPrincipalName -Server $_
}
$allUPNs | Group-Object UserPrincipalName | Where-Object { $_.Count -gt 1 } | Format-Table -AutoSize

This catches objects that aren't users or computers — like iNetOrgPerson objects or group managed service accounts. If you find one, delete or rename it as before.

Step 4: Last Resort — Schema Check

If you still get the error and no duplicates exist, your schema might be corrupted. This is rare, but I've seen it after a failed domain controller promotion. Check the event logs on all DCs for Event ID 1644 or 1988 under Directory Service. These point to internal DS consistency issues. You'll need to open a case with Microsoft at that point — not something you DIY without risking the forest.

Pro tip: Always note which object you were modifying when the error appeared. The object's DN gives you a clue which domain and OU to focus on. Writing it down saves 10 minutes of searching.

Preventing This From Happening Again

Once you've stomped the duplicate, lock down UPN creation. Use a naming standard — like firstname.lastname@domain.com — and enforce it with a provisioning script. Also run a weekly check:

Get-ADForest | Select-Object -ExpandProperty Domains | ForEach-Object {
    Get-ADUser -Filter * -Properties UserPrincipalName -Server $_ |
        Where-Object { [string]::IsNullOrEmpty($_.UserPrincipalName) -eq $false } |
        Group-Object UserPrincipalName | Where-Object { $_.Count -gt 1 }
}

Schedule it as a logon script or a scheduled task. That way you catch collisions before anyone hits the error.

And if you're using Azure AD Connect, set it to block duplicates — check the Stop processing if UPN conflict detected option in the sync rule. Saves you a headache down the road.