For most enterprise environments, a single SSP is sufficient. However, an enterprise occasionally will benefit from having a second SSP. An SSP provides a resource of services-such as Profiles, Search, Audiences, and the Business Data Catalog-for sites to consume. If you create a new SSP, all these configured services are lost to any Web applications and sites associated with the new SSP. That can, however, be just what is required to satisfy a business need. This section covers the following topics related to SSP in an enterprise environment:
Creating a new SSP
Changing Web application associations
Granting shared services between farms
Before you can create a new SSP, you must first create a new Web application that is not being used by other SSPs or sites. Also, it is recommended that for each Web application that is hosting an SSP, you also create a new application pool.
|More Info|| |
For more information on creating Web applications and application pools, refer to Chapter 7.
This ensures that the SSP has its own worker process and memory space to run in. To create a new SSP, follow these steps:
Go to Central Administration.
Click the Application Management page.
Click the Create Or Configure This Farm's Shared Services link in the Office SharePoint Server Shared Services section.
On the Manage This Farm's Shared Services page, click New SSP on the options bar.
On the New Shared Services Provider page, complete the fields as described in Table 18-1.
Click OK to complete the process for creating the SSP.
To confirm that the new SSP has been successfully completed, return to the Manage This Farm's Shared Services page. You should see the new SSP listed under the default SSP. Notice also that no Web applications are associated with the new SSP. (See Figure 18-11.)
Figure 18-11: Viewing the new SSP
Because of limitations in system resources, it is recommended that you not create more than 20 SSPs.
You cannot delete the default SSP until all Web applications have been re-associated and it no longer has any Web applications associated with it. Once you have re-associated the Web applications to another SSP, click the Change Default SSP button to choose the new SSP. Then select the drop-down arrow next to the old SSP and choose Delete.
When you create a new SSP, any services that you configure on that SSP-such as search, audiences, and BDC-will be available only to Web applications that have been associated with that SSP. Therefore, all sites that are created in the Web application are only able to consume the available services configured from that SSP. When a new Web application is created, it is automatically placed in the default SSP. You can then re-associate it with any SSP.
A Web application can be associated with only one SSP. A single SSP has no limit to how many Web applications it can host.
A Web application can be re-associated at any time in Central Administration and, if required, multiple Web applications can be moved at one time. Once re-associated, the Web application will be displayed under the new Shared Services Provider hosting it, as shown in Figure 18-12.
Figure 18-12: Web applications associated with separate SSPs
Prior to re-associating Web applications, you need to plan your environment. Most of the topics covered in this chapter need to be addressed on both the old and new SSP hosting Web applications. These topics include profiles, Audiences, Search, and My Site Locations. Once a Web application has been re-associated, all sites in the Web application lose or gain new services, and these services need to be correctly configured prior to moving the Web application. An example of this is a My Sites in which a user creates a second My Site because the My Site Location has not been configured correctly in the SSP Management page to point to his correct Web application hosting the My Sites.
Changing associations is, however, very straightforward. To change SSP associations, follow these steps:
In the Manage This Farm's Shared Services page, click Change Associations on the options bar.
On the Change Association Between Web Applications And SSPs page, select the Shared Services Provider name from the drop-down list that you want to associate Web applications with.
In the Web Applications section, select the Web application you want to re-associate. Alternatively, choose Select All to re-associate all Web applications with this SSP.
On the Warning page, click OK.
As mentioned earlier in this chapter, in an enterprise environment, you can have an SSP in one farm that provides services to an SSP in another farm, thus creating a parent/child relationship. This is known as Inter Farm Shared Services (IFSS). It works by selecting only one SSP from the farm, which then provides shared services to other farms. The farm that is providing the shared services is known as the parent, and all farms that consume from that parent are known as children. After you have prepared an SSP for providing services-such as the BDC, Profiles, and Search services-the child farms can consume those services for their own use. In Central Administration, you can identify a parent SSP because the word "Parent" is next to its name, as shown in Figure 18-13.
Figure 18-13: An SSP identified as the parent
To configure a farm to provide IFSS, follow these steps:
On the Manage Shared Services Between Farms page, select This Farm Will Provide Shared Services To Other Farms.
In the Provide Shared Services section, choose the SSP that will provide the services for child farms and add the users from the child farms who will be allowed to connect to this SSP. Click OK.
On the Success page, make a note of the parent farm database server and database name, as these will be needed when configuring the child farm. Click OK to complete the process.
Before a child farm can consume services from a parent, it must already have an SSP configured.
After a parent SSP has been configured and made available, other farms can start to consume the available services. The configuration of a child farm is also done in Central Administration. After a child farm is configured to consume services, an SSP is displayed and tagged as Remote in Central Administration. This Remote tag indicates that it is consuming services from another farm. You can now start associating Web applications with this SSP to consume its services. To configure a child farm, follow these steps:
From Central Administration, click the Application Management page.
Click Grant Or Configure Shared Services Between Farms in the Office SharePoint Server Shared Services section.
On the Manage Shared Services Between Farms page, select This Farm Will Consume Shared Services From Another Farm.
In the Consume Shared Services section, enter the database server, database name, and the user account that were specified earlier when creating the parent SSP.
If Excel Services are required, select the local SSP in the child farm that will be hosting Excel Services. Click OK.
There is no requirement for all SSPs to consume from the parent, and you can choose to have some farms not consume services at all from the parent. The parent/child relationship is also compatible with a SharePoint Portal Server 2003 Shared Services model. A child farm in SharePoint Portal Server 2003 can consume from the parent SSP in SharePoint Server 2007.
As part of a migration strategy for a SharePoint Portal Server 2003 Shared Services model, you should upgrade your parent farm first and then the child farms.