Best Practices for Implementing Search Server 2008

So far in this chapter, we have discussed the how of implementing Search Server 2008. In this section, we’ll outline what we believe are some best practices for a Search Server 2008 implementation. Because this product is new to the market, there is a lack of rich implementation experience, but that doesn’t mean that we can’t suggest several best practices for you to consider.

First, while it is possible to use Search Server 2008 to implement a new SharePoint Server 2007 farm, this is not a best practice because of the limitations inherent in the product. For example, you can’t implement more than one SSP in a Search Server 2008 implementation. In addition, most of the site templates that you would expect to exist in a SharePoint Server 2007 implementation will be missing, as will some expected features. It is a best practice to stand up your Windows SharePoint Services or SharePoint Server 2007 farm and then upgrade the search services by installing Search Server 2008 into that farm.

Second, you need to decide what content you’ll crawl and index and what content to which you can send a federated query to receive a result set. There are several considerations. First, you can’t send a federated query to a non-existent index. If the remote content isn’t being indexed by another OpenSearch 1.1–compliant indexing engine, then you’ll have to crawl and index that content if you want it to appear in your result set.

Creating a large number of federated Web parts in the result set will diminish the quality of the end-user experience because of the way the result set page renders. This page renders when the Web parts are ready to render in a serial, non-dependent fashion. So, if you have five federated Web parts for a given query, each gathering results from five different remote indexes, then each Web part will render independently and in no particular order. The rendering of these Web parts can cause other parts of the page to repaint, and sometimes content shifts up or down on the page when it repaints. This can be irritating to users if a large number of federated Web parts are rendering at different times. We recommend having fewer than 10 federated Web parts involved in returning results for any given query. While it is possible to federate most of your queries, best practice is to federate only those queries that are executed the most often to the largest remote indexes. So, even though you could build a federated Web part and FLD to a remote index, it might not be the best course of action if you already have a large number of queries federating to other remote indexes.

Those in geographically dispersed deployments with multiple SharePoint Server 2007 farms might consider standing up a Search Server 2008 farm for the sole purpose of providing federated queries across all of your farms’ indexes. SharePoint Server 2007 is OpenSearch complaint, so a Search Server 2008 implementation could provide federated queries to all of your SharePoint Server 2007 users in their respective locations. In most geographically dispersed deployments where multiple SharePoint Server 2007 farms are deployed, most of what a user needs can be found in their local SharePoint Server 2007 farm. However, there are times when a user may need to query an external farm for a content item. Search Server 2008 can provide this type of infrequent query service at very little cost.

From a staffing perspective, if you plan to implement a robust search and indexing solution for your users, you’ll likely need to add additional staff to your IT department because creating, testing, and managing content sources and search scopes can be rather time consuming. Also, the opportunity to use SharePoint Server 2007 audiences with Search Web parts and the flexible customization of how results are displayed demand additional full-time staff in large search and indexing implementations. For those large implementations, it is a best practice to dedicate full-time staff to this effort.

It is also best practice to ensure that you index only the content you need in your index when you crawl public Web sites. Often, Web sites include extraneous information that is helpful to the site itself, but shouldn’t appear in your index, such as a privacy policy or the Contact Us page(s). You should use the crawl rules to ensure that only those pages of content that you really need in your index appear in your index. To do this, use a combination of include and exclude rules. For example, assume a very simple Web site design with a home page and two virtual directories, or subdirectories, as follows:

Assume that you want to crawl content only on the VD1page, and you do not want content on the VD2 page or the home page. In this case, your crawl rules would look like the following:

https://testweb/vd1/*               Include 
https://testweb/*                   Exclude

Order is important here, and you need to ensure that you’re using the crawler rules to carve out portions of Web sites that you need to appear in your index.

As you implement Search Server 2008, you can also use the following list of questions as a checklist to ensure that you’ve covered many of the decision points that you’ll encounter as part of a robust Search Server 2008 implementation:

• What will be the full and incremental crawl schedules for each content source?
• Do you have adequate server hardware to crawl all of the content sources in your current schedule?
• Do you have adequate bandwidth available between your index server and your content sources?
• For each content source, what crawl rules, crawler settings, and crawler impact rules are needed?
• Who will troubleshoot failed crawls or information that does not appear in the index?
• Who will evaluate the content sources so that crawl criteria are configured efficiently?
• What words should you add to the noise word file?
• What will be your search scope topology?
• Do you need additional iFilters?
• Do you need additional Protocol Handlers?
• Do you need to add File Types to SharePoint?
• Do you need to add icons to SharePoint?
• Do you need to turn on the OCR feature and adjust the size above 1 MB?
• Do you need special accounts to crawl certain content sources?
• Do you need to create any Best Bets?
• Do you need to group any Crawled Properties into Managed Properties and then expose the properties in the Advanced Search Web Part?
• Do you need any special Server Name Mappings?
• Will you use a dedicated WFE server for crawling farm resources or all of your WFE servers?
• Establish primary, secondary, tertiary, and demoted sites for relevance/ranking in the result set.
• Ensure that disks are optimized for Search and SSP databases.

< Back      Next >

 

 

© Microsoft. All Rights Reserved.