Plan Shared Services Providers
Applies To: Office SharePoint Server 2007
This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.
Topic Last Modified: 2016-11-14
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 SSPs.
About SSPs
Services provided by an SSP
The following shared services are provided by each SSP:
**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 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.
Consuming services from an SSP
When a server farm is installed, you create the default SSP as one of the first post-setup tasks. Each SSP contains all of the available (installed) shared services.
You associate SSPs with specific SharePoint Web applications.
A SharePoint Web application can only be associated with one SSP.
All site collections and sites within a SharePoint Web application consume services from the same SSP.
Shared services cannot be enabled or disabled at the site collection or site level. All services that are available from the SSP are available to all sites within the Web application.
Farm-level SSP configuration
A server farm can host one or more SSPs. A server farm can also consume services provided by an SSP on a different server farm.
**Intra-farm shared services **The server farm uses the services of an SSP hosted on the server farm.
**Inter-farm shared services **The server farm uses the services of an SSP on a different server farm. A server farm that is consuming services from a different farm might not contain any SSPs. The one limitation to this configuration is that Excel Services is not available outside the farm that hosts this service. If Excel Services is required by a farm, the farm must host shared services locally.
In most single-farm environments, one SSP provides services for an entire organization. Multiple SSPs are only used in deployments that have a proven need for securely isolated content.
Geographic SSP configuration
Providing shared services over the WAN is not supported. For example, a regional farm in Africa cannot consume shared services from a central farm in Europe. The African farm must host its own SSP. However, users in Africa can connect to a central farm in Europe and consume shared services from the central farm.
While hosting shared services over the WAN is not supported, a central farm can be configured to crawl content across the WAN. For example, a central farm in Europe can crawl the content of a regional farm in Africa. This configuration provides a method of hosting enterprise-wide search. In this scenario, the central farm is not hosting shared services to the regional farm and the regional farm is not consuming shared services from the central farm.
Determining Shared Services Provider needs
The biggest design decision around providing shared services is how many SSPs to plan for.
Planning for a single SSP
In many cases, a single SSP can provide services for an entire organization.
A single SSP in a farm provides shared services to Web applications hosted on that farm.
All users in the SSP can share personal information, search for content, and access business data, according to each of their permissions.
Access to content can be limited by content targeting, privacy policies, and other features based on SharePoint groups and security.
A single SSP should be used if:
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.
Planning for multiple SSPs
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.
Sharing content across multiple SSPs
Even with the full content isolation of multiple SSPs, it is possible to override that isolation in rare cases if it is necessary.
Content on sites using one SSP can be crawled by another SSP by adding the start address to an external content source.
Trusted My Site host locations can be used to enable users to view personalized information about users in other SSPs.
These practices add additional administration costs while compromising the advantages of multiple SSPs. Typically, they are only done during ongoing operations, such as when a user changes locations in a geographically distributed deployment, or when content is relevant across an organization with groups that are otherwise isolated. Good planning for deployment and careful use of multiple SSPs can reduce the necessity of these practices.
Download this book
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable content for Office SharePoint Server 2007.
See Also
Concepts
Plan for personalized content and sites
Plan search (Office SharePoint Server)
Plan for business intelligence
Configure usage reporting