Using Federated Search in Geographic Environments

Greetings, my name is Brenda Carter, I am a technical writer who writes content for the IT Pro audience about Office SharePoint Server and Windows SharePoint Services. 


The purpose of this blog entry is to tell you about the new federated search functionality that is part of the Infrastructure Update and how it can help you pull search results together in environments where multiple farms are deployed geographically, such as in the following diagram.




For more information about our overall solution for deploying geographically, see the blog article I posted on the product team blog: Deploying Microsoft Office SharePoint Server 2007 geographically. You’ll learn our recommendations for deploying across the globe and even see a sampling of our WAN test results. Plus, you’ll get to know the consulting team and product team members who contributed to this guidance. You can also go directly to our planning content on TechNet: Plan to deploy Office SharePoint Server globally.


Recommendations for using federated search in a geographic environment are provided by:

·         Luca Bandinelli, previous SharePoint Ranger (Consultant) specializing in search and current Program Manager on the Customer Advisory team.

·         Keller Smith, Program Manager on the Search team

·         Richard Riley, Technical Product Manager


How federated search works

Federated search enables end users to issue a query that searches multiple sources and displays results in separate Web Parts on a single search results page. In a distributed environment with server farms in different regions, federated search can be configured on each of the regions representing a different federated location. The user will see search results from each region in a different federated results Web Part. The results can be displayed as soon as they are received. For example, search results from the local server farm will most likely be returned before search results that are received over WAN connections.


The following diagram illustrates the use of federated search in a geographically distributed environment in which Microsoft Office SharePoint Server is deployed to each region.




In this diagram:

·         A user at Regional Farm 2 issues a query.

·         The query traffic is sent to a Web server at the local farm. The Web server forwards the query to the federated search locations.

·         Query A and B are federated locations and are sent to the geographically distributed farms.

·         Query C is a local search that is served by the local farm.

·         Search results are displayed on one Web page in separate Web Parts.


Configuring federated search in distributed environments

Using federated search, each server farm crawls its own content. For server farms running Office SharePoint Server, this requires an SSP at each regional farm. You create a federated connection to a remote server farm running Office SharePoint Server by creating (on the local server farm) an OpenSearch federated location. The OpenSearch federated location must point to the RSS feed of a search results page within a search center on the remote farm. You include the local farm in federated search by creating a “local search index” type of federated location. To implement federated search in a distributed environment, configure each farm with federated locations to the other farms.


The following diagram illustrates in greater detail a federated search connection to a remote farm.



In this diagram:


·         On the Central Farm, a Search Center is added to the Company Info site collection. This Search Center is configured with the scope that allows users to search across the farm. This Search Center includes a Search Results page. An RSS feed is enabled for this page.


·         On the Regional Farm, a federated search connection (callout A) is configured to connect to the Search Results page of the Central Farm. This allows local users at the Regional Farm to search across content at the Central Farm.


Summary of federated search

There are many advantages to using federated search in a geographic deployment. Federated search eliminates the need to crawl content over WAN connections or to synchronize content over WAN connections. Displaying the results in separate Web Parts helps users distinguish where content is located, making it easy to identify local content. Understanding where content is located can also help a user determine which results are most likely to be relevant.


There are a few drawbacks to this architecture, though. First, enterprise-wide relevance in search results cannot be achieved. Instead, relevance is scoped to each federated location. Next, query performance for remote locations is subject to WAN links. However, users typically receive search results for the local farm rather quickly.


The following table summarizes the tradeoffs of the federated search architecture.




·          Provides enterprise-wide search.

·          No limitation to the number of documents or items that can be searched.

·          Content is not crawled or synchronized over WAN links.

·          Query performance is optimized for local content while at the same time providing results for remote content.

·          Users can search different locations without connecting to each location separately.

·          Each content store can be managed separately.

·          Windows SharePoint Services with Search Server 2008 can be used at regional farms, instead of Office SharePoint Server.

·          Security-trimming is preserved for the local farm and for remote farms if Kerberos authentication is used.

·          Search relevancy is not enterprise-wide. Relevancy is scoped to each content source.

·          Managing multiple SSPs or deployments of Search Server 2008 increases administrative costs.

·          Query performance for remote locations is subject to WAN links.

·          Because content is not synchronized across the environment, users will be downloading documents over WAN links during peak hours for bandwidth utilization.

·          Users cannot use advanced search options.

·          If Kerberos is not used, preserving security-trimming of search results requires extending federated search Web Parts.


More information

For more information about using federated search in a geographically distributed environment, see Plan for global enterprise search. This article includes more information about:

·         Configuring federated search in geographically distributed environments.

·         Using federated search with farms running Windows SharePoint Services 3.0.

·         Additional search architectures that are recommended for geographically distributed environments.


Let us know what other content you are looking for to architect your global search strategy. 


Thanks, Brenda


Comments (8)
  1. Hi Sabin,

    I tracked down an answer for you from the search team. Let me know if this does not work.

    Thanks, Brenda


    You can change this by modifying the rss page.  In order for it to be supported, you’ll have to make your own version of the RSS feed.  We don’t support changing the OOB files because these get overwritten upon upgrade/patching.

    On each WFE:

    1. Copy D:Program FilesCommon FilesMicrosoft Shared DebugWeb Server Extensions14TEMPLATELAYOUTSsrchrss.aspx

    2. Rename the file to “mysrchrss.aspx”.  Keep it in the LAYOUTS folder.

    3. Open the file.  You’ll see a small file that contains this XML:



    4. Add a line to this structure:




    5. Direct any queries you want against the new rss file.  Treat it just like you would the regular rss (same url paramanters, etc).

    This should change it.  The range is 1<=x<=50.  Try this in a test environment first.

    If you want to change the link in the search results UI page to go against a new RSS feed, you will have to…

    • Edit the XSLT of the Actions web part

    • Add some code that parses the rss url for “srchrss” and replaces it with “mysrchrss”

    Changing it in the UI may be unnecessary if you only want programatic access to the RSS elements (i.e. through an RSS reader).

  2. Thanks, David! I fixed the broken link. Brenda

  3. Hi Marvin,

    I verified this with a member of the product team. You can consolidate results using two different methods:

    1) Same result page: you can have different federated web parts that get information from different sources display results in the same page

    2) There’s a special federated web part that provides summary (to results) of your results from all federated connections.

    Even with these methods, though, there is no unique ranking for results in different locations even if these are SharePoint results.

  4. Sabin BARLUT says:

    Hi Brenda,

    Thanks for the article. When I use the Federated Search Webparts, I can only get 10 results. This is because the RSS feed from the SharePoint Search Page only provides 10 results. Do you know of a way to increase the number of items returned from SharePoint in the searchRss.aspx Feed???



  5. Sabin BARLUT says:

    Hi Brenda,

    Thanks for the answer. This works great. I had figured out up to changing the value.However I was using the same OOTB file. You are right, in an update my changes may get blown away.

    Thanks again for your help.


  6. marvin says:

    Hi I have a question Im a admin of MOSS in my company and I want to know is it possible to have a consolidated result from diffrent federated search?

Comments are closed.

Skip to main content