SharePoint 2007 further refines the concept of shared services which provide the heavy-lifting services behind SharePoint. Here’s the MicroSoft definition" A Shared Services Provider (SSP) provides a common set of services and service data to a logical grouping of Web applications and their associated sites. This article describes how SSPs work in Microsoft Office SharePoint Server 2007 and includes recommendations on planning for SSP.".
So where do SSPs fit in the overall scheme of things? SSP services are consumed by Applications and Site Collections. The following list shows the hierarchy:
- Site Collection – associated with an Application (Site collection template)
- Application – Associated with an SSP (Application Pool and SQl Database instance)
More specifically, SSPs provide the following services:
- Personalization services – provides user profiles based on data imported from directory services, My Sites with personal information that can be shared by all users in the SSP and managed by privacy policies, and content targeting by audience, Office client application, or personalization site links
- Business Data Catalog – provides a single unified schema for data stored in line-of-business applications
- Excel Services – provides shared worksheets and a way to analyze business data from data connection libraries by using reports in dashboard pages
- Office SharePoint Server Search – crawls (Index Service) all sites on Web applications using the SSP to create a single index of all content, data, and metadata.
- Portal usage reporting – enables SSP administrators to view aggregated information about site usage across the entire site hierarchy. SSP administrators can also enable usage reporting for administrators of individual sites and site collections.
Understanding what SSPs provide, the next questions would be:
- Can I have more than one SSP?
- If so how many?
- When would I use just one?
- When would I use several?
- What are the pros and cons?
Generally one SSP is fine for organizations deploying an internal Portal but for those considering access by external parties such as customers, suppliers and other parties a second SSP should be considered. Why? Think of SSPs as administrative islands like Domains in AD and therefore if you want a clear (no risk) spearation of data.
The folloing are guidelines for a single SSP:
- There is no explicit reason to use multiple SSPs
- Users will collaborate or share content and data across the organization
- Users will search organization-wide for people working in the organization
The folloing are guidelines for multiple 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