I'm managing a SharePoint site internally with lots of different users in different regions, everyone is able to access the site fine except one user who continues to get an error:
We've sorry [email protected] can't be found in the Microsoft.SharePoint.com directory"
I've tried deleting his permissions to view the site and re-adding them, I've also confirmed he can access other internal SharePoint sites and that he isn't a new joiner to the company.
Does anyone have any ideas what to do?
I have seen this issue several times. In addition to ensuring the user is logged out of all Microsoft accounts, get them to clear their browser cache too. This should ensure there aren't any authentication tokens lying around.
I have seen this issue several times as well. Most of the time this issue was related to the account used for accepting the invite and the e-mailadress the invite was sent to.
When you remove the permissions of the user, you are not actually removing the profile of the external user, so you can never really start over with adding the user again.
How to fix this:
Please use the following page to delete the user:http://site.sharepoint.com/_layouts/15/people.aspx?MembershipGroupId=0
Next, go to the SharePoint Admin Center and click on user profiles, click on manage user profiles and use the search field to search the external user. It is somewhere in there, so make sure to use the right search text.
Select the user profile and click on delete to completely remove the user account.
Now, try adding the user again.
This method always works for me when I have issues with permissions so give it a try!
Access http://Your SharePoint Site/_layouts/15/people.aspx?MembershipGroupId=0, and check whether username of the problematic accounts are listed there.
If not add the user and try again.
I would suggest you ask the user to first ensure they are signed out of all Microsoft accounts.
It could be that the user is logged in with an account that doesnt have permission, even if the error shows his work email.
An example would be, say they have been signed up to another microsoft service, such as MSDN, and associated their work email address with a seperate Microsoft account, even though the account is associated with their work email, it wont have access to SharePoint.
So for my users getting that error, I would always first point them in the direction of that linked page, to ensure they have logged out of all other accounts.
Can you verify:
When you assign him permissions is he resolved by PeoplePicker? (is he recognized by the system)
Has he ever accessed his SharePoint sites (Onedrive, Newsfeed)? Are they greyed out/accessible only via direct link/not at all?
When you go to SPO Admin Center, under Manage User Profiles search for the affected user>Edit his Profile>What value site capabilities are set to? If 12, change to 14. The capabilities are responsible for some social actions.
Have you ever recreated that user? How many profiles do you see in SPO Admin Center?
Are you able to share (and user will have access later) files/subsites/folders in that site collection?
Have you done anything original with that site, e.g did you delete permission levels?
When the user is trying to access the site, does he get an empty box where he can request access? Can he try this way?
On the off chance this helps: I have a client who has experienced this, and it generated a Microsoft ticket. Our situation is SP Online / O365; using Exchange on-prem, but ADFS in O365, with a "copy" script - new additions to Exchange get replicated in Active Directory.
Besides the limited connectivity with things like email and outlook from this setup, we would occasionally have experiences where a user who had been able to view everything in the Publishing collection (where everything is visible) suddenly couldn't view the Newsfeed, or a Team Site Owner getting access denied to her own sites.
And this would happen intermittently. Usually in a day their permissions would return. Everything was as expected in the SP user / membership grid.
Microsoft's tech advised us "not to rely on the Everyone or Everyone Except External system groups." They are supposed to inherit any new users with an activated O365 license, but according to him, it's a badly kept secret that they are not reliable.
His recommendation? Create an AD group for All SP Users, and populate it with all Active Directory users.
This is what worked for us after LOTS of troubleshooting and MSFT tickets. And, it gives us an accessible back door via O365 Admin to verify / add users to that group as needed. Apparently the script to copy all AD users into the All SP Users group is also intermittent, but that's a tangent.
Good luck.
I would also recommended to sign out from all the microsoft account and then try to add a user again and give him a permission. It should worked that way. if not, try using registry editor from the user side and delete the system/64 and install the system/32/window registry.
