The most important criteria that determine if you need more than one SSP are your requirements for isolation of content. For example, if your server farm hosts applications for more than one class of users, separate SSPs can help create the secure isolation between these classes of users. Plan to use a separate SSP for each of the following types of applications:
-
Intranet Intranet content includes team sites, My Sites, and published intranet content. This type of application is typically available only to users within your organization that have an account within your directory management system.
-
Partner Web A partner Web application typically hosts site collections and sites for collaboration between both internal employees and partner users. Using a separate SSP ensures that partner users cannot search on or access sensitive information within your Intranet environment.
-
Customer Web site A customer Web site that is available for anonymous users requires a dedicated SSP. The configuration of services within the SSP will be very different than those that are configured for other types of applications that you use for collaboration within your organization.
-
Records Center There are typically legal issues involved concerning the privacy of information in records centers. Because of this, use a separate SSP to crawl this content so that these records do not appear in search queries that originate from other SSPs.
Because each additional SSP that you add decreases the overall performance of the server farm, carefully consider your needs for implementing more than one SSP.
The following deployment scenarios might require the use of two or more SSPs:
-
Deployments with legal requirements for content isolation, such as financial services organizations, or deployments with one or more confidential projects that require full content isolation. To achieve full content isolation, you must also crawl and index the content in a separate index. Note that each SSP supports one index.
-
Geographically distributed deployments with each location having a discrete set of users and content that is more easily managed separately in each region.
-
Hosted deployments with customers that do not share any content or data.
The advantages of using separate indexes include:
-
Isolating content indexes to increase security. For example, you might want to isolate highly sensitive content, such as content stored in a records center.
-
Scaling out when the capacity of one index server is insufficient.
-
Efficiently crawling geographically dispersed content. Note that we do not recommend attempting to crawl content over a slow link, because the content being crawled must be sent over that link. To crawl content over a geographically dispersed area, consider installing a separate server farm with its own SSP in each geographical area.
It is important to note that Office SharePoint Server 2007 does not provide a way to combine indexes. Instead, queries are automatically routed to the SSP associated with the Web application from which the end-user initiated the query.
Even though all content that is crawled using a particular SSP is indexed in a single index, a query does not necessarily return search results for all items in the index that match that particular query. Instead, other search features filter or modify content after it has been crawled. For more information about these features, see Plan the end-user search experience (Office SharePoint Server).
Whenever possible, use only one SSP to crawl all content for your organization. Typically, if content on a Web application that uses a separate SSP is relevant enough to be included in a content source for your SSP, the Web application should use the same SSP as the Web applications that are crawled using your SSP.
In some cases, you might want to include a subset of content in your organization from a Web application that uses a different SSP. We recommend that you carefully plan how related information is stored across site collections. You should also plan which SSPs are associated with the Web applications that contain those site collections. If you must crawl content on a Web application that uses a different SSP, ensure that the user account used to crawl the content (either the default content access account or a different content access account defined by a crawl rule) has read permission to the content. For more information about crawling content, see Plan to crawl content (Office SharePoint Server).
Before you create multiple SSPs, consider using other means to isolate content:
-
Use SharePoint groups to limit permissions and authorization to the correct users and groups.
-
Use exclusive search scopes to prevent people from searching for certain content.
-
Use audiences to target content to specific groups of users.
-
Limit access to sites to specific users or groups. Some content on these sites will appear in search results.
Use multiple SSPs if all of the following criteria are met by your deployment:
-
Groups of users work on isolated projects, do not share personal information, do not have a business need to view sites for other projects, and do not collaborate across teams or projects.
-
The users have no business need to search for content, data, or metadata in other groups, and might have a compelling business reason to not view content or data.