Category: SharePoint 2013

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.

This is part 3 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 4 – 2016 SharePoint: The complete guide to user

Part 1: High-level Concepts If you have certain users that still show in the organization chart web part or “people search” results after being deleted or disabled in Active Directory, then it’s likely that the process to automatically clean up those user profiles is not working. Throughout the lifetime of SharePoint, there have been several

This is a pretty unique scenario, but it came up recently and exposed a little-known configuration “gotcha” with SharePoint. Consider the following scenario: You have two Trusted Providers (SAML auth) and are using them both for the same web application. For example, you have an Internal zone using URL https://teamsInternal.contoso.com that uses Trusted Provider “ADFS-Internal”

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 (2013, 2016, 2019, Subscription

This was a special situation where most of the site appeared to work, but certain links under Site Settings would fail with 403 Forbidden. For example: Themes Master Pages Solutions Composed looks List Templates Most document libraries Actually, in some cases, the page request would result in Access Denied, and redirect the user to the

STS Background: In SharePoint 2010, 2013, 2016, etc, the Security Token Service (STS) is a web service hosted under the “SharePoint Web Services” IIS site on HTTP port 32843 and HTTPS port 32844, in a virtual directory called SecurityTokenServiceApplication. In SharePoint 2010, it contains 2 web services:Securitytoken.svcWindowstokencache.svc In SharePoint 2013 and 2016, it contains 3