MOSS Indexing and SSPs

During recent search discussions and POCs, a number of questions have surfaced as well as some key points re: SSPs which I have tried to capture here.

Q: How many index servers can be a part of a MOSS farm?

A: The number of Shared Service Providers (SSPs) is the key. Conceptually, you can have more than one index server, but you can only assign one index server per Shared Service Provider. So you would have to have multiple SSPs to support multiple index servers. There is some confusion here since in SPS2003 the index was associated with a portal but in MOSS it is created and managed by the SSP.

· Multiple SSPs does not necessarily mean multiple index servers. The indexing role for each SSP can be on the same physical server or separate servers. Things such as crawling schedules and the number of user queries will be key information that will impact the decision.

· Unlike the indexing role, the query role is not assigned to the SSP.

· There is a 50 million document/item limit per index and query server. Up to now, I have not run into capacity issues that would dictate having multiple SSPs. When multiple SSPs have been needed it has been due to business requirements, e.g., indexing requirements for confidential data, or controlling what internet/extranet users can search.

· There is no OOTB solution for federating search requests across indexes and aggregating the results.

Some points worth reviewing for deploying SSPs:

1. You can associate each Web application with only one SSP. The first SSP created is marked as the default SSP for the farm. All Web applications that do not have an explicit SSP assigned use the default SSP.

2. The application pool identity accounts of Web applications that will need to use a shared service from an SSP must be granted access to the SSP.  When you create a Web application, the application pool identity of the Web application is automatically associated with the default SSP.

3. All shared services exist as a tightly bound cluster of services. This means that if you create a SSP, it will contain all services. These services include user profiles, Excel services, BDC, search, and usage reporting. All shared services are turned on at the SSP level. For example, you cannot turn off the Search service and expect all other shared services to work correctly.

4. Every SSP you create must have an associated administration site. The administration site is used for managing application level settings and configurations for the SSP.

Check out this article as part of your planning.

Plan to deploy index and query servers (Office SharePoint Server for Search)

</steve>