Sharepoint fix mismatch user id

Treat a SharePoint “user ID mismatch” as an identity-reconciliation issue. If the account was reused, check whether the site’s UserInfo entry is stale; if it is, fix that mapping before changing permissions. Ignoring the mismatch can leave valid users locked out while you chase the wrong group or role. This guide shows how to tell a stale UserInfo record from a normal permission problem, then remediates the right one.

What the error means

If you see Access denied, a legacy user account message, or a OneDrive URL with a suffix added to the expected path, start by assuming SharePoint is matching the wrong identity record. The fastest first check is the Microsoft 365 admin center Site User Mismatch diagnostic run by a SharePoint administrator account, with the affected user and original site URL ready (per Microsoft support).

Separate identity mismatch from plain permissions loss

A normal permission failure usually leaves the identity record intact. A mismatch means the site still points at an old ID, so re-sharing alone can miss the real problem. Microsoft says the same issue can affect SharePoint Online and OneDrive for Business, and it can show up as inconsistent access rather than a single clean error code (per Microsoft support).

Check whether SharePoint or OneDrive is affected

Look at where the denial appears. If only one site fails, the stale entry may be local to that site. If OneDrive also fails, expect the same identity problem in the personal site record, including a new OneDrive site URL with a numeric or GUID suffix when the username was reused (per Microsoft support).

Likely causes

The usual trigger is a reused account after deletion. Less often, the issue appears during directory synchronization or while Microsoft Entra PIM role activation is still propagating. A clean diagnostic does not always mean the user is fixed yet, so confirm the identity path before you remove entries or widen the cleanup.

Reused UPN after account deletion

This is the usual trigger. Microsoft says the old account can be deleted and a new account created with the same user principal name, but the new account gets a different ID value. SharePoint keeps the old ID in the site UserInfo list, so the new account no longer matches and access is denied (per Microsoft support).

1. Open the affected site in Microsoft 365 admin center and run Site User Mismatch.
2. Enter the affected user account and the original site URL.
3. Verify whether the diagnostic points to a stale identity entry.
4. Remove the old user entry from the affected site only.
5. Re-share the site or OneDrive after the stale entry is removed.

PIM or role activation delay

A SharePoint admin may still see a mismatch while Microsoft Entra Privileged Identity Management is catching up. Microsoft warns that PIM role activation can take up to 24 hours to propagate. In that window, the diagnostic can look clean too early, even though the needed admin right is not fully active yet (per Microsoft support).

1. Confirm the admin account has an active SharePoint administrator role.
2. Open Microsoft Entra PIM and verify the role activation status.
3. Wait for propagation if the role was just activated.
4. Run Site User Mismatch again after the delay.
5. If results still conflict, collect the exact diagnostic output for escalation.

Directory sync or account move edge cases

Microsoft also notes cases during directory synchronization between an Active Directory organizational unit and SharePoint. Say your account moved between sync scopes, then came back with the same UPN but a different object ID. That can look like a permission problem, while the site still holds the older identity record (per Microsoft support).

1. Check whether the account was moved, deleted, or re-created in a synced directory.
2. Compare the current account object with the site access record.
3. Run the diagnostic from the original site URL, not a copied sharing link.
4. Remove only the stale user entry from the affected site.
5. Re-share access after the identity match is corrected.

How do I find the original OneDrive URL for a user?

Use the original personal site URL for the diagnostic, rather than a search result or a shared file link. Microsoft’s example format is a personal site address such as https://contoso-my.sharepoint.com/personal/UserA_Contoso_com. For a reused username, the new OneDrive site can also appear with a suffix added to the expected URL, so confirm the pre-change address before you run the diagnostic (per Microsoft support).

Gather the exact inputs before you run the check

1. Open the Microsoft 365 admin center.
2. Start the Site User Mismatch diagnostic.
3. Enter the affected user account.
4. Paste the original site URL or original OneDrive URL.
5. Run the test from a SharePoint administrator account.

How do I fix a SharePoint user ID mismatch?

Fix the identity mapping first, then re-share access. Microsoft’s supported path is to run the Site User Mismatch diagnostic in the Microsoft 365 admin center with a SharePoint administrator account, the affected user account, and the original site URL. For OneDrive, changes may take approximately 24 hours to appear after cleanup (per Microsoft support). (Microsoft Learn)

Single-site cleanup

1. Run Site User Mismatch from the Microsoft 365 admin center.
2. Use the SharePoint administrator account that is currently active.
3. Provide the affected user account and the original site URL.
4. Remove the stale identity from that site’s UserInfo list.
5. Re-share the site and verify access again.

Multi-site cleanup

1. Confirm the same user is failing on more than one site or OneDrive.
2. Check each affected site individually before changing anything tenant-wide.
3. Remove the stale UserInfo entry from each impacted site.
4. Re-share only the sites that the user should keep.
5. Wait for OneDrive changes to settle if the personal site was involved.

Tenant-wide cleanup

Use broader cleanup only after you have confirmed the same stale identity appears across multiple sites. A common first-timer mistake is to start with a script and remove entries before checking whether the failure is actually a single-site permission problem. If the issue is spread across many sites, a tenant-wide approach can be faster, but it should still preserve valid access (per Microsoft support).

1. List the affected sites and personal sites first.
2. Confirm the same old identity appears in more than one location.
3. Use the smallest fix that matches the blast radius.
4. Re-share legitimate access after each cleanup pass.
5. Verify the user can open both SharePoint and OneDrive where needed.

Mismatch triage matrix

Use this matrix to decide whether you are dealing with one site, many sites, or an identity problem that still needs confirmation. The safest path is to validate the stale entry before removing it. That is especially important when the same email address now maps to a different account object.

Still not working?

If the site still denies access after the stale identity is removed and the site is re-shared, move to a broader review of the user’s identity history and affected sites. That is the point to verify whether the problem is actually outside the supported diagnostic path, or whether the account change has not fully propagated yet.

When to broaden the cleanup

1. Check whether the same user fails on several sites, not just one.
2. Review whether the account was deleted, recreated, or moved in sync.
3. Run the diagnostic again from each original site URL that still fails.
4. For OneDrive, allow the change window to complete before retesting.
5. Use a tenant-wide script only after the same stale identity is confirmed across many sites.

Unsupported environments and escalation

Microsoft says the diagnostic is not available in GCC High, DoD, or Microsoft 365 operated by 21Vianet. If you are in one of those environments, or the diagnostic output does not match the live access problem, escalate with the exact user account, original site URL, and diagnostic result so support can verify the identity mapping directly (per Microsoft support).

Suppose a rehired employee gets the same UPN back after deletion. The personal site still points at the old ID, so SharePoint denies access until the stale UserInfo entry is removed and the site is re-shared. If OneDrive is involved, wait for the post-fix delay before deciding the cleanup failed.

Frequently asked questions

Why does SharePoint say there is a legacy user account with the same email?

That message usually means the site still holds the old ID while the current account has a new ID under the same UPN. Check the affected site’s UserInfo list, confirm the current account object, and run the diagnostic from the original site URL before changing permissions.

Can a deleted and re-created account cause SharePoint access denied?

Yes. If the account was deleted and then recreated with the same UPN, SharePoint may still match the old ID. The practical fix is to remove the stale identity from the affected site and then re-share the site or OneDrive access.

Do I need a SharePoint admin to run the mismatch diagnostic?

Yes. Microsoft requires a SharePoint administrator account to run the Site User Mismatch diagnostic. Use the Microsoft 365 admin center, select Run Tests, and provide the affected user account plus the original site URL when prompted.

Can user ID mismatch affect OneDrive and SharePoint sites?

Yes. Microsoft says the issue can affect SharePoint Online and OneDrive for Business. OneDrive fixes may take approximately 24 hours to appear, so retest after that window before deciding the cleanup failed.

What is the fastest way to remove the old user from all affected sites?

Confirm that the same stale identity appears on multiple sites first, then use the smallest cleanup that matches the scope. A tenant-wide script can be faster than one-by-one work, but only after the mismatch is verified on each affected site and the valid permissions are preserved.