Some potential symptoms: You try to add a user to a SharePoint group. The account is added without error, but it doesn’t show up in the group. You try to add a user to a “person or group” column in a list. The account is added successfully, but it doesn’t show up in the list.
This is one that has plagued SharePoint admins since SharePoint 2007 and earlier. There are a few other posts out there that mention this behavior, but as far as I can tell, none of them offer a complete solution. Consider the following scenario: The SharePoint farm exists in DomainB.You have users in DomainA.You migrate those
Often in troubleshooting SharePoint, we’re interested to know on which Web-Front-End (WFE) a certain request landed. When you have multiple WFEs that are load balanced, this is not easily discernable. One trick is to edit your HOSTS file and point the load balanced URL at the IP address of one WFE. That method certainly has
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. In those scenarios, Trusted Provider auth (SAML / WS-Fed) works well. See: AD FS.
I find there is much confusion around this topic, so I’ll try to clear it up here. First off, non-imported profiles are well… not imported. They were not created by Profile Sync / AD Import / Sync with External Identity Manager. We also refer to these as “unmanaged”, or “stub” profiles because they typically only
Here’s an example of an error that often occurs during Active Directory Import (aka: ADI, AD Import): ScanDirSyncChanges: Batch-abort Exception in processing response for page ‘7’, exception ‘System.DirectoryServices.Protocols.DirectoryOperationException: An operation error occurred. Under what conditions might this occur? You have an Active Directory group that has over 5,000 members. You may see