Tag Archives: Orphaned Users

Orphaned Users Clean-Up in large Microsoft 365

Leave a reply

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

Is It Safe to Remove a User from a SharePoint UIL?

Leave a reply

Actually, this article is more about “Is it safe to remove all deleted user accounts from all SharePoint sites UIL?”, as managing user lifecycle changes in Microsoft 365 goes far beyond deciding whether it’s safe to remove a single user from an individual SharePoint UIL. In large Microsoft 365 tenants, deleted or inactive accounts – sometimes called orphaned identities – can create clutter and confusion in permissions and UI elements affecting governance clarity, audit readiness. This KBA explains the broader tenant‑scale implications of cleaning up deleted user accounts across all SharePoint sites.

My immediate motivation was researching the ‘User ID Mismatch’ issue in SharePoint and figuring out how to address it proactively across the tenant. Why a dedicated KBA? Because, In isolated cases, it’s generally considered safe to remove a single user from a single SharePoint UI location after their Entra ID account has been disabled or deleted. However, there is no official guidance recommending a tenant‑wide cleanup of all UI entries for disabled or deleted accounts. In fact, when asked why such cleanup might be needed, Copilot typically responds that performing it tenant‑wide is not considered safe.

One of the reasons Copilot says it is not safe is

“Avoid removing UIL entries if you need historical metadata
For example, if you rely on “Created by” or “Modified by” or Version history tracking

In my personal experience, removing a user from the UIL does not affect item edit history — the removed user still appears correctly. Moreover, when a new user with the same UPN/email but a different display name is added to a site and begins working on the same document, SharePoint handles this correctly. But let’s test it to confirm or refute this.

I have created 3 new accounts in tenant and provided them with an m365 license:

Then created a test site, and all three users one-by-one were working on the site, creating documents, lists, providing permissions

Ensure that “Created by” or “Modified by” and Version history are tracking users correctly:

Now let us delicense, disable and delete all three users – John A Doe, John B Doe and John C Doe.
These does not change anything, as users are still in the UIL. Now let me remove all three users from the site UIL. Sources say that “Microsoft has a series jobs to clean-up users after deletion” and “never re-create users within days after deletion, wait at least 30 days.”

So let me check what is happening with “Created by”, “Modified by” and “Version history” after we delete users from the UIL and re-create users with the same UPN and provide access to the site…

EventConsequenses
User deleted from Entra Id and from UILall looks good
After a few minutesall looks good
After a few hoursall looks good
User John A Dow is recreated with the same UPN
(less than 24 hours since deletion), provided with permissions to the site and started working on documents		all looks good
After a few minutesall looks good
After a few hoursall looks good
User John B Dow is recreated with the same UPN
(less than 7 days since deletion), provided with permissions to the site and started working on documents		all looks good
After a few minutes, and after a few hoursall looks good
User John C Dow is recreated with the same UPN
(less than 30 days since deletion), provided with permissions to the site and started working on documents		TBP
After a few minutes, and after a few hoursTBP

So far all looks good, i.e. I’m not seeing any issues.

Proof is below (in the form of screenshots):

Users deleted from Entra Id and from UIL, after a few minutes:

After ~1-2 hours, I created a user with the same UPN “John.A.Doe@vladev.xyz” but with different display name – “John A2 Doe”. A new user requested access to the site, got approval and was able to access the site with no issues, then created a new document. Here is how it looks like:

Then a new user – John A2 Doe – updated Doc2. Again, all looks good. An old John.A.Doe and a new John.A.Doe are reflected correctly. Here is the version history:

Let us wait for 24+ hours…

After 10 days I undeleted “John B Dow”. Checked their access to site – permissions are here. Why? It turns out I did not remove the user from the associated Microsoft 365 group. So when I restored (undeleted) account from Entra Id – the account regain groups membership. And after some time the user was able to access the site correctly. I did not expect that, and I’m not sure is it OK. I need to keep this in mind.

Now let me try to undelete “John A Dow” (remember I already created another account with the same UPN). User accounts that you can find under “Deleted Users” have a username like “457be210d0344040a530dc99cfaa2ba6John.A.Doe@contoso.com”.
Admin center did not let me undelete this account. The message I got was “There was a problem” and “Conflicts occurred trying to restore user. Please resolve conflicts.”. So that is OK as well.

User Information List (UIL)

In short, User Information List (aka 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.

The UIL is normally hidden, but you can access it adding the following to the site URL: “/_catalogs/users/simple.aspx”, “/_catalogs/users/detail.aspx” or “/_layouts/15/people.aspx?MembershipGroupId=0”, e.g.

https://<site-collection-url>/_catalogs/users/simple.aspx
https://<site-collection-url>/_catalogs/users/detail.aspx
https://<site-collection-url>/_layouts/15/people.aspx?MembershipGroupId=0

References