The great thing about SharePoint Enterprise Search is that once it's up and running it mostly just works. Except, of course, when it doesn't. Recently I was troubleshooting a farm in which People search stopped returning any results. In this environment, the main OU containing user accounts had been moved and a new profile import run to re-populate the profile database. The import was successful but the changes required a full crawl of the content source which had been working just fine up until that point. After the next crawl completed all queries against the People scope returned an empty result set.
After confirming that none of the permissions had changed, and that the default crawl account still had access to the User Profile service app and all web applications, another full was run without success. It was during this run that the crawl log displayed the following error for the primary web application (which had probably been there all along but was buried beneath a number of other content-related crawl errors):
An unrecognized HTTP response was received when attempting to crawl this item. Verify whether the item can be accessed using your browser.
A bit of research indicated that this is usually due to insufficient permissions – either the crawl account does not have Full Read permissions set in the web application User Policy or it hasn't been granted the "Retrieve People Data for Search Crawlers" right for the user profile service application. But in this case both sets of permissions were valid. An attempt to connect to the search crawl web service (/_vti_bin/spscrawl.asmx) confirmed this but also revealed something interesting – all HTTP requests were being redirected to HTTPS. Another look at the Content Source in Search Administration showed that the primary web application was, in fact, set up to crawl content via an HTTPS URL.
The SharePoint People Search mechanism requires a specific URL format within a Content Source, one that begins with "sps3://" instead of the usual "http://". The site cannot actually be browsed via this URL; instead, it's merely a connector reference that the search crawler associates it with the proper URI under the covers. When a web application is secured via SSL the protocol portion of the URL has to be changed from "sps3://" to "sps3s://" – the "s" letting the crawler know it should use HTTPS instead of HTTP.
Specifying an SSL target for the People search content source
Changing the URL value in the Content Source from "sps3://" to "sps3s://" resulted in a successful crawl and People search started returning results at the conclusion of the next full crawl. So if any of the web applications in your farm use HTTPS by default, be sure to check the Content Source settings to be sure that the search crawler can properly access them.
ArticlesTen Steps to Optimize SharePoint
Secrets of SharePoint Part 5: Configuring Microsoft
Office SharePoint Server 2007 for Optimal Performance
Creating End User SharePoint Solutions for Performance
SharePoint 2010 Performance Enhancements for
Microsoft SharePoint Server 2010 for the ASP.NET
Following Best Practices and Avoiding Common Errors with
Microsoft Office SharePoint Server 2007 Development
SharePoint Performance and Capacity Planning
Troubleshooting Common Performance Problems in SharePoint
Channel 9 Interview with Eric Shupps
SharePoint TechTalk - Different Views on Social Computing
SharePoint Post-Deployment Planning and
SharePoint Pod Show - Design for Performance
SharePoint Pod Show - Test Driven Development
Run As Radio - Eric Shupps Improves SharePoint