Consider the following scenario: You try to delete a user from a site collection, either in the UI (Site Settings | People and Groups | delete users from site collection), or by using the PowerShell command Remove-SPUser. The operation runs for a long time, during which the sites within that content database may suffer severe
I recently went looking for an article showing how to configure People Picker for 1-way trusts and was disappointed with what I found. Many articles reference the cringe-worthy STSADM commands. Others are either incomplete or less than concise. So here’s my take on it: Background: When using Windows authentication within SharePoint, a domain or forest
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
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