Rules for Deploying Shared Service Provider

Before deploying an SSP, you will need a thorough understanding about the rules for deploying them. This topic discusses the rules for deploying SSPs.

The rules are as follows:

1. You can associate each Web application with one SSP only. To associated specific web application to a particular SSP, Change Associations is used. All WSS site collections and sites under the associated Web application inherit the use of the SSP. It is required that you associate all Web applications to SSPs. When you create the first SSP in your farm, the SSP 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. The details can be specified in the SSP properties page as shown below.
   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.