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 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?
It’s another one of those things that sounds so simple but ends up being ridiculously unintuitive to configure in SharePoint. I recently embedded a search box web part in a master page and wanted to have it search and return results from a custom list (Business Directory) in my site. So I ran through the usual steps of creating a ‘Business Directory’ display group and search scope for the list. I also set up a custom results page, ran a crawl and then configured the web part to use the Business Directory display group and hide the scope drop down (hidescopeDD). To my dismay I found that when I executed a search query using the web part, results from the entire site where returned rather than results just from my list. My custom results page had the search box web part configured in the same way but with the scope drop down showing (showDD). When I executed the same search in this web part the list results were returned.
So it seems the problem here is that the hidescopeDD DropDownModeEx for the search box hides the scope drop down but it also then defaults to the contextual scope; this:site rather than the only “real” scope in the specified display group. There are only 3 options to hide the drop down and none of these actually specify what the default scope should be (hidescopeDD, HideDD_NoScope, HideDD_useDefaultScope).
So to get around this you can actually specify the scope you want to use in the search box AppQueryTerms attribute.
AppQueryTerms= scope:Business Directory
The AppQueryTerms attribute is quite handy because you can use it as a filter in all sorts of ways. For example you can also specify the content type you want returned:
AppQueryTerms= content type:Business Directory Listing
Or the site you want to results to be returned from: