Category: SharePoint 2016

I’ve already written a few things on this topic, but I thought I’d add additional background, consolidate concepts, and highlight a new (to me) twist. Background: SharePoint Server (doesn’t matter which version) People Picker should not return disabled user accounts from Active Directory. If it does, there’s a configuration problem in either Active Directory or

  Consider the following scenario: You move a content database from a Windows-claims web app to a new claims-based web application in a SharePoint 2016 or 2019 farm. You run Test-SPContentDatabase against the database. Example: Test-SPContentDatabase -Name Contoso_Content -WebApplication “https://team.contoso.com” The output contains this warning: “The [contoso.com-443] web application is configured with claims authentication mode

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

Important: This is not something that is supposed to work. You’ll see that we can get it to work in certain scenarios, but it is not an intended design of SharePoint. At any time, a code change could be made that breaks our workarounds and leaves little recourse other than enabling the accounts in Active

There are two App Fabric PowerShell Modules that SharePoint (2013+) uses for all Distributed Cache commands. They are located here: C:\Program Files\AppFabric 1.1 for Windows Server\PowershellModules\DistributedCacheAdministration\DistributedCacheAdministration.psm1 C:\Program Files\AppFabric 1.1 for Windows Server\PowershellModules\DistributedCacheConfiguration\DistributedCacheConfiguration.psm1     — If there are problems with these modules, certain (or all) Distributed Cache PowerShell commands may fail to run with error:

Update 4/1/22: Added Important note to Issues #2 and #6 Update 1/26/21: Added Issue #7 NTLM authentication is not great. It’s not the fastest. In most cases, that honor would go to Kerberos. It’s not the most secure. Again, Kerberos. It’s not all that flexible. For example, it doesn’t work well for extranets or anything cross-firewall.

This is kind of a “fringe” case, but since it may not be the last time it happens, here’s a post: Consider the following scenario: In SharePoint 2013+ you’re using Active Directory Import to import user profiles as trusted provider-type (SAML) profiles. You find that profiles for some users are not imported. You have already