This is a simple one (hopefully).
The SSP3 protocol is used when defining the content sources for the SSP
If you are using SSL on your My Site host header, the SPS3S protocol should be used instead instead.
After you’ve updated the content source, run a full crawl and you should now have people results!
I found this error while testing a search result source in a ported SharePoint 2013 site (to SharePoint 2016): Search has encountered a problem that prevents results from being returned. If the issue persists, please contact your administrator.
When I looked through the ULS there was a number of errors relating to the result source’s query. The issue, of course, was that I hadn’t reset the search index and done a full crawl since migrating and upgrading the content database.
I was surprised that in all my years working with SharePoint I had never come across this issue until very recently. Well, its not really an issue, I assume it is by design. I’m talking about the SharePoint search index being directly linked to the permissions and access of users at the time of the crawl. I always thought that search results were bascially security trimmed like links to sites and lists/libraries in SharePoint but this doesn’t seem to be the case. The results s are based on the level of access a user had when the last crawl was executed. This means that if you add a user to site permissions AFTER a crawl, they will not get search results from that site until after the next crawl. So if you find some users in your training session don’t get search results and others do, its probably because those folks turned up uninvited and surprised you. I bet you added them, last minute, to the training site group before the session started. Huh? huh? Am I right?