How upgrade affects search system architecture (SharePoint Server 2010)

 

Applies to: SharePoint Server 2010

The information in the following table describes how features and functions of the search system architecture are affected when you upgrade from Microsoft Office SharePoint Server 2007 to Microsoft SharePoint Server 2010.

Feature or function	Feature or function in Office SharePoint Server 2007	Corresponding feature or function in SharePoint Server 2010
Search service	A Shared Services Provider (SSP) hosts one or more centrally managed, reusable services. These services can be consumed by multiple Web applications in a farm. One of the services is the Office SharePoint Server Search service (OSearch). The OSearch service is used to crawl content repositories, index the crawled content, and serve search queries that are issued by end-users. However, an administrator might want to define more than one group of search settings for a farm-wide search configuration. For example, for security reasons the administrator might want to dedicate one content index to one set of content sources, and another content index to another set of content sources. To define an additional group of settings for a farm-wide search system, the search administrator must configure the OSearch service in a different SSP. If there is no other SSP in the farm that can be used for this purpose, the farm administrator must create a new SSP. However, each SSP requires maintenance and can consume system resources in addition to those that are used for the OSearch service.	For each SSP that existed in the farm before upgrade, the upgrade process automatically creates a Search service application. At upgrade time, the administrative settings from the OSearch service in an SSP are copied to the corresponding new Search service application. For example, the new Search service application contains the content sources, scopes, and crawl rules from the OSearch service in the corresponding SSP.
Search service configuration dependencies	In an SSP, the search administrator configures the OSearch service to define one group of settings (such as content sources and scopes) for a farm-wide search system. Each SSP can contain only one OSearch service. Therefore, an SSP can contribute only one group of settings to the farm-wide search system.	Each Search service application contributes one group of settings (such as content sources and scopes) for a farm-wide search system. A Search service application requires no host such as an SSP. To add a new group of settings to a farm-wide search system, the search administrator merely creates and configures an additional Search service application.
Databases	For each SSP, there are two databases: The SSP database. This database contains: Administrative settings for search, such as content sources and scopes. The profile store (Office SharePoint Server 2007 only). The search database. This database contains: Crawler internal data, such as crawl logs. The property store, which includes the metadata from crawled documents.	For each SSP that existed before upgrade, the following three databases are created and associated with the corresponding Search service application: The search administration database. This database contains the administrative settings for search that were stored in the SSP database. The crawl database. This database contains the crawler internal data that was stored in the SSP database. The property database. This database is largely the same as the search database that existed before upgrade. (Some information that was in the search database before upgrade is moved into the search administration database and crawl database.) There is only one search administration database per Search service application. After an upgrade, however, the crawl database and property database can be scaled out.
Crawling	An index server has a single crawler.	A crawl server contains one or more crawl components that can crawl content independently of one another.
Serving queries	A query server has only one component to serve search queries.	A query server can host one or more query components, each of which serves search queries.
Content index	Each SSP can contain only one OSearch service, and there is one corresponding content index.	For each SSP that existed before upgrade, one index partition is created with one query component. An in-place upgrade copies the entire content index from the SSP to the new index partition. After upgrade, the administrator can scale out to multiple index partitions. Each index partition contains a discrete part of the index. For example, in a topology with two index partitions, each partition contains half of the index. In a database-attach upgrade, the old content index is not retained. To create an index, it is necessary to perform a full crawl after the upgrade.
Propagation of content index	The search system stores the content index in the file system of the index server. The search system also propagates a copy of the content index to the file system of each query server.	Each crawl component propagates the content index to the index partitions on the query servers. The search system stores the content index in the file systems of the query servers. The crawl server does not keep a copy of the content index.
Naming of SSP and Search service application	Each SSP in a server farm has a unique name — for example, SharedServices1.	Each Search service application that is created during the upgrade process has a default name that is based on the name of the corresponding SSP from Microsoft Office SharePoint Server 2007. For example, if the SSP was named SharedServices1, by default the corresponding Search service application is named SharedServices1_Search. However, the administrator can customize these database names with an XML file that is used at upgrade time.

See Also

Concepts

How upgrade affects Search Center sites (SharePoint Server 2010)

Other Resources

Downloadable book: Upgrading to SharePoint Server 2010
Resource Center: Upgrade and Migration for SharePoint Server 2010