Creating Multiple Shared Services Providers | Microsoft SharePoint Products and Technologies Administrators Pocket Consultant

Much like Active Directory forests, you should only add a second Shared Services Provider (SSP) when absolutely necessary. Adding another SSP greatly increases the complexity of your overall design. For example, adding a second SSP infers the creation of another user profile database, Search services, My Sites host, and much more. However, there are a few reasons to create multiple SSPs:

Legal, regulatory, or government regulation
Geographic dispersal: you cannot use intra-farm Shared Services over a Wide Area Network (WAN) link with a delay greater than 80 ms.
Indexing limitations, such as geographic, size, or WAN latency
Extranet or Internet needs, such as an Extranet portal or Internet publishing site
SharePoint hosting solutions

Although many of the limitations of creating multiple SSPs can be overcome, doing so is usually not worth the administrative effort or financial expenditure. If you require additional SharePoint Server farms you should consider inter-farm shared services, covered later in this chapter. If you choose to create multiple SSPs, consider the following items:

User profiles and properties Creating a second SSP gives you a second set of user profiles. If the second SSP is in the same server farm, you can import the same user profiles again, if needed. Obviously, this increases the processor and disk usage of both the directory controller and SSP Web application.
My Sites By default, creating a second SSP creates another set of My Sites. You should plan for using a single My Site Web application even if using multiple SSPs. Creating multiple My Site providers is covered at the end of this chapter.
Indexing Creating another SSP also creates a second index. Although this index can exist on the same Index server as the first SSP, a single index cannot be shared between SSPs. For this reason, you must crawl all content twice if you wish it to exist in both SSPs. Creating a second content index can dramatically increase the complexity of your SharePoint Server implementation and should be avoided.
Search scopes All of the search scopes you created in your first SSP will not be visible in the second SSP. There is no way to synchronize or copy these search scopes. If the same scopes need to exist in the second SSP, they must be recreated.
Audiences Like search scopes, audiences cannot be shared between SSPs.
Excel Calculation Services Excel Calculation Services can only be shared intrafarm. When creating a second server farm, you must enable Excel Calculation Services locally on that farm if required.

Intra-Farm Shared Services

By default, all Shared Services within a SharePoint Server farm are considered to be intra-farm. Any Web application within that server farm can be associated with that SSP and therefore consume services. If multiple Shared Services Providers and the associated Web applications share a common configuration database (configDB), they are also referred to as Intra-farm Shared Services. Multiple Intra-farm Shared Services do not provide absolute process isolation, but can be useful when creating a second index server or isolating user profiles and audiences. Generally speaking, creating multiple Intra-farm Shared Services Providers does not add performance to a SharePoint Server farm. A few reasons for creating multiple Intra-farm SSPs are as follows:

Regulatory or legal requirements, such as HIPAA, Sarbanes-Oxley, or legal case isolation. For example, many Records Centers use a second Intra-farm SSP to search and index official files and official file status.
Specialized indexing requirements, as is the case with ISPs.
Intranet and Extranet separations. For example, you might have one SSP to service indexing, audiences, and profiles for your internal users while having a second SSP to serve only indexing to your external users. This is useful when you do not wish to expose your internal content via search to external users.

Inter-Farm Shared Services

Inter-farm Shared Services are necessary when a second farm is required. If possible, you should consume Shared Services from a centrally located SSP. This simplifies your implementation by having a single place for user profiles and properties, one set of audiences and search scopes, and a single content index. However, there is one service that cannot be shared: Excel Calculation Services. When consuming Shared Services from another SharePoint Server farm, you are prompted to choose the local Intra-farm Shared Services Provider to use for Excel Calculation Services. For this reason, there must be a default Shared Services Provider in every SharePoint Server farm, even when consuming Shared Services from another farm. A few reasons for implementing Interfarm Shared Services are as follows:

Absolute security and process isolation
Implementing Portable SharePoint Server farms: for example, a SharePoint Server farm might move geographically inside a large insurance company that services customers affected by natural disasters.
Geographic: Intra-farm Shared Services must be at LAN speeds.

Caution

Inter-farm Shared Services should not exceed 80-ms network delays. Longer delays might work, but are not recommended or supported.

Configuring Multiple My Site Providers

By default, you have a single My Site Web provider per SSP. Remember that a dedicated Web application is recommended; http://mysite.contoso.com, for example. A common reason for creating multiple My Site Web applications might be to enable regional access to a often used My Site Web application while retaining the best practice of a single Shared Services Provider. This is called Global My Site deployments in SharePoint Server 2007 and allows a single My Site per user, but the My Site Web application can be shared by multiple SSPs. If you have multiple My Site providers associated with a single SSP, you must use audiences to direct the users. A My Site provider is a Web application that is managed by an SSP. A single SSP can direct users, based on audiences, to multiple My Site Providers. Because a My Site provider must be managed by an SSP, you must have SharePoint Server 2007 installed on the destination farm to host a My Site provider. To enable multiple My Site Web applications (providers), do the following:

Create the My Site Web application in the desired SharePoint Server farm.
Apply the My Site Host site collection template, preferably in the root of a dedicated Web application to host My Sites.
On the server farm you wish to configure for multiple My Site trusted hosts, go to SSP Administration > My Site Settings.
Under the Multiple Deployments section, select Enable My Site to support global deployment.
From the same SSP Administration home page, browse to Trusted My Site Host Locations.
From the New drop-down menu, select New Item.
You must enter in an URL; the description is optional.
Most likely, you will want to enter a target audience. This can be an Active Directory Security or Distribution list, or a SSP Global Audience.

If a user is in more than one My Site Trusted Location audience, he or she is directed to the first one in the list. Select Change Order from the Actions drop-down menu to change the order. In addition, a user in multiple My Site audiences is directed to the next available My Site provider upon creation, should the first one in the list be unavailable.