FAST Search User Contexts and Site Promotions in SharePoint 2010

You may have heard about this cool feature of FAST Search for SharePoint Server 2010 (FS4SP) called user context. FAST Search user contexts allow you to use SharePoint user profile property values such as Office Location and Ask Me About (in the out-of-the-box configuration) or any other to boost search results.

This article shows how easy it is to configure a SharePoint user profile property to be used with FAST Search user contexts, define user contexts based on specific property values and then associate those user contexts with sites and documents to be boosted in search results (feature called FAST Search Site Promotions). You have an option to use SharePoint user interface or PowerShell to perform most of the configuration steps so I’ll cover both. As an example, I’m going to use standard Department user profile property to boost search results for certain SharePoint sites for different users. Users from Sales and Marketing departments will have different search results boosted for the same search term.

We’ll start by configuring the FAST user context to be based on the Department user profile property using the following PowerShell command :

Add-PSSnapIn Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
Set-SPEnterpriseSearchExtendedQueryProperty -SearchApplication "FASTQuery" -Identity "FASTSearchContextProperties" -Value "Department"

Next we need to perform an iisreset on the SharePoint WFE in order for the change to be reflected in the UI.

We can now add new user contexts by using different variations of the Department property values by going to Site Actions -> Site Collection Administration -> FAST Search user context -> Add User Context. Let’s go ahead and create a user context for Sales and Marketing.

If you have a large number of user contexts to be created and deployed to multiple environments then you may want to automate the process with PowerShell:

Add-PSSnapin Microsoft.FASTSearch.Powershell -ErrorAction SilentlyContinue

$siteCollectionId = "69d025ce-96a7-4131-adc0-7da1603e8d24"
$searchSettingGroup = Get-FASTSearchSearchSettingGroup -Name $siteCollectionId

$userContext = $searchSettingGroup.Contexts.AddContext("Sales")
$expression = $userContext.AddAndExpression()
$expression.AddMatchExpression("Department", "Sales")

$userContext = $searchSettingGroup.Contexts.AddContext("Marketing")
$expression = $userContext.AddAndExpression()
$expression.AddMatchExpression("Department", "Marketing")

Note that the commands above need to be executed on the FAST Search server and remember to use the site collection ID of the site collection that hosts your search center site. As you can see, the script approach is much more flexible than the SharePoint user interface in terms of the expressions you can use to define the context.

Once the user contexts are setup, you should see something similar on the Manage User Context page:

Next we are going to add a couple of site promotions and associate each one with a different user context. Navigate to Site Settings -> Site Collection Administration -> FAST Search site promotion and demotion -> Add Site Promotion, then add the Sales team site url to the Promoted Sites list and Sales user context to the User Context list:

Follow the same steps to create another site promotion but this time for the Marketing team site.

An alternate way of creating site promotions would be using the following PowerShell commands:

Add-PSSnapin Microsoft.FASTSearch.Powershell -ErrorAction SilentlyContinue

$siteCollectionId = "69d025ce-96a7-4131-adc0-7da1603e8d24"
$searchSettingGroup = Get-FASTSearchSearchSettingGroup -Name $siteCollectionId

$siteUri = New-Object -TypeName System.Uri -ArgumentList "http://intranet.contoso.com/sales"
$sitePromotion = $searchSettingGroup.PromotionsWithoutKeyword.AddPromotion("Sales")
$sitePromotion.PromotedItems.AddPromotedLocation($siteUri)
$sitePromotion.Contexts.AddContext("Sales")

$siteUri = New-Object -TypeName System.Uri -ArgumentList "http://intranet.contoso.com/marketing"
$sitePromotion = $searchSettingGroup.PromotionsWithoutKeyword.AddPromotion("Marketing")
$sitePromotion.PromotedItems.AddPromotedLocation($siteUri)
$sitePromotion.Contexts.AddContext("Marketing")

When creating site promotions using PowerShell, you also have the ability to specify a boost value other than the default value of 1000. Simply set the $sitePromotion.BoostValue property to the desired value.

Finally, we are ready to verify if the search result boosting actually works. We are going to use the FAST Search for SharePoint 2010 Query Logger tool to take a look at the FQL commands being submitted and executed on the FAST query server. If we execute a search query in SharePoint using credentials of a user account having the Department user profile value set to Sales, we’ll see that an additional xrank expression has been added to the original query:

As you can see, the boost of 1000 points has been added to the final rank of the sales presentation document located on the Sales team site:

I hope you find it useful to see a specific example of creating FAST Search user contexts and site promotion in both SharePoint user interface and with PowerShell. In my next post, I’ll expand on the topic of user contexts and show an example of best bets targeting.

Search and Claims-Based Authentication in SharePoint 2010

In order to enable crawling for web applications configured with claims-based authentication in SharePoint 2010, it is required that Windows Authentication is enabled for at least one Zone. In cases when Forms Based Authentication or a Trusted Identity Provider is configured for the Default Zone, it is a common practice to extend the web application and enable Windows Authentication for the extended zone. Search is then setup to crawl the extended zone url. There’s a couple of issues with crawling a non-default zone though:

  1. Documents in the index are tagged with the extended zone urls so the search results in the Search Center point to that location rather than to the default zone
  2. Contextual search (This Site) doesn’t work as SharePoint appends the default zone url filter to the search query

Those may sound like major obstacles but it turns out there’s a simple solution, although it does require some manual configuration in Central Administration. The following steps apply to both SharePoint 2010 Search and FAST Search Server 2010 for SharePoint.

In Central Admin, navigate to Manage Service Applications -> Search Service Application (FAST Search Connector for FS4SP), then click on Server Name Mappings within the Crawling section.

Now add a new mapping for each non-default zone url being crawled. Enter the extended zone url in the “Address in index” field and the default zone url in the “Address in search results” field.

Once all server name mappings are in place, complete a full content crawl and that’s it! Your search results will show correct urls in the Search Center and contextual search will work properly.

GAC Multiple Assembly Versions Using SharePoint 2010 Solution Package

Ever wanted to deploy multiple versions of an assembly to the GAC as part of a SharePoint 2010 solution package? Visual Studio 2010 makes it easy to GAC a single assembly version but will throw an error similar to the one below if you try to package a project with multiple versions of a dll, in this case AjaxControlToolkit.dll.

Both "Contoso.SharePoint" and "Contoso.SharePoint" contain a file 
that deploys to the same Package location: AjaxControlToolkit.dll.

The solution is simple and this post walks through it step-by-step.

We start with no AjaxControlToolkit.dll versions in the GAC.

Next, we are going to create a new SharePoint 2010 project in Visual Studio 2010 (or you can use an existing project).

Make sure that “Deploy as farm solution” option is selected.

Then double-click the Package.package in the Solution Explorer and click Advanced in the lower-left corner.

Press Add and select the “Add Existing Assembly…” option, browse to the location of one version of the assembly – in my case 3 different versions are stored in subfolders under the AjaxControlToolkit parent folder. Visual Studio automatically populates the Location field with the assembly name – go ahead an prefix the name with the version number followed by a backslash. Repeat for each version of the dll.

Now all versions of the assembly should appear in the Additional Assemblies grid in Visual Studio.

If we package the project and browse to the pkg folder, you’ll see that each version of the assembly is located in a separate subfolder.

Opening the manifest file also confirms that all assembly versions are included in the solution package.

Go ahead and deploy the solution package and, voilà, all of our assembly versions are now in the GAC!