SharePoint: Quick Troubleshooting tip: Add user with Classic auth permission
As lame as this sounds, there have been a few (rare) situations where trying to do something with a Windows-Claims web application within Central Administration fails with an Access Denied (sorry, this site has not been shared with you) error due to lack of permissions for your Windows Classic authentication account. If you find a
SharePoint: Quick Troubleshooting Tip: Add the Account column to User Information List
Often while troubleshooting authentication or permission problems, you need to see the actual account name for the user or group added to permissions. This is particularly important in SAML / Trusted Provider authentication because the way the claim is being passed in the SAML assertion must match exactly with the way claim has been added
Keeping SharePoint happy during your domain migration
We’ve seen a few of different problems occur in SharePoint (2013, 2016, 2019) when users are being migrated from one domain to another. They usually come up in one of the following areas: People Picker People Picker may show either or both accounts depending on which domain SharePoint is in, and how PP is configured
SharePoint 2016: Check Permissions – Windows Auth
I’ve written several blog posts on the “Check Permissions” function and its reliance on the “External Token”, including one for SharePoint 2013 with Windows authentication, which you may consider as some good pre-reading to this post, as it discusses the External Token and the details around trying to refresh that token non-interactively. Suffice to say
SharePoint: Unique list permissions: The server was unable to save the form at this time
Consider the following scenario: You break permission inheritance on a list and give some users permission to only that list. The users can browse to the list, but when they try to add an item to the list or edit an existing item, the following error occurs: The server was unable to save
SharePoint – Intermittent error: “Sorry, this site hasn’t been shared with you”
Consider the following scenario: Randomly, when a user browses to a resource (site, list, etc) that they are supposed to have access to, they receive “Sorry, this site hasn’t been shared with you” (access denied). The users continue to get “Access Denied” for a period of time, and then it starts working again after making
SharePoint: Windows user not equal to ADFS user
I’ve been over this concept with customers and support engineers so many times, that I’m not sure why I haven’t posted about it before. My colleague Adam posted on this topic a while back, but I wanted to expand on that a bit. The Setup: Let’s say you have a SharePoint (2010, 2013, 2016, 2019,