Tag Archives: Orphaned Users

Orphan Users in Small Tenants

Leave a reply

“Orphan User” in SharePoint refers to a user account that no longer exists in Entra ID but is still present in the User Information List (UIL) on SharePoint sites.

Offboarded user accounts are usually deleted from the Entra ID directory sooner or later. However, SharePoint caches user information in its own databases. This information is stored in the so-called UIL (User Information List). Each site has its own User Information List.

Generally, orphan users are pretty harmless, as they are not users, but just ghost entities – records that reflects former accounts, i.e. these users cannot login, even when a new user is created with the same email – access is not possible. Moreover, legacy Microsoft documentation says such records are needed to preserve metadata – like who is the author of the document or documents editing history, etc.

So yes, orphan users are harmless until you hit a User ID Mismatch issue.

In a nutshell, a User ID Mismatch happens when an email address (UPN) is reused and a new user tries to access a SharePoint site where the old user previously had access.

SharePoint does not allow the new user to automatically inherit the same access that the old user had, and this is expected behavior. The issue is that SharePoint may fail to correctly grant access to the new user even after permissions have been assigned.

In such cases, you must first remove the old user ID from the site’s User Information List. This approach is recommended by Microsoft and considered as safe. And guess what? It turns out the old user is no longer needed in the UIL to preserve metadata 🙂

When a user hits a User ID Mismatch issue, it is often difficult to recognize that the problem is not simply missing permissions or a site owner not approving access, but an actual product limitation that prevents access to SharePoint. As a result, users become frustrated, support teams spend time troubleshooting the issue, and it may take a while before the root cause is identified and resolved.

So why not remediate the issue proactively? This way, there are no high-priority support tickets, no angry users, and no urgent troubleshooting when the problem eventually occurs.

The engineering problem behind all approaches to proactively resolving the User ID Mismatch issue is that there is no out-of-the-box (native) SharePoint report that provides a list of sites where a specific orphan user is present. You cannot simply press a button and get a complete list of orphan user/site pairs.

In general, you need to scan the entire tenant, site by site, including personal OneDrive sites, and retrieve all historical site users. Then you need to check whether each user stored in SharePoint still exists in Entra ID.

Multiply the number of sites by the number of users and see how long it might take. An average user typically has access to only ~1% of all sites in a tenant, so you can imagine how inefficient this approach can be.

However, for small tenants, we can still use this so-called brute-force approach. With this approach, we use PowerShell to do the job: identify all orphan users and, optionally, remove them.

Whether this is a viable solution depends on your specific situation: the size of your organization, employee turnover, the amount of data (number of sites), and the age of the tenant.

I may provide some kind of calculator in the future to estimate how long the process might take based on tenant characteristics. But the general idea is simple: in some cases, a brute-force approach is perfectly acceptable because it:

a) is very simple and does not require advanced PowerShell skills, and
b) can be completed in a reasonable amount of time (minutes or hours)

The script is here: https://github.com/VladilenK/m365-User-Id-Mismatch

References:

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