Migration to Fast Search for SharePoint 2010 – General Considerations

Uncategorized 6 Minutes

I’m currently working on an engagement where the customer is looking for upgrading his current SharePoint 2010 Enterprise Search to Fast Search for SharePoint 2010, but I was wondering if there are any issues that need to be considered during this process.In this post I will highlight some of the issues that need to be considered before doing the implementation so that you could use it as a reference for planning the Migration of Fast Search for SharePoint 2010. For more information please check the references section below.

1.       Search alerts

By using search alerts in SharePoint Server 2010, users can receive daily or weekly updates on all the new or changed documents for a specific query. FAST Search Server 2010 for SharePoint does not keep information about when a document was first indexed or when it was modified, and therefore does not provide this feature. However, similar alerting functionality can be achieved via partners or Microsoft Services. A possible approach would be to save the queries, run them as batches, and then use an external mechanism to track results that have or have not been presented before.

2.       Social tagging and its effect on relevance ranking

Social tagging is provided in SharePoint Server 2010 enterprise search. The feature is available through information that is stored in and extracted from a separate user information database. FAST Search Server 2010 for SharePoint expects to find all relevant information from the crawled document metadata. Because social tagging is not stored in the metadata, FAST Search Server 2010 for SharePoint cannot return this information. This does not mean that social tagging is removed completely, only its effect on search results and the possibility to present or refine on social tags in search results.

If the information still exists in the user database, it is possible to tag content and have other users see the tags. Social tagging and relevance ranking can then be implemented through custom code created by a partner, Microsoft Services, or on-site developers.

3.       Definition extraction

SharePoint Server 2010 extracts meanings of definitions from indexed text. Definition extraction occurs during a crawl and is a process of associating terms with one or more descriptions through the recognition of cue phrases. FAST Search Server 2010 for SharePoint does not have a similar feature.

4.       Crawl rules for document formats

SharePoint Server 2010 specifies the document formats to be crawled by defining a set of File Types to include in the content index. For more information, see Operations – Add a file type to the content index (http://technet.microsoft.com/en-us/library/ff621093.aspx).

FAST Search Server 2010 for SharePoint handles this in the opposite way. Instead of defining what to include, you specify the file types to be excluded from a crawl. For more information, see Operations – Include a file type in the content index (http://technet.microsoft.com/en-us/library/ff191221.aspx).

5.       Mirroring indexes across multiple data centers, backup and recovery functionality

FAST Search Server 2010 for SharePoint does not offer mirroring and synchronization of indexes across multiple data centers. The FAST Search Server 2010 for SharePoint property index is stored on a file system and not in SQL Server as for SharePoint Server 2010. Index redundancy or index fault tolerance can be achieved by various ways of indexer backup deployments. In most large deployments, the index will be spread over several columns, and it is usual to have several rows with copies of the index for redundancy.

You can run a full data backup for a FAST Search Server 2010 for SharePoint farm, but this involves a long period with crawling suspended. The recommended approach for index high-availability in FAST Search Server 2010 for SharePoint is the fault-tolerant indexer setup.

In a fault-tolerant indexer setup of FAST Search Server 2010 for SharePoint, the data index is automatically copied to the backup indexers, which reside on the backup indexer row. If one indexer server fails with unrecoverable disk errors, you can either recover the server farm from the latest backup, or manually enable a backup indexer to act as the new primary indexer.

For more information about redundancy and availability, see Planning and architecture – FAST Search Server farm redundancy and availability (http://technet.microsoft.com/en-us/library/ff599525.aspx). For more information about backup and recovery strategy, see Operations – Plan the system backup and recovery strategy (http://technet.microsoft.com/en-us/library/ff460220.aspx).

6.       Minimum size footprint

FAST Search Server 2010 for SharePoint and SharePoint Server 2010 has different architectures. This difference has the following effects on size footprint:

  • Running FAST Search Server 2010 for SharePoint on the same servers as SharePoint Server 2010 is not supported. You can only migrate to separate FAST Search Server 2010 for SharePoint servers, and not within the existing SharePoint Server 2010 servers.
  • The FAST Search Server 2010 for SharePoint resource usage pattern differs from SharePoint Server, and therefore requires different kinds of server resources (more local disk, less SQL dependencies).
  • The FAST Search Server 2010 for SharePoint topology differs from SharePoint Server 2010. Therefore, the number of servers and the configuration of the servers will be different.

FAST Search Server 2010 for SharePoint has a different and larger disk footprint than SharePoint Server 2010 enterprise search. FAST Search Server 2010 for SharePoint uses less disk space in SQL Server, but more disk space locally. The total disk footprint is typically 2.5 times larger with FAST Search Server 2010 for SharePoint. FAST Search Server 2010 for SharePoint can support a larger document capacity per server than SharePoint Server 2010 given sufficient storage space.

7.       Query integration and query-side interfaces

SharePoint Server 2010 and FAST Search Server 2010 for SharePoint support different search syntaxes for building search queries. For example, queries in SharePoint Server 2010 that use SQL syntax must be revisited and changed to use keyword syntax in FAST Search Server 2010 for SharePoint. For more information about the different query syntaxes, see Building Search Queries (http://msdn.microsoft.com/en-us/library/ee556426.aspx).

The same query-side interfaces can be used both with FAST Search Server 2010 for SharePoint and SharePoint Server 2010 enterprise search. If you have a custom search application that is running on SharePoint Server 2010, you should be aware that some advanced query features that are available through the Federation Object Model or the Query Web service will behave differently after you upgrade to FAST Search Server 2010 for SharePoint. FAST Search Query Integration Overview describes the feature differences and what you must consider. In particular, note how to handle people search queries in FAST Search Server 2010 for SharePoint (http://msdn.microsoft.com/en-us/library/ff394628.aspx).

As an example, the following Query Web Service schema elements are not supported (that is, they are ignored) by FAST Search Server 2010 for SharePoint:

IgnoreAllNoiseQuery, IncludeHighConfidenceResults, HighlightQuerySuggestions and CapitalizeFirstLetters.

8.       Customized ranking

SharePoint Server 2010 and FAST Search Server 2010 for SharePoint have different integration interfaces for handling custom relevance tuning. There are more options available in FAST Search Server 2010 for SharePoint, but the RelevanceModel element is not supported. For more information about how to customize search relevancy, see Improving Relevance for FAST Search Server 2010 for SharePoint (http://msdn.microsoft.com/en-us/library/ff464315.aspx).

9.       Custom security trimming

SharePoint Server 2010 provides support for custom security trimming of search results through a SecurityTrimmer interface (ISecurityTrimmer2). FAST Search Server 2010 for SharePoint does not support this interface for result-side custom security trimming. All security trimming is performed as part of the query matching, based on ACL information that is stored in the index. Because FAST Search Server 2010 for SharePoint provides query refinement based on all items that match a query, this ensures that refinement counts only reflect the items that the user is entitled to see.

One way to customize security trimming is to write custom claims providers to add principals (groups/users) from other domains into the query rewrite. Another option is to write custom crawlers that provide custom ACL information to the index.

Note: I used the following references in my post:

 

Author

Published