Making Custom User Profile Properties Searchable in SharePoint 2010

By , October 11, 2010

SharePoint 2010 allows for the creation of custom user profile properties in much the same way 2007 did.  This allows a company to tailor user profiles to fit their unique business needs and better promote social networking in the enterprise.

One issue I recently ran into with this however appeared when I tried to search on these new custom properties.  It so happens, that SharePoint does not automatically tie these new properties into the search experience, even if you mark the new property as one to be indexed.  I am going to walk through the steps required to create a new user profile property and make it appear in SharePoint 2010’s people search so hopefully someone else doesn’t waste as much time as I did getting this to work.

For this example I am going to create a Property called “Previous Customers” that lists all of the customers a person has worked with in the past.  Note that in my case this is a multi-value property, so make your selections accordingly.

Part 1 – Creating a Term Set for the Profile Property (This will store all of the Previous Customers entered by the users in a nice, clean set that is then reusable)

1)      Navigate to the Managed Metadata Service Application in Central Admin

2)      Create a new group for Profile Property Term Sets

3)      Create a new Term Set for the Profile Property you are about to create

Part 2 – Creating the Profile Property

1)      Navigate to the User Profile Service Application in Central Admin

2)      Click on “Manage User Properties”

3)      Click on “New Property”

4)      Fill out the information requested in the dialog box, selecting the term set created in Part 1.

5)      Make sure you select the Indexed check box

Now if you go to a user profile you should see the new property you just created.

So, at this point you may think (I did) that since you clicked the Indexed box, this will be indexed and make people appear in the People Search Results… Wrong!  We still have quite a bit of work to do.

Part 3 – Setting up the Metadata Properties in Search (This is kind of the tricky part)

1)      Navigate to your Search Service in Central Admin (Fast Query Service if using FAST Search)

2)      Click on Metadata Properties

3)      First make sure your Crawled Properties are there – Click on “Crawled Properties” (You may need to do an incremental crawl before they show up.)

4)      Do a search for your term (In my Case, PreviousCustomers – Results are shown in the image below)

5)      You should have two properties, one beginning with “ows_taxId” and the other starting with “People:” – If not, do an incremental crawl and try again, also make sure you filled out at least one profile with some sample data.

6)      We need to create a new Managed Property to map your custom user profile property to, so click back a couple of times and click on “New Managed Property”

7)      Fill out the resulting dialog box, mapping it to your Crawled Property – my example is shown below.

8)      Now go back to your crawled properties and  set their mappings per the image below

a.       Select ContentsHidden as a mapping for your People Attribute

b.      Do not select Included in Index in either one

Now if you kick off a crawl you should get some results back when you perform a search.  What this looks like is shown below.

So, you should notice that while you get a result back (I have “City of” as one of my previous customers) is does not display your custom field in the results.  To correct this we need to modify the xslt in the people results web part.

I hate editing xslt, but find it pretty easy if you copy some of what is already there.  Past Projects for example is an out of the box profile property that is like mine (Multi-Valued, appears in results, text, etc.) so wherever I saw PastProjects in the xslt, I copied that section with my term PreviousCustomers.

Part 4 – Modify the XSLT in the People Search Results Web Part

The three additions are below… I suggest using Visual Studio or something to edit the xslt other than the browser – much easier.

Add A Parameter (I Didn’t end up using this, but added it anyway)

<xsl:param name=”PreviousCustomersLabel” />

Declare a variable

<xsl:variable name=”haspc”        select=”($FilterNodeSet and $FilterNodeSet/@title=’PreviousCustomers’) or hithighlightedproperties/previouscustomers/@hashh &gt; 0″/>

 

Add an If Statement to display the Property

 

<xsl:if test=”$haspc”>

<li>

<span id=”FieldTitle”>

Previous Customers:

</span>

<xsl:call-template name=”RenderSimpleMultivalue”>

<xsl:with-param name=”multivalue” select=”hithighlightedproperties/previouscustomers”/>

<xsl:with-param name=”cutoff” select=”5″/>

</xsl:call-template>

</li>

</xsl:if>

 

The end result is what you wanted to begin with, your results being shown and the proper section being highlighted.


24 Responses to “Making Custom User Profile Properties Searchable in SharePoint 2010”

  1. John says:

    Thanks very much for this post – I couldn’t figure out why I couldn’t search my custom properties in sp2010.
    Related to this: I’m passing a query to the search service but I can’t add my custom (text) field to the “order by” clause – I get “System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]” If I remove my custom field, the search executes fine.

    I get that error when I query using the codeplex “Sharepoint Search Service Tool” which I’m using to troubleshoot.

    Have you see similar? do you have any suggestions?

    Thanks

    -John

  2. Clara says:

    Thanks a lot! Your post is very clear and helpful. I didn’t know about the “ContentsHidden” mapping.

  3. Rusty says:

    Perfect just waht I was looking for ,
    Also anyone know of any way so that a user can select their custom properties whilst editing their profile but instead of typing the metadata term they want against their profile it could be displayed as a series of option check boxes \ tick boxes that refer to the terms? Just I have a 2 page long list of expertise terms I want users to sign up that they have skills in those areas and displaying them would be handier we feel as a page of option dots rather than filling it in via terms in a text box if you follow?

    Sorry for the random question

  4. PaulE says:

    Thanks, Steve! Indispensible. Though, I had difficulties getting it to work until I add my new property to the Fetched Properties XML in the People Search Core Results’ Display Properties. A full crawl may also be necessary: the description on the Crawled Properties page says, “Changes to properties will take effect after the next full crawl.” Thanks for the guidance!

  5. Kenny says:

    Thanks for great tips. Would this solution work with custom property where property is imported from AD?

  6. It should – I dont think there is really any difference as far as SharePoint is concerned, other than the linking of the AD property to the SharePoint property.

  7. Kevin Guuyer says:

    You are a hero Steve, this was killing me and with these changes searching and user profiles are working like a charm. Thanks for sharing!

  8. Matt says:

    Steve,

    Two questions I was hoping you could clarify for me.

    1. In Part 2 – Step 4 you say “Fill out the information requested in the dialog box, selecting the term set created in Part 1.” The “…selecting the term set created in Part 1.” is throwing me. When I create new property the only “selecting” that I’m doing is of what my property is mapped to and we are mapping to to an external content type defined in the BCS. I don’t see anywhere that we can select the term set we created using the Term Store Management Tool.

    2. Even after creating a new Term Set in the Term Store Management Tool and doing a full re-crawl, I’m still not seeing the “ows_taxId_” property? Any ideas on what I might be overlooking here?

  9. Matt says:

    Disregard I see there is a checkbox for that called “Configure a Term Set to be used for this property” that shows up on new, but is disabled existing properties and I was trying to modify an existing property. I was completely overlooking it. Doing this also fixed it not showing the “ows_taxId_” property as well.

  10. Tom Resing says:

    I love how simple you make this with great screen shots. User profiles, search and managed metadata are definitely strengths of the platform in 2010 and I’m glad to see so many taking advantage of them in this way. Keep it up!

  11. TJ says:

    What is the purpose of
    1. Mapping the second crawled property starting ows? I didn’t, and the new managed property was still returned in search.
    2. Mapping the ContentsHidden managed property?

  12. Tony Stark says:

    Got everything to work. However, these term sets are not showing up “Search Options” for end users to pick a value from (like a choice list used to be in sp 2007). I am using the following code to populate properties.

  13. FXOMeara says:

    Great post! I banged my head with the ‘ContentsHidden’ for a while!

  14. Paul Huang says:

    Hi, Steve
    About this statement, “we need to modify the xslt in the people results web part.”, I don’t know which xslt file is what I need to modify, would you please give me a hint? Many thanks.

  15. Jon Withers says:

    Thanks for this excellent post. I have been able to add a NickName property which i can now search using Nickname:jon however if i don’t use the prefix i am unable to search for “jon”. Please can you inform me how i set the search so that it will search the NickName property by default?

  16. [...] Steve McDonnell provides a blog post with screenshots of this and some added XSLT. [...]

  17. Susana says:

    Hi,

    Thanks for your post, very very useful!

    Just one question, how to configure User Profile properties that have a value depending on the language?

    For example, for the description we have one value in Spanish, other in English, and so on.. We saw how to show a different label for a User Profile property, but how can we show a different value of the property? Is is possible to define a group of properties for each language, and search within those properties when search center is used in each corresponding language?

    Regards

    Regards,
    Susana

  18. Sanjay says:

    Hi,

    Thanks for your post, very very useful! it saved lot of my time to complete this task.

    Regards
    Sanjay

  19. Ole Kristian says:

    Hi Steve,
    I have followed your steps, but my issue is that my custom section does not appear in the search result as you have shown in your last screenshot. It seems that I get a search hit as the expected profile is shown in the search result, but no custom section with hightlighting.

  20. Lance says:

    I found that I had to set the Default Privacy Setting of the custom property to “Everyone”. Hope that helps someone.

  21. Sean says:

    Great writeup!

    I have same issue as Ole Kristian however, I am not seeing my custom property show up in the Search Result. The result is there in the results XML, and I see my custom property value (that I searche don to retrieve this), but it doesn;t render with the modified XSL. I have triple checked everything. I am wondering if there is some other configuration causing this…

  22. Sean says:

    Found the solution!

    The tutorial above (first link) is super great, but in the alst section, where they tell you how to modify the XSL in the CoreResults webpart, they leave out one important point: You must add your new custom property to the Fetched Columns list property as well! Its easy to miss! Once you do this, your search will show your custom property properly, with hit highlighting etc…

Leave a Reply