SSL and Empty SharePoint People Search Results

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 Performance

Webcasts

Secrets of SharePoint Part 5: Configuring Microsoft Office SharePoint Server 2007 for Optimal Performance
Creating End User SharePoint Solutions for Performance and Scalability 
SharePoint 2010 Performance Enhancements for Administrators
Microsoft SharePoint Server 2010 for the ASP.NET Developer
Following Best Practices and Avoiding Common Errors with Microsoft Office SharePoint Server 2007 Development
SharePoint Performance and Capacity Planning Essentials
Troubleshooting Common Performance Problems in SharePoint 2010

Videos

Channel 9 Interview with Eric Shupps
SharePoint TechTalk - Different Views on Social Computing
SharePoint Post-Deployment Planning and Management

Podcasts

SharePoint Pod Show - Design for Performance
SharePoint Pod Show - Test Driven Development
Run As Radio - Eric Shupps Improves SharePoint Performance