Crawled properties are metadata properties that are exposed or derived from documents, lists, libraries and anything else that can be indexed. When you search in SharePoint, these crawled properties have to be mapped to managed properties, which will be displayed in search results and refinements. While you may already know this, consider the impact on your organization, or your client’s for that matter, if something goes awry with a key SharePoint component that boasts robust capabilities: Enterprise Search.

Recently I was involved in a project where we had to customize the end-user search experience. The requirement was to have the People Search Core Results web part display specific results, with limited styling applied, and to set a scope on search results based on the boolean value of a managed property. To achieve this I had to alter the fetched property list and the web part’s XSLT transformation style sheet, define the rules used in scope, and apply the scope. There are many articles that explain how to do each one of these tasks in detail, while in this post I provide a more high-level explanation and possibly a solution for an issue I encountered along the way. (As always, best practice dictates that we do not make mods to the OOB search pages, but make copies and work on those instead). Additionally, to make the following configurations you must be a member of the Site Collection Admin group at the very least.

1) Search for a person in your Search Center. From the ribbon or Site Settings, select to edit the results page. Once in edit mode, edit the People Search Core Results web part. In the web part edit tool pane, expand the ‘Display Properties’ node, uncheck the ‘Use Local Visualization’ check box, Ctrl +A the Fetched Property list in the text box and copy to clipboard. To go back to the default property settings all you have to do is re-check the ‘Use Local Visualization’ check box.

Paste the Fetched property list into Visual Studio or the editor of choice. I didn’t remove any of the OOB properties and just added my own at the bottom. You will customize which ones actually show up on screen in the XSLT style sheet, so there is no harm in leaving the default ones in there. Fetched properties are simply managed properties, so a precursory measure to double-check that they exist and are mapped to the correct crawled properties is advised. If all props are there and mapped, simply paste the modified fetched property list back into the text box.

Hint: You will have to format the list so that the properties are on a single line, as opposed to a block of XML; this is the only way to get them all into the text box.
<Columns><Column Name="ColumnName1"/><Column Name="ColumnName2"/><Column Name="ColumnName3"/></Columns>

2) Click on the XSLT Editor, and copy and paste the XSL code into VS to alter which properties are displayed in search results. First, define the variables right below this line ‘<!-- This template is called for each result –>’ and map them to your managed properties. Follow the OOB variable definition, like in the following snippet:
 

<xsl:variable name="hassip" select="string-length($sip) &gt; 0"/>
<xsl:variable name="hasemail" select="string-length($email) &gt; 0"/>
<xsl:variable name="haspn" select="string-length($preferredname) &gt; 0"/>
<xsl:variable name="hasydn" select="string-length($yomidisplayname) &gt; 0"/>

Second, in the body, call the variable and pass value.

<xsl:if test="$hascompany">

<ul id="CompanyField" style="display: inline; font-size: 12px; color: #737373">

<xsl:value-of select="company" />

</ul>

</xsl:if>

In this example the variable is’ $hascompany’ and the managed property is ‘company’. Use lowercase letters. You can also specify inline styles here, although linking to an external style sheet in your Style Library would be a cleaner alternative. Save and publish your page.

3) Assuming that you’ve already created the scope(defined rules) in CA’s Search Services or Site Administration's Search Scopes (depending on permissions), list its name in the People Search Core Results web part under the Location Properties node in the Scope text box and click ‘OK’ to save. Publish your page and test search scope. This is where my trouble began.

The scope would not apply to search results because the crawled property mapped to the managed property in my scope rule wasn’t being crawled. The settings for that crawled property listed no content using it, which was inaccurate. I checked my settings for the respective user prop, made sure it was being indexed, set some profiles to use it, ran a full crawl and even performed an IIS reset, to no avail. We even tried to create new user properties to set the scope rule with, but it seemed as if SharePoint stopped creating crawled properties altogether. At this point I called Microsoft to obtain an explanation for this unusual behavior. While awaiting a call-back from MS Tech Support and after hours and hours of digging, I found an obscure article where the author was experiencing the same issue in a multi-tenant environment. He mentioned checking the host file to make sure the right site collection was mapped to the IP address.
What I found was that the site collection I was working on had the word ‘intern-’ preceding the site collection name (this had to be system generated). I left it alone and simply added another instance of my site collection, sans ‘intern-‘, followed by another full crawl. Lo and behold crawled properties started showing up again at creation. I then mapped a new crawled property to the managed property needed for scope, referenced the scope name in the web part, and everything seemed to work just fine. I am still researching the relationship between mappings of IP addresses to host names and the SP index crawler. If anyone in the blogosphere has any insight, send it this way, otherwise this all may have been a terrible coincidence and a wonderful learning experience!