When a user leaves an organization, their account is usually deleted from Microsoft Entra ID. However, SharePoint often keeps a record of that user in its own databases. These records are commonly called orphaned users. Most of the time they do not cause any problems. But when the same user principal name (UPN) is later assigned to a new account, these orphaned records can cause the well-known User ID Mismatch issue. In this article, we’ll look at what orphaned users are, why they exist, how they are related to User ID Mismatch, and what SharePoint administrators can do about them.

Overview

An orphaned user in SharePoint is generally understood as a user whose record still exists in a SharePoint site collection, even though the corresponding account no longer exists in Microsoft Entra ID.

Orphaned user records are not necessarily errors. SharePoint maintains its own site-level user information so that it can preserve historical context, such as who created or modified a document. However, these records can become operationally significant when an organization creates a new Entra ID account using the same User Principal Name, or UPN, as a previously deleted account.

This can produce a SharePoint user ID mismatch:

• The old and new accounts have the same UPN.
• They have different Entra ID object IDs.
• SharePoint still associates the UPN with the old identity.
• The newly created user cannot access content, even after apparently receiving permissions.

This article explains:

1. What orphaned SharePoint users are.
2. Why SharePoint retains them.
3. How they contribute to user ID mismatch.
4. Why fixing one affected site does not solve the tenant-wide problem.
5. How remediation strategies differ by tenant size, tenant age, and employee turnover.
6. How to approach the problem using cleanup, ticket prevention, and offboarding controls.

---

What Is an Orphaned User in SharePoint?

SharePoint maintains information about users who have interacted with or received permissions to a site collection.

This information is stored in the site collection’s hidden User Information List, commonly referred to as the UserInfo list. When a person visits a site or is otherwise resolved as a user, SharePoint caches information about that identity in this list. Deleting the corresponding account from Microsoft 365 or Entra ID does not necessarily remove the entry from each SharePoint UserInfo list. [learn.microsoft.com]

The resulting record is commonly called an:

• Orphaned user
• Stale user
• Legacy user
• Orphaned SharePoint identity

“Orphaned user” is a useful administrative term, although Microsoft documentation more frequently uses terms such as legacy user account, outdated user account, or an old entry in the UserInfo list.

Why does SharePoint retain the user?

The retained record provides continuity for user-related metadata.

For example, after an employee leaves the organization, users may still need to see that the former employee:

• Created a document.
• Modified an item.
• Added a list entry.
• Was previously assigned permissions.
• Participated in historical SharePoint activity.

From this perspective, the orphaned record appears not only harmless but useful. It helps SharePoint preserve the historical identity associated with existing content.

This is one reason administrators should not treat every orphaned user as something that must immediately be deleted. Microsoft positions removal from the UserInfo list primarily as a troubleshooting action for profile synchronization and mismatched-ID scenarios, rather than as routine indiscriminate cleanup. [learn.microsoft.com]

---

The Problem Appears When an Identity Is Recreated

Consider a common employee lifecycle scenario.

1. John Smith leaves the organization.
2. His Entra ID account is deleted.
3. SharePoint retains John’s entries in the UserInfo lists of sites where he previously appeared.
4. Several months later, the organization rehires John.
5. The identity team creates a new Entra ID account using the same UPN, such as john.smith@contoso.com.

The new account looks similar to the old account:

• Same display name
• Same email address
• Same UPN

However, it is not the same directory object.

The recreated account receives a new internal identity value, even though its UPN matches the deleted account. Microsoft documents this as a primary cause of SharePoint and OneDrive user ID mismatch. [learn.microsoft.com], [learn.microsoft.com]

The same situation can also occur when the UPN is assigned to an entirely different person. For example, a new employee named John Smith may receive an address previously used by another John Smith.

From Entra ID’s perspective, the new account is a new security principal. From the affected SharePoint site’s perspective, however, the UPN may still be associated with the legacy UserInfo entry.

---

What Is a SharePoint User ID Mismatch?

A user ID mismatch occurs when the identity presented by the current user does not match the identity stored in SharePoint.

Conceptually, SharePoint sees something like this:

Attribute	Legacy account	New account
Display name	John Smith	John Smith
UPN	john.smith@contoso.com	john.smith@contoso.com
Entra ID object ID	Old value	New value
SharePoint UserInfo entry	Present	Not properly resolved

Although the UPN is the same, the internal identity is different.

Microsoft describes the underlying cause as follows: the recreated account receives a new ID, but the affected SharePoint or OneDrive UserInfo list still contains the old ID. When the user attempts to access the site using the new account, the new identity does not match the identity stored in the site. Access can therefore be denied. [learn.microsoft.com], [learn.microsoft.com]

Typical symptoms include:

• An Access denied message.
• A message stating that a legacy account with the same email exists.
• Permissions that appear correct to the site owner but do not work for the user.
• Inconsistent access across SharePoint sites.
• A OneDrive URL with an unexpected numeric or GUID suffix. [learn.microsoft.com]

---

Why Denying Existing Access Is Correct

At first glance, it may appear that SharePoint should automatically connect the new account to the old account because the UPN is identical.

That would create a security risk.

A reused UPN does not prove that the new account represents the same person. Even if it is the same person, the individual may have returned:

• In a different position.
• In another department.
• As a contractor instead of an employee.
• Under different security requirements.
• With a different level of authorization.

The new account should not automatically inherit the old account’s SharePoint permissions.

Therefore, SharePoint is correct not to treat the recreated account as the same security principal merely because the UPN matches.

The more problematic behavior appears after an authorized site owner intentionally grants the new account access.

---

Where the Actual Operational Problem Begins

Suppose the new John Smith requests access to a site.

The site owner reviews the request and intentionally approves it. Alternatively, the site owner shares a site, library, folder, or document with the new account.

From the site owner’s perspective, everything may appear correct:

• The expected name is displayed.
• The expected email address is displayed.
• The user appears in the permissions interface.
• The sharing operation completes without an obvious error.

However, the user may still be unable to access the resource because the site’s UserInfo list contains the legacy identity associated with the same UPN.

SharePoint does not always replace the old identity automatically when the new account is granted access. That is the practical limitation behind many user ID mismatch incidents.

Microsoft’s supported starting point is the Site User Mismatch diagnostic in the Microsoft 365 admin center. When a mismatch is found, the diagnostic can offer to remove the old identity from the affected site. After the old entry is removed, the new account must be assigned the appropriate permissions. [learn.microsoft.com], [learn.microsoft.com]

For a single site, this is usually manageable.

At tenant scale, it becomes much more complicated.

---

Why Fixing One Site Is Not Enough

A recreated user rarely interacted with only one SharePoint site.

During the person’s previous employment, the account may have been present in:

• Team sites
• Communication sites
• Microsoft Teams-connected sites
• Project sites
• Departmental sites
• Shared OneDrive sites
• Archived collaboration workspaces
• Sites where individual files or folders were shared

Removing the legacy identity from one affected site fixes only that site.

The same user may encounter another mismatch tomorrow, next week, or several months later when attempting to access a different site.

This creates a recurring support pattern:

1. The user reports an access problem.
2. The administrator identifies a mismatch.
3. The administrator fixes the affected site.
4. The ticket is closed.
5. The user encounters the same problem on another site.
6. The investigation starts again.

The technical fix is site-specific, while the identity lifecycle problem is potentially tenant-wide.

---

Why Discovering Every Affected Site Is Difficult

The obvious question is:

Which SharePoint sites still contain the old identity?

SharePoint Online does not provide a simple out-of-the-box report listing every site collection whose UserInfo list contains a specific legacy user.

An administrator can technically scan SharePoint sites and inspect their users. However, this can be inefficient in a large tenant.

For example, imagine a tenant with:

• 50,000 SharePoint sites.
• A user who appeared in approximately 100 of those sites.

A straightforward tenant scan may need to inspect all 50,000 sites to locate the relevant 100.

This is a classic search-efficiency problem. The administrator knows the identity being investigated but does not know which site collections contain that identity. SharePoint’s user information is distributed across site collections rather than exposed through a convenient centralized orphan-user inventory.

For one affected user, a tenant-wide brute-force scan may consume considerable time and service resources relative to the number of useful results.

---

Shifting Left: When Should the Problem Be Addressed?

Instead of waiting for a user to report an access problem, administrators can move the remediation point earlier in the identity lifecycle.

There are three general opportunities.

Option 1: Fix the Site After a Ticket Is Reported

This is the most reactive approach.

Workflow

1. A user reports that SharePoint access does not work.
2. The administrator confirms that the account was recreated or the identity changed.
3. The administrator runs the Site User Mismatch diagnostic.
4. The old user entry is removed from the affected site.
5. The new account is granted the appropriate permissions.
6. The user tests access.

Advantages

• Limited scope.
• Low immediate effort.
• Changes are made only when necessary.
• Reduced risk of unnecessary tenant-wide modifications.

Disadvantages

• The user has already experienced disruption.
• The problem may exist on multiple sites.
• Each new site can generate another ticket.
• Support engineers repeatedly investigate the same root cause.

This approach treats the symptom rather than the tenant-wide identity residue.

---

Option 2: Check Newly Created Accounts

The next shift-left opportunity occurs when an account is created.

The organization could determine whether the UPN was previously used and then search for the corresponding legacy SharePoint identity.

Advantages

• The mismatch may be resolved before the user accesses SharePoint.
• Work is targeted at identities that are actually being created or recreated.
• It avoids cleaning every orphaned user immediately.

Disadvantages

• The process must determine whether the UPN is genuinely new or reused.
• The administrator still needs to locate the sites containing the previous identity.
• Historical identity data may not be readily available.
• It is still reactive to account creation rather than integrated with offboarding.

This approach can prevent tickets, but it requires reliable identity history and potentially expensive site discovery.

---

Option 3: Remove Legacy Site Entries During Offboarding

The earliest intervention point is employee offboarding.

Before deleting the Entra ID account, the organization still has a valid and identifiable user. It may be easier to determine the SharePoint sites associated with a current identity than to reconstruct that information months or years later.

The offboarding process could:

1. Identify the SharePoint and OneDrive sites associated with the departing user.
2. Record relevant site membership and ownership information.
3. Address ownership and permission dependencies.
4. Remove the user from selected UserInfo lists when appropriate.
5. Delete or disable the directory account according to organizational policy.

Advantages

• The identity is still known and available.
• Site discovery can be incorporated into lifecycle automation.
• It can reduce future user ID mismatch incidents.
• It addresses the problem at its earliest practical stage.

Disadvantages

• Most offboarded users will never return.
• Most deleted UPNs may never be reused.
• Removing every departing user from every site may be unnecessary.
• Historical and metadata implications must be tested.
• Offboarding workflows become more complicated and potentially slower.
• A poorly designed process could create more risk than it removes.

This is the most proactive approach, but it can also be an over-engineered solution if the actual mismatch rate is very low.

An organization should not assume that universal deletion is automatically the best practice. Microsoft specifically describes UserInfo removal as a troubleshooting operation that should be performed for synchronization or mismatch scenarios when advised, rather than as a general cleanup requirement. [learn.microsoft.com]

---

A Three-Workstream Strategy

For established tenants, no single activity completely solves the problem. A practical program can be divided into three separate workstreams.

1. Clean Up Existing Orphaned Users

This workstream addresses the historical backlog already present in the tenant.

Its purpose is to:

• Inventory orphaned or legacy users.
• Identify high-risk identities.
• Detect reused UPNs.
• Remove confirmed conflicting identities where appropriate.
• Document exceptions and unresolved cases.

This is a backlog-remediation activity.

It can require substantial effort in an old or large tenant because orphaned identities may have accumulated for many years.

---

2. Stop Tickets

This workstream focuses on newly created or recreated accounts.

Its purpose is to prevent a new employee or returning employee from encountering mismatch errors after receiving SharePoint access.

Possible activities include:

• Detecting whether the new UPN was used previously.
• Comparing the new Entra ID object ID with historical identity information.
• Checking likely or known SharePoint sites.
• Removing confirmed legacy entries.
• Reassigning access explicitly to the new identity.
• Verifying access before the user begins work.

This is a near-term ticket-prevention activity.

It does not remove the entire orphan-user backlog, but it can prevent visible incidents for newly created accounts.

---

3. Stop the Bleeding

This workstream is triggered when users are offboarded.

Its purpose is to prevent new legacy identity conflicts from accumulating.

Possible activities include:

• Capturing the user’s site footprint before account deletion.
• Reassigning site, group, and content ownership.
• Recording the original Entra ID object ID and UPN.
• Applying a UPN-retention or reuse policy.
• Removing selected SharePoint user entries where justified.
• Preserving an auditable identity mapping for future investigation.

This is a future-state prevention activity.

The safest implementation may not be immediate removal from every UserInfo list. In many organizations, the more valuable first step is recording the departing user’s identity and SharePoint footprint so the information remains available if the UPN is reused.

---

Tenant Age Changes the Priority

The appropriate combination of these workstreams depends partly on the age of the tenant.

New Tenant

A newly created tenant has little or no legacy identity history.

The primary focus should therefore be:

• Offboarding design.
• Identity history retention.
• UPN-reuse controls.
• Future orphan-user prevention.

A new tenant may not need a significant cleanup or ticket-remediation program.

Established Tenant

An established tenant may already contain:

• Many deleted identities.
• Previously reused UPNs.
• Unresolved UserInfo entries.
• Existing user ID mismatch cases.

Implementing an improved offboarding process prevents new problems, but it does not repair the historical backlog.

The organization may need all three workstreams:

• Clean up existing records.
• Prevent current tickets.
• Improve future offboarding.

Old Tenant

An old tenant with many years of account turnover may require a formal engineering solution.

The challenge is not necessarily deleting every orphaned entry. The challenge is:

• Identifying which entries are risky.
• Prioritizing accounts whose UPNs have been reused.
• Finding affected sites efficiently.
• Correcting mismatches without damaging historical information.
• Avoiding an endless tenant-wide brute-force scan.

---

Tenant Size Determines the Technical Approach

Small Tenants

In a small tenant, brute-force scanning may be acceptable.

An administrator may be able to:

1. Enumerate all SharePoint sites.
2. Enumerate the users on each site.
3. Compare SharePoint identities with Entra ID identities.
4. Produce an orphan-user report.
5. Review and remediate the results.

Depending on throttling, permissions, and the number of sites, the process might complete within a practical operational window.

Medium-Sized Tenants

A medium-sized tenant may require a hybrid approach:

• Scan high-value sites first.
• Prioritize reused UPNs.
• Process active departments before archives.
• Maintain a cached site-user index.
• Perform incremental scans instead of full rescans.
• Combine ticket-driven remediation with scheduled discovery.

The objective is to avoid repeatedly scanning every site for every affected user.

Large Tenants

In a large tenant, a naive brute-force approach may be impractical.

The solution may require:

• Incremental inventory collection.
• Parallel processing with controlled concurrency.
• Throttling and retry handling.
• Persistent storage of site-user relationships.
• Delta-oriented identity processing.
• Site prioritization.
• Historical identity correlation.
• Separate handling for SharePoint sites and OneDrive sites.
• Governance around retention and UPN reuse.

At this scale, orphan-user management becomes an engineering and data-indexing problem rather than a simple administrative script.

---

Employee Turnover Also Matters

Tenant size and age are not the only factors.

Two organizations with the same number of users may experience very different levels of risk.

An organization with stable staffing and low turnover creates relatively few deleted identities. An organization that frequently hires contractors, seasonal workers, or temporary employees may create and delete a much larger number of accounts.

Relevant factors include:

• Number of offboarded users per year.
• Percentage of UPNs eventually reused.
• Frequency of employee rehires.
• Use of contractors and seasonal employees.
• Tenant age.
• Number of SharePoint sites.
• Average number of sites associated with each user.
• Average delay between deletion and UPN reuse.

The mismatch rate may be low relative to the total number of deleted accounts. Therefore, removing every orphaned SharePoint user during every offboarding may be disproportionate to the actual risk.

A more efficient strategy may prioritize identities whose UPNs are known to have been reused or are likely to be reused.

---

Is It Safe to Remove an Orphaned User?

This deserves its own detailed discussion.

Microsoft documents removal from the UserInfo list as a way to troubleshoot mismatched identity and profile synchronization scenarios. At the same time, Microsoft warns that the removal procedure should be used for those troubleshooting purposes rather than as an unrestricted general cleanup method. [learn.microsoft.com]

The practical safety of removal depends on several factors:

• Whether the account is truly deleted.
• Whether the UPN has been reused.
• Whether the old and new accounts belong to the same person.
• Whether permissions have been reviewed.
• Whether the user owns or administers important resources.
• Whether workflows, applications, or custom solutions reference the user.
• How historical people fields behave after removal.
• Whether the target is SharePoint or OneDrive.
• Whether the organization has retention, audit, or compliance requirements.

Removing the old UserInfo entry can be appropriate for correcting a confirmed mismatch. It should not be confused with granting the new user the old user’s access.

After the legacy entry is removed, the new account should receive only the permissions appropriate to the new identity and current role.

For additional analysis, see:

Related article: [Is It Safe to Remove a User from the SharePoint User Information List?]
Link to be added.

---

Recommended Administrative Approach

A balanced strategy is usually better than universal deletion.

For an Active User ID Mismatch

1. Confirm that the account was deleted and recreated or otherwise received a new identity.
2. Confirm that the UPN matches a legacy SharePoint entry.
3. Use Microsoft’s Site User Mismatch diagnostic for the affected site.
4. Remove the confirmed old identity.
5. Assign permissions to the new account explicitly.
6. Validate access using the new account.
7. Record the affected site so repeated incidents can be correlated.
8. Investigate other high-probability sites used by the person.

The Microsoft diagnostic requires an appropriate administrative account. Microsoft also notes that it is unavailable in GCC High, DoD, and Microsoft 365 operated by 21Vianet environments. [learn.microsoft.com]

For Newly Created Accounts

1. Check whether the UPN was previously assigned.
2. Preserve both the new and historical Entra ID object IDs.
3. Identify known sites associated with the previous identity.
4. Correct confirmed legacy entries before granting new access.
5. Avoid automatically restoring previous permissions.

During Offboarding

1. Capture the departing account’s UPN and Entra ID object ID.
2. Record site ownership and critical memberships.
3. Transfer required ownership.
4. Preserve an identity-to-site inventory where practical.
5. Apply the organization’s UPN-retention policy.
6. Remove SharePoint entries only according to a tested and documented policy.

---

Conclusion

Orphaned SharePoint users are not automatically defects. They are a consequence of SharePoint retaining site-level identity information after the associated Entra ID account has been deleted.

In many cases, these records remain harmless and help preserve historical context.

They become problematic when:

1. An Entra ID account is deleted.
2. A new account is created with the same UPN.
3. The new account receives a different internal ID.
4. SharePoint still associates the UPN with the old identity.
5. The new user attempts to access a site containing that legacy identity.

SharePoint is correct not to transfer the old account’s permissions automatically. A reused UPN should not be treated as proof that two accounts represent the same security principal.

The operational limitation is that SharePoint may continue resolving the UPN against the old site-level identity even after a site owner intentionally grants access to the new account.

For one site, the solution is relatively straightforward: identify and remove the legacy entry, then assign the proper permissions to the new identity.

For an entire tenant, the problem is much harder because administrators must determine which sites contain the old identity.

An effective strategy therefore separates the work into three areas:

1. Clean up the historical backlog.
2. Stop tickets for newly created or recreated accounts.
3. Stop the bleeding by improving offboarding and identity-history processes.

The right balance depends on tenant size, tenant age, employee turnover, UPN-reuse practices, and the organization’s tolerance for support incidents versus proactive engineering effort.

---

Related Articles

• User ID Mismatch in SharePoint: Detailed Troubleshooting and Resolution
  Link to be added.
• Is It Safe to Remove a User from the SharePoint User Information List?
  Link to be added.
• Managing Orphaned SharePoint Users in Small Microsoft 365 Tenants
  Link to be added.
• Managing Orphaned SharePoint Users in Large Microsoft 365 Tenants
  Link to be added.
• Estimating User ID Mismatch Risk in Your Microsoft 365 Tenant
  Link to be added.

Another Way to Prevent User ID Mismatch: Identity Management

So far, we discussed the problem from a SharePoint administrator’s point of view. In that world, the typical solution is to find the legacy user in SharePoint and remove the old user entry from the User Information List.

However, there is another approach.

Instead of fixing User ID Mismatch issues after they occur, an organization can prevent many of them through proper identity management.

The root cause of most User ID Mismatch issues is not SharePoint itself. The issue typically appears when a user account is deleted and later a new account is created with the same UPN. SharePoint still contains records for the old identity, while the new account has a different internal identity value. As a result, SharePoint treats them as two different users even though the UPN is the same. [learn.microsoft.com], [learn.microsoft.com]

Because of that, Identity and Access Management (IAM) teams can reduce or eliminate many User ID Mismatch issues by ensuring that each person receives a unique UPN that is never reused.

For example, instead of recreating:

john.smith@contoso.com

for a rehired employee, the organization could assign a different UPN, such as:

john.smith2@contoso.com

or follow another naming standard that guarantees uniqueness.

With this approach, the new account never collides with the legacy SharePoint user record. As a result, User ID Mismatch issues are much less likely to occur.

Of course, this approach comes with its own challenges. Organizations often prefer to reuse the original UPN because it is easier for users, administrators, and business processes. In addition, changing naming standards may affect other systems that depend on predictable user names.

For that reason, UPN management should be viewed as an identity governance decision rather than a SharePoint administration task. SharePoint administrators can fix User ID Mismatch issues when they occur, but Identity and Access Management teams can often prevent those issues from appearing in the first place by implementing policies around account lifecycle management and UPN reuse.

In short, there are two ways to address User ID Mismatch:

1. SharePoint approach: Find and remove the legacy SharePoint user records that cause the conflict.
2. Identity management approach: Prevent UPN reuse so that the conflict never occurs.

The first approach is owned by SharePoint administrators. The second approach is owned by Identity and Access Management teams. In many organizations, the best long-term solution is a combination of both approaches.

References

• Clean orphaned users (ShareGate)
• Orphaned Users (SysKit Point)

This article address “Orphaned Users” in SharePoint and applies mostly to medium and large tenants.

The problem statement

Orphaned users are user accounts that no longer exist in Entra ID (Azure AD) but still appear inside Microsoft 365 SharePoint or OneDrive sites, specifically in the User Information List (UIL). A SharePoint User Information List (UIL) is a hidden system list that exists in every SharePoint site collection and stores cached profile information about users who have interacted with that site. In short about orphaned users and UIL: The identity is gone, but its footprint remains.

Why Orphaned Users Must Be Removed?

Orphaned users should be eliminated not only because their presence in sites confuses active users, but mostly because they cause “User ID Mismatch” issues when UPNs are reused.

What is a “User ID Mismatch” issue in SharePoint?

User ID Mismatch is a known problem in SharePoint. It happens usually when a user account is deleted from the directory, and then a new account is created with the same UPN (re-used user principal name). Symptoms are: a user is provided with the access to the site, but still cannot get access.

The reason behind it is that SharePoint caches users data in the UIL, including not only UPN, but also Entra Id user object Id. So when a re-used UPN tries to access the site – SharePoint does not allow access, because even if UPN is the same – Id is different – e.g. SharePoint treats user as a different one. So access needs to be re-provided. And this is where the actual issue happens. When a site owner shares the resource with a new user (or approves access request) – Microsoft does dot update the UIL with the new user ids. So for the user and for the site owner it looks like access was provided, but in fact it was not.

How do we remove Orphaned Users

Microsoft provides a “fix”, but this solution is really weak as it allows only to remove one orphaned user from one site reactively. Here are some more details: “Fixing SharePoint User ID Mismatch Issue“.

Can we address the issue proactively, tenant-wide (all users, all sites, before the issue happens)? Probably – yes, but it takes a lot. Here are some more details: “Preventing SharePoint User ID Mismatch: a Tenant‑Wide Approach“. In a nutshell solution is at the moment of an employee offboarding – when a user account is deleted from directory (Entra Id) – we need to remove that user from all sites UIL they had access to. But how? And the other question: is it safe?

How do we remove deleted Entra is users from all SharePoint sites? This is a huge problem, as there is no native (out-of-the-box) Microsoft’s tools or reports to get all sites a specific user has access to. But here is where a 3-rd party tools might help. E.g. SysKit Point – with it’s “Orphaned Users” policy or ShareGate.

Is it safe to remove all orphaned users from all sites in SharePoint? Though Microsoft did not publicly say “yes” (at least I have not seen it), a high-skilled SharePoint support engineers says yes, generally it’s safe if you do it correctly. My research on the question says the same – yes, it is safe (“Is It Safe to Remove a User from a SharePoint UIL?“).

Can we just turn the SysKit’s “Orphaned Users” policy on? In small tenants – yes, in new tenants – yes. But your tenant is not new and not small – you probably already have tens or hundreds of thousands of orphaned users. Unfortunately, in SysKit there is no options to implement the policy in chunks – so we do orphaned users clean-up against test sites, then pilot, then step-by-step all other sites. Also the “orphaned users” report just fails due to enormous amount of data.

So the idea is to do an initial clean-up in the environment – gracefully remove all existing orphaned users before implementing “Orphaned Users” policy. This is exactly the topic of this KBA.

Initial Clean-Up of Orphaned Users in large Microsoft 365 tenants

A controlled, script-based clean-up must be completed before the Orphaned Users policy can be safely enabled. PowerShell is identified as the primary tool for this effort.

Below is a draft (preliminary considerations) – to be tested/proved/updated.

Scale of the Problem (sample large Microsoft 365 tenant):

• Approximately 500,000 sites (~200k SharePoint + 300k OneDrive sites)
• Approximately 500,000 orphaned users
• Approximately 300,000 normal users

Key Constraints and Challenges

• No existing report that maps orphaned users to sites
• Full enumeration of sites and users is expensive and time-consuming
• Microsoft throttling limits must be respected
• Some sites have extremely large User Information Lists (UILs)
• Orphan detection must not rely on UPNs due to reuse
• Processing must be resumable and trackable

High-Level Strategy

The clean-up approach must:

• Support piloting and phased execution
• Reduce orphaned user count enough for SysKit reporting to function (no need in total “zero orphan” cleanup)
• Minimize tenant-wide risk

Recommended initial strategy:

• Exclude new sites and external sites
• Identify large sites and process them separately
• Begin with medium-sized sites
• Validate approach using small but active sites before scaling

Execution Model

For each site processed:

• Retrieve users from the site’s User Information List (UIL)
• Check each user to determine orphan status
• Remove orphaned users immediately
• Avoid report-only runs except for limited analysis

Deleting orphans immediately avoids duplicate scanning and unnecessary re-validation.

Orphan Detection Approach

Preferred identifier: Entra ID Object ID. UPNs must not be used to determine orphan status due to reuse.

Options considered:

1. Query Entra ID for every user
   • Accurate but expensive
   • Repeats checks for the same users
2. Maintain a cached list of existing users
   • Risk of missing newly added users
   • Large list reduces efficiency

Recommended technique:

• Maintain a list of orphaned users by Entra Object ID
• If Object ID is known orphaned, it is orphaned everywhere permanently
• Check UIL user Object ID against this list first
• If unavailable, fall back to Entra ID lookup

Note: UIL does not always store Entra Object ID directly; sometimes only login name (claim) is available.

Handling Large Sites

• Get-PnPUser does not support paging
• Direct access to the User Information List (UIL) with paging is required
• Large UILs can cause failures if not paged properly

Workers and Parallel Processing

The clean-up cannot be completed with a single script run.

Expected characteristics:

• Hundreds or thousands of executions
• Parallel workers required
• Throttling must be handled gracefully
• Processing must be resumable

Worker execution options:

• Manual runs from a VM (e.g., nightly)
• Scheduled Azure jobs (Function App or Automation Account)

With multiple workers, a global STOP flag should be supported.

Tracking and State Management

Tracking is mandatory to avoid reprocessing completed work.

Tracking by user-site pairs is not feasible due to scale.

Preferred approach: Tracking by site.

Minimum tracking fields per site:

• SiteUrl
• State (Pending | InProgress | Done | Failed)
• LastProcessedDateTime
• AttemptCount
• LastError
• Metrics:
  • UsersScanned
  • OrphansFound
  • OrphansRemoved
  • DurationSeconds

Tracking Storage Options

• SharePoint list: not suitable at scale
• CSV:
  Pros: simple
  Cons: slow, co-authoring issues
• SQL:
  Pros: fast, reliable
  Cons: complex
• Azure Table Storage or Cosmos Table API: viable option

Each worker:

1. Takes a site
2. Marks the site InProgress (with a lease)
3. Scans UIL in pages
4. Removes orphaned users
5. Logs actions and metrics
6. Marks site Done

Reused UPNs and User ID Mismatch

Because the tenant contains many reused UPNs:

• UPN must not be used to determine orphan status
• Entra ID Object ID must be used wherever possible

Deleting users by site user ID or login name is safe because reused UPNs are not added to UIL until the previous orphan entry is removed.

An alternative approach is to skip reused UPNs entirely:

• This is safe from a risk perspective
• But it misses an opportunity to fix User ID Mismatch issues

This tradeoff may be acceptable if performance gains are significant.

References

• Fixing SharePoint User ID Mismatch Issue with PowerShell
• Preventing SharePoint User ID Mismatch: a Tenant‑Wide Approach
• Is It Safe to Remove a User from a SharePoint UIL?