“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: