Category: SharePoint 2016

I came across this topic troubleshooting a support case where users were getting Access Denied to a site using Trusted Provider (SAML) authentication. The Issue: Users were given permission to the site using a group that had other groups nested in it. The users were not direct members of the group being used for permission.

Disclaimer: The below is a summary of observations made as the result of some reverse-engineering and Source Code review. It’s not necessarily to be taken as “official,” but does check out according to my testing. This is post is not about configuring Forms-based Authentication (FBA). There’s plenty of other posts out there about that. The

This post is about how a simple web service failure, caused by a networking or Active Directory issue can take your site down. I’ve come across this a few different ways. The behavior is almost always intermittent, making it hard to track down.   Possible Symptoms: Users intermittently receive a “Something Went Wrong” message when

Update 4/15/20: I have now tested this with AD Import and both SharePoint 2016 and 2019. It’s the same problem in both versions. This problem manifests itself in a few different ways: You create an Audience based on “Member Of” the “Domain Users” group. You notice there are only a couple (or maybe even zero)

Consider the following scenario: SharePoint 2013 or 2016 servers are in the contoso.com domain contoso.com has a trust relationship with the corp.fabrikam.com domain. The peoplepicker-searchadforests property is configured like this: “forest:contoso.com;forest:corp.fabrikam.com,corp\SPadmin,*****“ You use People Picker to find a user. If the users account name (samAccountName) is unique, you have no issues adding it to SharePoint.

Update 4/10/20: We’ve found a number of customers manually mapping profile properties for AD Import because that’s what they had done in previous versions of SharePoint using FIM Sync. There can be problems in certain scenarios when doing this. For example, if you manually map “WorkEmail” property to the “proxyAddresses” AD attribute, that explicit mapping

This is part 4 in a series. You can find other parts here: SharePoint: The complete guide to user profile cleanup – Part1 SharePoint: The complete guide to user profile cleanup – Part 2 – 2010 SharePoint: The complete guide to user profile cleanup – Part 3 – 2013 SharePoint: The complete guide to user