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

But how do you tell the search web parts to use your custom ranking model, once you specified it? As far as I can tell there’s 2 options:

• Pass in the id of the model through the querystring by appending “&rm=<guid of ranking model>”
• Use the Shared Query Manager

The Shared Query Manager is _the_ option for modifying the query the search web parts are going to use.

To use the Query Manager to set an other Ranking Model I’ve created a custom web part. To retrieve the Query Manager all you have to do is call the static GetInstance method of the SharedQueryManager class.

After that, you can loop through the query manager and each location within the LocationList to set the ID of the Ranking Model:

public class SetRankingModel : WebPart
    {
        protected override void OnInit(EventArgs e)
        {
            try
            {
                QueryManager qm = SharedQueryManager.GetInstance(this.Page).QueryManager;

                foreach (LocationList ll in qm)
                {
                    foreach (Location l in ll)
                    {
                        try
                        {
                            l.RankingModelID = "5ea2750c-8165-4f65-bd12-6e6daad45fe1";
                        }
                        catch { }
                    }
                }

                base.OnInit(e);
            }
            catch { }
        }
    }

After you’ve placed this web part on a search results page, each web part will use your custom Ranking Model.

Bookmark to:

Let the SharePoint Search web parts use an other Ranking Model is a post from: Peter Gerritsen's blog

First I added a metadata property ItemDeclaredRecord that is mapped to ows__vti_ItemDeclaredRecord (DateTime).
Then I tried the following query (using Steve Peschka’s Developer Search Tool):

SELECT Size, Rank, Path, Title, Description, Write FROM scope() WHERE (ItemDeclaredRecord > '1900/01/01 00:00:00') AND CONTAINS (Path, '"/projecten"')


This query works fine and retreives all records declared after January 1st, 1900 under the “projecten” site. To retreive all records within a specific subsite I then tried the following query:

SELECT Size, Rank, Path, Title, Description, Write FROM scope() WHERE (ItemDeclaredRecord > '1900/01/01 00:00:00') AND CONTAINS (Path, '"/projecten/subsite1"')

This threw a FaultException?!
After fiddling around with the query for a few hours, I finally found a query that works:

SELECT Size, Rank, Path, Title, Description, Write FROM scope() WHERE (ItemDeclaredRecord > '1900/01/01 00:00:00') AND CONTAINS (Path, '"/projecten/subsite1"') ORDER BY Rank DESC

I’m not sure what the ORDER BY part does to the search system internally, but for now I’m guessing it’s SQL for ‘Pretty pretty please!’.

EDIT:
The property you add in the ORDER BY part has to have the “Reduce storage requirements for text properties by using a hash for comparison” option checked.

Bookmark to:

Strange FullTextSqlQuery query behaviour (System.ServiceModel.FaultException) is a post from: Peter Gerritsen's blog

For instance if you would like to filter on a date, you could use the following query:

LastModifiedTime>=01/06/2010

The actual format of the date depends on your regional settings (I’m using Dutch (nl-NL) in this case).

To search within a range of dates you can use the following query syntax:

LastModifiedTime:28/06/2010..30/06/2010

To exclude items you could use the following syntax:

LastModifiedTime<>28/06/2010

More info from MSDN about keyword syntax kan be found here: http://msdn.microsoft.com/en-us/library/ee558911.aspx

Bookmark to:

SharePoint 2010 Search: Property Restriction in Keyword Queries is a post from: Peter Gerritsen's blog

This is done by specifying a keyword query like 9:”folder/subfolder”. In this case the searchproperty 9 contains the path of the item.

While this worked well on our development environments and most of the browsers we tested on, a some browsers it failed. My colleague Arthur discovered it had something to do with the language setting of the browser. When we used Dutch (nl-NL) as preferred language the standard core search results web part didn’t return any items when using a query with a “/” in the conditions.

If you execute a KeyWordQuery or FullTextSqlQuery in your own code you have the possibility to specify a culture to use in the search. Unfortunately the core search results web part doesn’t provide you with an option to do this easily. In the end I came up with a “hack” to make this work. Just change the preferred languages the browser sends with each request in the OnInit of a webpart that inherits from the standards core results web part like so:

protected override void OnInit(EventArgs e)
{
	if (!string.IsNullOrEmpty(CultureOverrideTo))
	{
		if (this.Page.Request.UserLanguages.Length > 0)
			this.Page.Request.UserLanguages[0] = “en-US”;
	}

	base.OnInit(e);
}

Note: Because this modifies the current request this can have some consequences on other web parts on your page. So use it with care.

UPDATE:

This same behavior can also occur in custom search code. To fix this, simply specify the Culture of your KeyWordQuery or FullTextSqlQuery.

Bookmark to:

MOSS Search and browser languages is a post from: Peter Gerritsen's blog