Cleaning Up Orphaned Users in Microsoft 365 SharePoint to Prevent User ID Mismatch Issues
What Is an Orphaned User in SharePoint?
To understand orphaned users, it helps to look at how SharePoint tracks user data. When a user account is created in Microsoft Entra ID and assigned a SharePoint license, they gain access to SharePoint sites.
Every SharePoint site maintains a User Information List—a local cache where SharePoint stores essential user metadata, such as display names, job titles, and email addresses. When a user account is eventually deleted from Entra ID, their data is not automatically purged from SharePoint. This is intentional: SharePoint preserves user metadata for historical integrity, allowing team members to see who created or updated a document.
An orphaned user is a user record whose metadata remains cached within a SharePoint site’s User Information List, even though the corresponding identity no longer exists in Entra ID. This phenomenon occurs across every SharePoint site the user interacted with during their tenure.
The User ID Mismatch Issue
While preserving metadata is useful for auditing and history, it sets the stage for the User ID Mismatch issue.
This scenario typically happens when a new account in EntraId is created with the exact same User Principal Name (UPN) as a former worker, for instance in cases:
- An employee leaves and is later rehired
- A contractor is converted to a full-time employee
- A new employee is onboarded who happens to share the same name
When the new account is created in Entra ID and receives the same UPN it is always assigned a brand-new, unique internal object ID. When this user attempts to access SharePoint, a collision occurs:
- Security by Design: SharePoint checks its local User Information List and finds an existing entry for that UPN, but the internal account IDs do not match. SharePoint correctly denies access, treating the incoming user as an unrecognized identity.
- The Access Block Bug: The real problem arises when a site administrator attempts to explicitly grant access. Even with admin approval, SharePoint fails to update the reference to the new account ID because the old legacy record occupies the database entry. SharePoint continues blocking access without returning a clear error message.
Microsoft acknowledges this limitation: the legacy user record must be completely removed from the site’s User Information List before the new user can be granted access.
Why Microsoft’s Native Solution Falls Short at Scale
While Microsoft provides a standard resolution—deleting the old legacy ID from the site—the fix is GUI-based and designed strictly on a single-site, single-user basis.
In an enterprise environment, this creates severe operational hurdles:
- Tenant-Wide Scope: An average employee might access dozens or hundreds of sites throughout their organizational tenure. Fixing a mismatch requires applying Microsoft’s fix across every single site the user touched. Though we can do the same with PowerShell, there is a second problem –
- Lack of Out-of-the-Box Reporting: There is no native report that displays all occurrences of a legacy account across all SharePoint sites in a tenant. While a brute-force PowerShell script can scan a tenant, doing so in medium-to-large organizations is resource-intensive and exceptionally slow.
- User Frustration: The error presents silently. SharePoint appears to work normally, but access fails. When a user contacts a site owner who approves access yet nothing changes, it creates confusion. Once resolved on one site, the user frequently hits the exact same issue on other sites, assuming the entire problem was fixed globally.
Strategic Approaches: Prevention vs. Cleanup
To effectively manage User ID Mismatch issues, I think organizations should generally look at three distinct activities:
1. Proactive Prevention (“Stop Tickets”)
For just onboarded users (incoming accounts), you can proactively check newly created Entra ID accounts against historical UPNs. If a match is found, you can scan and clean up potential orphaned records across SharePoint sites before the user ever encounters an access block.
2. Automated Offboarding (“Stop Bleeding”)
At the exact moment a user account is disabled or deleted from Entra ID, an automated routine can sweep SharePoint sites to remove the newly orphaned user metadata. Stopping the bleeding at the point of departure prevents new orphaned records from accumulating.
3. Historical Cleanup of Existing Orphaned Users
For mature tenants that have been active for years, orphaned users have already accumulated in massive numbers. Estimating roughly, in a mature tenant (e.g., 10 years old), the number of orphaned user records can scale to rival the number of active users in Entra ID. (see How Many Orphaned Users Do You Have in SharePoint?)
Cleaning up existing orphaned users tenant-wide is the cornerstone of resolving widespread User ID Mismatch friction.
Technical Cleanup Strategy for Large Organizations
While smaller tenants with a few dozen sites can rely on a simple brute-force scan across every site, brute-force scanning for large enterprises with 100,000+ sites is impossible. But one of the approaches I came up and effectively use in my tenants I support is below.
The goal here isn’t an exhaustive, 100% tenant-wide purge—it’s about capturing the low-hanging fruit. By applying a targeted 80/20 strategy, you can eliminate a massive portion of the organization’s User ID Mismatch issues with relatively minimal effort:
Step 1: Target High-Population Sites First
Instead of scanning 100,000 sites, target the top ~20 high-population sites where most organization members have visited. This typically includes The main Corporate Intranet / Portal, Company-wide news sites, Sites tied to widely joined public Teams or organization-wide Viva Engage (Yammer) communities.
Focusing on these key high-traffic sites allows us to proactively eliminate a massive portion of cached orphaned user records with a manageable level of effort.
Real-world data shows why this is so effective: when analyzing onboarded users who experienced UPN reuse, legacy user records are rarely spread across hundreds of niche sites. Instead, for the majority of users, their legacy access—and thus their cached data—was confined to just a handful of company-wide, high-population sites that everyone visits. Clearing these top sites eliminates the bulk of potential user ID mismatch landmines before users ever hit them.
Step 2: Query the User Information List Directly
Avoid using Get-PnPUser on large sites, as it takes an impractically long time to run. Instead, query the underlying Site User Information List directly to fetch all items. Even for sites with hundreds of thousands of cached users, this query completes within a few minutes. Convert these list items into usable user objects in memory.
Step 3: Fast Matching via Entra ID Hash Tables
- Retrieve all active users from Microsoft Entra ID.
- Build an in-memory Hash Table of active Entra ID accounts indexed by UPN.
- Iterate through the SharePoint site users and check their existence against the Entra ID hash table. Because hash table lookups occur in O(1) time, identifying all orphaned users on a site takes only minutes.
Step 4: Parallelized Deletion
Running Remove-PnPUser sequentially across thousands of orphaned users takes roughly 1 second per user—meaning a single site could take days or weeks.
To bypass this bottleneck, leverage PowerShell Parallelism (e.g., ForEach-Object -Parallel). Executing user deletions concurrently reduces the processing time for ~100,000 orphaned users down to approximately one hour.
Summary Workflow
- Identify top 20 high-traffic corporate sites.
- Fetch site users via the hidden User Information List (bypassing
Get-PnPUser). - Compare site users against an active Entra ID Hash Table.
- Purge identified orphaned records using PowerShell parallel execution.
Stay tuned for an upcoming post where I will share the exact PowerShell script and code samples implementing this optimized workflow!