Plan SSP architecture

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: 2017-01-24

This article describes Shared Services Providers (SSPs) and provides examples of how to build SSPs into the architecture of your overall solution design for Shared Services Providers (SSPs) in Microsoft Office SharePoint Server 2007.

In this article:

• About SSPs

• Building SSPs into your solution design

• Single farm SSP examples

• Planning SSPs for an inter-farm environment

• Inter-farm SSP examples

• Capacity planning related to SSPs

• Planning administration roles for SSPs

About SSPs

Office SharePoint Server 2007 includes a set of services that can be shared across Office SharePoint Server Web applications. The set of services are contained within and provided by an SSP. Using shared services greatly reduces the resources required to provide these services across multiple sites. By default, a single SSP shares these services across all sites within a server farm.

The following table lists the services that are provided by an SSP.

Building SSPs into your solution design

When a farm is first installed, you create the default SSP as one of the first post-setup tasks. SSPs work in the following ways:

• Each SSP contains all of the available (installed) shared services.

• You associate SSPs with specific Office SharePoint Server Web applications.

• A Web application can only be associated with one SSP.

• All site collections and sites within a Web application consume services from the same SSP.

Creating additional SSPs

You can create additional SSPs, if needed, based on your solution requirements. Separate SSPs provide process isolation of profiles, content, and search results. Process isolation is accomplished in the following ways:

• Each SSP resides in a separate IIS application pool.

• Each SSP uses a unique set of service accounts to run the services provided by the SSP, such as search, content crawling, and profile importing.

The most important criteria that determine the number of SSPs in your logical architecture are:

• The need to share content and profile data across sites that reside in separate Web applications and IIS application pools. For example, you can share My Sites, team sites, and published content across an intranet by bringing these sites together under one SSP.

• The need to isolate content and audiences to specific sites. For example, if your server farm hosts applications for more than one class of users, separate SSPs can help create isolation between these classes.

When you create a new Web application, by default the new Web application is associated with the default SSP. If you want to associate the Web application with a different SSP, you must change the association manually.

The following diagram illustrates the logical architecture of a server farm with two SSPs.

Although not pictured, multiple Web applications within a single application pool can consume services from different SSPs. For example, in the previous diagram there is no technical limitation that prevents the two Web applications in Application Pool A from consuming shared services from different SSPs. However, Web applications that are grouped in the same application pool typically share similar isolation and security requirements, which makes it more likely that they will consume services from the same SSP.

SSP architecture

Each SSP uses the following three types of shared services resources:

• Databases (SSP database, search database)

• Shared Services Administration site (including the site’s content database)

• Web service hosting site (IIS Web site that hosts shared Web services for the SSP)

The SSP database includes the following types of data:

• SSP configuration data and site usage data

• People profiles and audience data

• Business data catalog metadata

Each SSP also includes a search database that includes all configuration and data associated with search.

The following diagram illustrates the logical architecture of a farm with emphasis on the farm resources used by SSPs.

Single farm SSP examples

This section provides several example architectures for building SSPs into a single farm and includes some additional planning recommendations.

Example 1—Single farm, single SSP

A single SSP works well for an organization that hosts a large number of sites on one farm.

Description

A single SSP is used across the entire farm:

• All sites use the same set of shared services.

• All sites can be created within a single Web application or across multiple Web applications (shown).

• Web applications can be associated with the same application pool (shown) or with different application pools.

Recommendations

This is the recommended configuration for most companies. Use this configuration if:

• You want to optimize the resources required to run shared services within a farm.

• Your farm does not require isolation of Web applications.

Example 2—Single farm, multiple SSPs

In some organizations, there are isolation requirements that can be satisfied by implementing an additional SSP.

Description

Multiple SSPs are used to enhance both sharing and isolation goals:

• A single SSP provides services for sites that are spread across multiple Web applications. This strategy allows sharing of content and services while maintaining process isolation between sites in different Web applications.

• Using a dedicated SSP for targeted sites provides isolation of processes, content, and services.

Recommendations

This configuration is recommended for the following scenarios:

• Sharing content and profile data across sites that otherwise require process isolation, for performance or security reasons.

• Accommodating a group or department within a company that requires secure and isolated data.

• Hosting sites for external access by partners on the same farm as your internal collaboration sites

Example 3—Hosting with a single farm

You can host multiple customers or departments on the same farm and ensure isolation of data by dedicating an SSP to each customer. A dedicated SSP also allows you to delegate ownership and configuration of services to the specific organizations. For example, you can configure a dedicated SSP for a department that requires ownership of its search configuration or profile data.

Description

Multiple SSPs are used to isolate services within a single farm.

• Each company or department receives a dedicated SSP.

• Using separate application pools to host separate departments or companies provides process isolation at the application pool level (in addition to shared services isolation).

• An application pool can include one or more Web applications.

• Administration of shared services can be delegated to the organizations that an SSP provides services for.

Recommendations

This configuration is recommended for the following scenarios:

• Hosting sites for multiple companies or multiple independent departments within a single organization.

• Providing flexibility for each company or department to further isolate content or optimize performance by using multiple Web applications or application pools.

• Delegating administration of services.

• Accommodating a huge amount of data. There are some capacity guidelines that apply to how much data the search service of a single SSP can accommodate. For example, the recommended limit for number of documents indexed by a single SSP is 50,000,000. For more information about capacity guidelines, see Capacity planning related to SSPs later in this article.

Example 4—Hosting with multiple farms

Some organizations require physical isolation of data in addition to process isolation. For these organizations, a separate farm might be the solution.

Additionally, some organizations might include further requirements that indicate that more than one SSP is necessary on the farm, similar to Example 2 (previously pictured).

Description

Multiple farms are used to provide physical isolation between departments or companies:

• Each department or company receives a dedicated farm and SSP.

• All hardware is dedicated based on department or customer.

• Each farm is completely isolated, resulting in no possibility of cross-portal data access.

Recommendations

This configuration is recommended for the following scenarios:

• Isolating departments within a single organization, where physical isolation of hardware, data, or applications is a requirement.

• Hosting SharePoint sites for multiple companies, where physical isolation is necessary for:

  • Tracking resource utilization

  • Securing applications and data

  • Optimizing performance

  • Satisfying licensing requirements

Additional planning recommendations for SSPs

You can configure SSPs either to enhance information-sharing across multiple Web applications or to further isolate content within a single Web application. For example, sites that reside in different Web applications and application pools can be unified under one SSP to share content and profiles across an intranet. This provides for personalization and enterprise-wide search across many sites and applications. This configuration is an example of balancing process isolation (by implementing separate Web applications and application pools) with the business need to share information and leverage profile data across the applications.

You can also configure SSPs to enhance your overall isolation goals. For example, using a dedicated SSP for partner sites ensures that partner users cannot search on or access other sites within your environment. You can configure the SSP to further isolate content between site collections in the following ways:

• Limit search scopes to the individual site collections.

• Use audiences to target content to certain groups of users.

• Use the Stsadm command-line tool to configure the People Picker to display only users who are members of the site collection.

When you design your SSP strategy, consider the ways in which you can configure the individual services within an SSP to enhance your overall content-sharing or isolation goals. For examples of these strategies, see the following design sample: Logical architecture model: Corporate deployment.

Planning SSPs for an inter-farm environment

A single SSP can be configured to provide services to multiple Office SharePoint Server 2007 farms. Using an SSP across farms provides centralized administration of services and also reduces the number of services providing the same role. This can also dramatically reduce the amount of hardware and other resources that are required to provide services.

The guidance in the rest of this article describes and refers to the following diagram. This diagram illustrates a parent farm sharing services with three child farms that are each configured for different purposes. Each of the child farms are described later in this article.

Parent and child farms

Inter-farm shared services are offered by a parent farm to one or more child farms:

• A parent farm is configured to provide shared services to other child farms.

• Child farms are configured to consume shared services from the parent farm.

• A farm cannot be both a parent farm and a child farm.

• Only one SSP per farm can participate in inter-farm shared services:

  • Parent farms can only share one SSP to child farms. However, a parent farm can include more than one SSP for its own use (see the Parent Farm in the previous diagram).

  • Child farms can only consume services from one parent SSP. However, a child farm can provide more than one SSP for its own use (see Child Farm 2 in the previous diagram).

Switching between inter-farm SSPs and stand-alone SSPs

Shared services consumption for child farms can be reconfigured at any time:

• A child farm can disassociate from a parent farm and be configured to either consume shared services from a different parent farm or use its own local SSP.

• Child farms can consume shared services from a parent farm when connected to the central network and then switch to consume services from their own local SSP when they are disconnected. Child Farm 3 (in the previous diagram) illustrates a farm with a standby local SSP that is used when the farm is disconnected.

• Parent farms can be reconfigured as stand-alone farms at any time. Parent farm administrators should alert the child farm administrators of affected child farms before reconfiguring the SSP as a stand-alone SSP.

Inter-farm SSP limitations

The following limitations apply to inter-farm shared services:

• If the parent and child farms reside in different domains or forests, there must be a trust relationship configured between the domains or the forests. Additionally, if the two farms reside in different forests, Active Directory replication between the separate and trusted forest must be working correctly.

• Inter-farm SSPs are not supported across a WAN. A child farm cannot be associated with an SSP of a parent farm if the two farms are separated by WAN links.

• Parent farms must have all Office server products installed that are used by child farms. For example, if a child farm includes Office Project Server, then Office Project Server must be installed on the parent farm for shared services to work correctly. If a child farm uses the Enterprise Edition of the Client Access License (CAL), then the parent farm must also use the Enterprise Edition CAL (as opposed to the Standard Edition). The one exception to this design requirement is the Excel Services service.

• The Excel Services service cannot be provided by an SSP of a parent farm and must be provided by an SSP that is local to the child farm. A Web application can be configured to consume all other services from a parent farm while consuming the Excel Services service from a local SSP. This is the only circumstance in which a Web application can consume services from two different SSPs. For an illustration of this scenario see Combined inter-farm and local SSPs (Child Farm 2) later in this article.

Scripting inter-farm SSP configuration

You can create a script to duplicate the manual processes required to associate a child farm to a parent farm. Scripting the setup process:

• Reduces the amount of time required to deploy shared services across multiple farms.

• Ensures that configuration settings (directory, configuration, search index, etc.) are applied consistently across farms.

For more information, see Shared Services Provider: Stsadm operations (Office SharePoint Server).

Inter-farm SSP examples

This section describes the three child farms illustrated in the previous diagram.

Inter-farm shared services only (Child Farm 1)

Description

Child Farm 1 consumes only shared services that are hosted by a parent farm. This scenario allows you to optimize the hardware, network, and administrative resources required to provide shared services across farms. You can either designate an existing farm to serve as the parent farm or you can create a farm dedicated to hosting shared services only.

Recommendations

This configuration is recommended for the following scenarios:

• Providing shared services to multiple farms within a company.

• Hosting Office SharePoint Server solutions for companies that require farm isolation but that do not require isolation of services.

Combined inter-farm and local SSPs (Child Farm 2)

Description

Child Farm 2 consumes services from two different SSPs:

• Consumes inter-farm shared services from the parent farm.

• Hosts its own SSP and consumes services from this SSP.

Farms configured in this way can leverage corporate-wide shared services but can also function independently, if needed. A child farm can switch from consuming inter-farm shared services to consuming its own shared services.

The combined inter-farm and local SSP configuration is also required if a child farm is using Excel Services. If Excel Services is required by a farm, the farm must host shared services locally. In this configuration, Web applications in the child farm consume Excel Services from a local SSP and all other services from a parent SSP, as illustrated in the following diagram.

Recommendations

This configuration is recommended for the following scenarios:

• A department within a company requires farm isolation to protect sensitive data or to dedicate physical resources, and also needs to be included in company-wide portals and sites.

• A company or division is acquired and you want to provide access to company-wide resources without otherwise disrupting the farm. This scenario allows the child farm to take advantage of shared services that are available corporate-wide, such as search and crawling.

• A division or group within a company is sold or reassigned to another Office SharePoint Server environment, and you want to configure the farm to operate independently as a step toward transitioning the farm to the new environment.

• Excel Services is required by a child farm.

Standby SSP (Child Farm 3)

Description

Child Farm 3 is configured to switch between consuming inter-farm shared services and its own shared services. The SSP within the child farm serves as a standby provider. The child farm switches to the standby SSP when disconnected from the parent farm.

Recommendations

This configuration is recommended for farm deployments that are temporarily dispatched to different geographic locations.

Capacity planning related to SSPs

When planning your SSP architecture, consider the software boundaries that are recommended for logical architecture elements and the effect they might have on your SSP configuration.

The following table lists the recommended guidelines for logical architecture components.

In addition to the logical architecture components, the search service also includes recommended software boundaries that can affect the number and configuration of SSPs in your environment. The following table lists the specific search objects with recommended boundaries that affect SSP planning.

For more information about software boundaries, see Plan for software boundaries (Office SharePoint Server).

Planning administration roles for SSPs

The shared services model in Office SharePoint Server 2007 provides the ability to centralize administration of services as a whole while delegating administration of specific services, as desired. The following table lists the primary SSP roles.

One person can perform all of these roles. However, in many medium and large organizations administration of specific services is often delegated. The following table lists the specific service administration roles that can be delegated.

For more information about these roles and how to configure them, see Plan for security roles (Office SharePoint Server).

Inter-farm SSP administration

In environments where inter-farm shared services are implemented, the responsibilities of the farm administrator differ, depending on whether the farm is a parent farm or a child farm. The following chart summarizes the administrative tasks that are performed by each administrator in an inter-farm SSP environment.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

• Planning and architecture for Office SharePoint Server 2007, part 2

See the full list of available books at Downloadable content for Office SharePoint Server 2007.

See Also

Concepts

Plan Shared Services Providers
Logical architecture components
Logical architecture model: Corporate deployment
Create and configure Shared Services Providers