This is especially a problem with the out-of-the-box webpart that shows information about a person:



When you click on one of the values in this webpart, you will be redirected to the people search results page with the value you clicked passed in as the search keyword:



But this will not give you any results. This post by kgreame outlines the same problems and some of the steps he tried to solve this issue. In the comments to that post, a workaround is mentioned: map the matching crawled properties to the ContentsHidden Managed Property.
There is however an other way. In this post by Larry Kuhn, he explains how the DEFAULTPROPERTIES within the SharePoint Search work. By setting a weight of a Managed Property, you will include it in the ranking model SharePoint uses and the property is therefore added to the default properties that are searched.
SharePoint 2010 introduces the concept of Ranking Models, so the solution mentioned in that blogpost doesn’t work. We can however create our own Ranking Model. I’ve copied the information from the Ranking Model that SharePoint uses for People Search and added my own Managed Property, Expertise, with a weight of 1.0:

<?xml version="1.0" encoding="utf-8"?>
<rankingModel name="CustomPeopleRanking" id="5EA2750C-8165-4f65-BD12-6E6DAAD45FE0" description="Custom People Ranking" xmlns="http://schemas.microsoft.com/office/2009/rankingModel">
  <queryDependentFeatures>
    <queryDependentFeature pid="177" name="RankingWeightName" weight="0.5" lengthNormalization="0" />
    <queryDependentFeature pid="19" name="PreferredName" weight="1.0" lengthNormalization="0" />
    <queryDependentFeature pid="24" name="JobTitle" weight="2.0" lengthNormalization="0" />
    <queryDependentFeature pid="39" name="Responsibilities" weight="1.0" lengthNormalization="5" />
    <queryDependentFeature pid="179" name="RankingWeightLow" weight="0.2" lengthNormalization="5" />
    <queryDependentFeature pid="175" name="ContentsHidden" weight="0.1" lengthNormalization="5" />
    <queryDependentFeature pid="35" name="Memberships" weight="0.25" lengthNormalization="5" />
    <queryDependentFeature pid="178" name="RankingWeightHigh" weight="2.0" lengthNormalization="0" />
    <queryDependentFeature pid="180" name="Pronunciations" weight="0.05" lengthNormalization="0" />
    <queryDependentFeature pid="408" name="Expertise" weight="1.0" lengthNormalization="0" />
  </queryDependentFeatures>
</rankingModel>

We can then add this Ranking Model to SharePoint with Powershell:

Get-SPEnterpriseSearchServiceApplication | New-SPEnterpriseSearchRankingModel

And paste in the XML of this Ranking Model when Powershell prompts you for it.

But how do we force SharePoint to use this Ranking Model? I’ve outlined one of the solutions in a previous post.

So after adding a web part that sets the ranking model we can perform the search again:


And bingo, the user with this value in an extra profile property shows up in the search results.

Why use this over mapping the properties in the ‘ContentsHidden’ Managed Property? As you can see the ‘ContentsHidden’ property is included in the Ranking Model with a value of 0.1. If you want to give more weight to a custom property or you have more properties to which you want to assign a different weight, you will need to modify the Ranking Model.

Bookmark to:

People Search: Use a custom Ranking Model to search in added Profile Properties is a post from: Peter Gerritsen's blog

Profile types

You can specify sub-types for profiles. For each profile property you can configure for which types the property is used. A user will be able to see or edit only those properties that are linked to their Profile type:

In the Profile list or Profile property list you can filter the list by profile sub-type:

Organization profiles

You can now import organizations from your profile store. This includes options for importing organizations in a hierarchy. The organization profile system also supports specification of Profile Types, so different types of organizations can have different properties.

The hierarchy is specified by selecting a parent organization in an organization profile. You can also specify the leaders of an organization and the members of that organization. This will link the specified user profiles to this organization:

Property Synchronization

Profile properties can now be exported as well. This allows for users to edit a property value which is then updated in your identity store such as Active Directory:

This sync is one way only, so a property can be imported or exported, but there’s no option to keep the two values in sync in a bi-directional way. Export to BCS sources is also not supported.

Term store used for choices

Properties that are defined with choices are linked to the Term store. So there’s a single management system for choice fields across the SharePoint farm:

The property will use the configuration of the Term set to define if users are allowed to use fill-in choices.

Multiple import connections

In SharePoint 2007 you were only able to import from one primary store. So importing from 2 or more Active Directories or a custom user database was not supported. In 2010 this is supported. You can now specify more then 1 import connection to import accounts from AD as well as a LDAP or BCS store.

Import filters

You can specify exclusion filters for your import connections. This will allow you to filter out user or organization profiles when importing from you identity store:

Conclusion

The SharePoint team has done quite a big overhaul on the user profile system. A lot of pain points from MOSS 2007 have been solved, the system allows for more granualarity in configuration of the profiles and has been integrated nicely with new functionality such as the Term store (a.k.a. Managed Metadata Service)

Bookmark to:

SharePoint Server 2010 User Profile System is a post from: Peter Gerritsen's blog