Small Town Sysadmin
Free CJIS checklist

Field notes

Field note: two Microsoft 365 accounts for one person, and two different fixes

Directory sync left a user with a duplicate account twice, in two different shapes. Here's how to tell which shape you have and how each one was fixed.

Two different offices, two different users, same complaint. The person had two accounts in Microsoft 365: the real one with their mailbox and licenses, and a second one on the tenant’s .onmicrosoft.com name that nobody created on purpose. Both offices sync their on-premises Active Directory to Entra ID with Entra Connect.

They looked identical from the outside. They weren’t, and the fix depended on which account was the synced one.

First, find out which account is synced

This one question decides everything. In Microsoft Graph PowerShell:

Get-MgUser -Filter "startsWith(userPrincipalName,'jane.doe')" -Property DisplayName,UserPrincipalName,OnPremisesSyncEnabled,OnPremisesImmutableId |
    Format-List DisplayName,UserPrincipalName,OnPremisesSyncEnabled,OnPremisesImmutableId

OnPremisesSyncEnabled : True means the account comes from on-premises AD. A synced account can’t be deleted from the cloud, and its anchor (OnPremisesImmutableId) can’t be cleared there either. If you try, the next sync just puts it back.

Case 1: the mailbox account was cloud-only, and sync made a new one

What happened: The user’s on-premises UPN still used the internal .local suffix. Microsoft 365 can’t use a .local name, so when sync picked the user up, it created a brand-new account on the .onmicrosoft.com name instead of matching the existing mailbox account.

What I tried first: stamping the on-premises anchor onto the mailbox account to force a match. It fought back with an address conflict, so I took the cleaner route.

What worked:

  1. Deleted the cloud-only duplicate so only the synced object was left.
  2. Changed the user’s on-premises UPN to the real email domain:
Set-ADUser -Identity "jane.doe" -UserPrincipalName "[email protected]"
  1. Ran a delta sync on the Entra Connect server:
Start-ADSyncSyncCycle -PolicyType Delta
  1. Reassigned the licenses to the synced account and confirmed the UPN and mail address both showed the real domain.

The routable domain has to be added as a UPN suffix in AD and verified in Entra ID for step 2 to stick.

Case 2: the reverse

What happened: This time the stray .onmicrosoft.com account was the synced one, and it held the user’s on-premises anchor. The real mailbox account was cloud-only. Because the stub was synced, I couldn’t delete it or clear its anchor from the cloud.

What worked: take the user out of sync for a minute, which makes the stub go away, then hand the anchor to the right account.

  1. Moved the user’s AD account into an OU that Entra Connect doesn’t sync, then ran a delta sync. The stub moved to Deleted users in Entra.
  2. Purged it from Deleted users so the anchor was free:
Get-MgDirectoryDeletedItemAsUser -All | Where-Object { $_.UserPrincipalName -like "*jane.doe*onmicrosoft*" }
Remove-MgDirectoryDeletedItem -DirectoryObjectId "<Id from above>"
  1. Stamped the anchor onto the real mailbox account:
Update-MgUser -UserId [email protected] -OnPremisesImmutableId "<the user's ImmutableId>"
  1. Moved the AD account back to its normal OU and ran another delta sync. On-premises hard-matched to the mailbox account.

The check afterward showed one account, synced, on the right UPN, with the mailbox and licenses untouched. Moving the AD account between OUs didn’t sign the user out or change their password, so they kept working the whole time.

What I took away from it

  • Check OnPremisesSyncEnabled on both accounts before you touch anything. It tells you which fix you need.
  • A synced object only goes away by taking it out of sync scope on-premises.
  • Keep on-premises UPNs on a real, routable domain. A .local UPN is how Case 1 started.
  • Verify with Get-MgUser after every step, not just at the end.

If the account looks fine but the user still can’t sign in with their email address, see the UPN mismatch field note.

Sources

All articles