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)





Comments (3)
  1. bartg says:

    The 50 million documents per index/query server is a test-limited boundary 🙂

    It will / should work with over 50 million documents in the index, however it is unsupported since MS didn’t test it in their lab.

    Another sidenote:

    If you want to use multiple index servers in your farm (thus having multiple SSP’s), you’ll need to create your own search controls since the default ones are only talking to the index server belonging to the connected SSP.

    This will also kill the relevancy algorithms. Relevancy will only be calculated on each index server for the content sources belonging to this index servers.

    Hope this helps, need to make a good blogpost on this at my own blog as well 😉

  2. Akhilesh Tiwari says:

    Hi Steve,

    I do not see any UI option to enable Indexing for a "Multiple line text column" in Custom List.

    I even tried doing it through code:


    SPFiedlMultiLineText spText;    //Got the object

    spText.Indexed = true;        //Enabled indexing

    spText.Update();             //Commite the changes


    However shen I commite I get an exception saying "Operation can not be performed. Please try again."

    Could you please let me know whether indexing is possible in the above scenario?


Comments are closed.

Skip to main content