Federating Search

Sometimes you cannot or do not want to use the SharePoint 2010 search engine for some content sources but still want to return search results from that content. For this scenario, you can consume search results from a federated source.

Federation can be configured from locations that are OpenSearch 1.0/1.1-compatible and can return with RSS or Atom of the result set.

The following is a list of circumstances when federation needs to be used:

• The content source is huge, and you don’t want to build your own index of it (for example, MSDN, or Wikipedia sites).

• The content in the source changes often, and you need immediate crawling instead of SharePoint’s scheduled crawling.

• The queries have to be processed under a different security context.

• You need only the results with specific keywords or keyword patterns in the query.

• The content is queried infrequently.

• You have more than 500 content sources.

The following list contains the cases when federation should be not used:

• There is not enough bandwidth between the SharePoint farm and the federated location.

• Content changes often, but immediately crawling is not needed.

• The content is not or cannot be crawled by the remote search engine.

• The remote server does not return with RSS or Atom.

In most cases, the federated location is some external search engine. However, if SharePoint can crawl the content, but you have other specific requirements (for example, keyword restrictions or different security context), SharePoint can be its own federated location as well.

Federated locations can be defined on the admin page of the search service application, by performing the following steps:

1. Go to the administration page of the search service application.
2. Click on Federated Locations in the group Queries and Results of the left navigation bar.
3. Click New Location.
4. Fill in the basic properties: Location Name, Display Name, and Description. Author and Version are optional.
5. Trigger is the field where you can configure when this federated location has to be searched. The trigger types are the following:

   • Always— Query should always match.

   • Prefix— Query must begin with a specified prefix. For example, if you use the prefix SharePoint, and the query is SharePoint ECM, the federated location will be queried with the term ECM. If the query is ECM, the federated location will not be queried because the prefix SharePoint is missing.

   • Pattern— Query must match a specific pattern or a .NET regular expression capture group. For example, use the pattern (^([w-.]+)@([w-]+.)+([a-zA-Z]{2,4})$) for matching email addresses.

6. Select the Location Type. Use SharePoint Index on This Server if you want to use the local SharePoint index. FAST Index also can be selected for the results of a FAST Search Server. Select OpenSearch 1.0/1.1 to use remote federated location.
7. Configure the Query template. In this expression, the federated location’s query URL TEMPLATE can be configured. {searchTerms} means the query term that is passed to the remote search engine. For example, in case of using Bing as a remote search engine, the Query Template looks like this: http://www.bing.com/search?q={searchTerms}&format=rss
8. The More Results link template links to the URL that will be opened when the users click on the More Results link of the federated result set. It can be the same as the Query Template, but it’s not necessary.
9. The display formatting can be configured as XSL transformations. The result sets are in XML format so that these XSLs can define how to display them. Feel free to change it or use the default one.
10. Define usage restrictions, if you want to define what site domains can use this location.
11. Federated locations can be accessed with specific credentials different from the default one. Various types of credentials can be configured as follows:

    • Anonymous

    • Common authentication should be used when all queries have to be run with the same credentials. The types of common authentication are the following:

    • Basic Authentication

    • Digest Authentication

    • NTLM—Application Pool Identity

    • NTML—Username and password

    • Form Authentication

    • Cookie Authentication

    • User authentication also can be used if you don’t have common credentials for the whole company but would like to authenticate each user with a unique account. The types of user authentication are the following; in each case, the user has to be authenticated before using the federated location:

    • Kerberos

    • Basic Authentication

    • Digest Authentication

    • NTLM—Username and password

    • Form authentication

    • Cookie authentication

Table 8.1 describes the advantages and disadvantages of search federation.

Table 8.1. The Advantages and Disadvantages of Search Federation in SharePoint 2010

Federated locations also can be exported and imported. The steps of exporting a location follow:

1. Go to the admin page of your Search Service Location, and choose Federated Locations from the display group Queries and Results in the left navigation bar.
2. Here you can find the configured federated locations. Choose the one you want to export, and open its context menu.
3. Click Export Location.
4. The location definition will be generated in .OSDX format. Choose a place to save it.

The steps for importing an .OSDX definition file are as follows:

1. Go to the admin page of your Search Service Location, and choose Federated Locations from the display group Queries and Results in the left navigation bar.
2. Click Import Location.
3. Enter or browse the full path to the .OSDX file, and click OK.
4. After a successful import, you can edit the newly created location by choosing the option Edit Location, or finish the importing by clicking on Done.