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

Wrapping Long String Values in Firefox

I know it's all the rage among web developers to blame IE for everything that's wrong on the Internet but sometimes - just sometimes - the folks in Redmond get it right and the fine volunteers of the Mozillaverse get it wrong.  Perhaps there's no better example of this than word breaking in columns.  For years, IE has had the ever-so-useful CSS property "word-wrap" which, when supplied with a value like "break-word", will split up a long string of text and preserve the precious layout you've slaved for hours to create.  It's so handy, in fact, that it actually made it into the CSS3 spec (don't be a hater - even the standards busybodies know a good thing when they see it).

Unfortunately, Firefox doesn't recognize this property.  Yes, I know it's supposed to in version 3.5+ but I have yet to see it actually working.  I've spent the better part of the last 9 months doing JavaScript programming for SharePoint 2013 apps so I've spent way too much time testing browser compatibility and not once have I seen FF honor this property.  Perhaps there's some secret Little Orphan Annie Decoder Ring trick to make it work - if so, please share it with me but until then we'll have to continue  hacking our way around this ridiculous exclusion in an otherwise fine browser.

A lot of people suggest doing this in CSS like so:

.wrap {
white-space: pre-wrap;       /* CSS3 */
white-space: -moz-pre-wrap;  /* Mozilla */
}
But I've found that solution is spotty - it sometimes works and sometimes doesn't (mostly the latter).  Instead, I prefer to use JavaScript to solve this problem, which eliminates the need for browser-dependent CSS tricks.  Taking, for example, a string that has 20 characters and must fit into a column that only permits 10 characters, the solution would look something like this:

var newstring = oldstring.replace(/([^\s\t\r\n<>]{11})/g, "$1<wbr>");

Or, if you would prefer a hyphen instead of a soft line break:

var newstring = oldstring.replace(/([^\s\t\r\n<>]{11})/g, "$1&shy;");  

Inline replacement is fine but if you end up doing it repeatedly within an application all those Regular Expressions get pretty redundant.  Plus, it would be nice to be able to specify the length as a parameter for a reusable function.  A quick bit of additional code will get us there:

function breakWord(string, length) {
    var reg = new RegExp("([^\s\t\r\n<>]{" + length + "})", "g");
    var s = string.replace(reg, "$1<wbr>");
    return s;
}
We can now call that function on any string we like:

var newstring = breakWord(oldstring,10);
Ah, that's better.  Word breaking for any string in IE and Firefox.  Now, Microsoft, let's talk about all those web pages that don't work in IE10, shall we?  Like, I dunno, just as a random example, SharePoint 2010 dialogs.  How 'bout it?


Articles
Ten 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