Interfarm Shared Services

Overview

If Intra-farm shared services are web apps consuming from SSPs within the same farm, then Inter-farm are web app(s) consuming from SSPs outside the farm. (MSDN:Shared Services Overview) (TechNet:Plan Shared Services Providers). Because of the WAN limitation, (can't consume SSP across the WAN) many people discount a solution with more than 1 farm. Before you dismiss this whole post, consider this... It really isn't that strange to create 2 farms in the same region... Why you may ask... You may decide that you want to do collaboration with Out of the box functionality maybe some custom master pages and layouts, but pretty much no custom assemblies or custom site defs or web parts. On the other farm, you create your Intranet Portal with custom web apps for your business and it becomes much more application centric. Sean Livingston has put together a service offering white paper focused on hosting customizations that we should be sharing as soon as we can get it published.

Let's say you have a few web apps, quite a bit of content. (Don't waste your time with this if you have one web app.)

Why have the SSP in a separate farm? (Sam from MSW is a fan.)

1. If you have Multiple farms then it consolidates management for Search, Profiles, My sites, etc...

2. Can reduce number of servers and disk space for Query. If high availablity of the site is important, but search isn't, you could save a bunch on disk space by having your Index/Query/WFE SSP farm all on one box thus reducing the storage needed on query since it would be on the same box. You could even use the same SQL environment for the 2 farms.

3. Politics - The SSP is a very hot commodity, by putting it in it's own farm you can optimize the disks, SQL, the management from top to bottom could then be managed in a vacuum. This doesn't have to make sense from a technical point of view to see how multiple groups could divide their farms then consume a common "enterprise search" experience.

What to avoid...

You may think, why not run Search in a separate farm with the Search SKU (Microsoft Office SharePoint for Search Standard or Enterprise) and have it provide shared services. Won't work. Both parent and child farms need to be the same SKU (hence same features).

What you may not know...

Excel services although it shows up as a shared service, it's basically config for the safe locations. The Excel services are still with the consuming farm for rendering and calc purposes.

Forms services are always on the front ends for rendering. There's actually no real way off offloading the forms rendering to an app server if you wanted to, but you can offload document conversions i.e. the document HTML transformation service.

Contrary to some rumors there is no magic latency calculation to consuming shared services over the WAN.

Some Additional Information

Some data from the multi farm Visio deployment docs. I noticed this doesn't come up in search. Guess our favorite Internet search engines like Live don't have Visio Ifilters.

Model: Office SharePoint Server Inter-Farm Shared Services

Snippet from the Visio (good stuff):

Shared Services Providers can be configured to provide services to multiple Microsoft® Office SharePoint® Server 2007 farms. Utilizing Shared Services Providers across farms:

• Reduces the number of services that provide the same role.
• Dramatically reduces hardware, resource, and network bandwidth use.

Centralize administration of Shared Services Providers.

· Intra-farm shared services are offered by a parent farm to one or more child farms [Joel: One to one or one to many relationship]

· 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. (Joel: This is not saying the same as Intra-farm)

Only one Shared Services Provider can participate in inter-farm shared services:

· Parent farms can only share one Shared Services Provider to child farms. However, a parent farm can include more than one Shared Services Provider for its own use (see Parent Farm left).

· Child farms can only consume services from one Shared Services Provider. However, a child farm can include more than one Shared Services Provider for its own use. (see diagram)

Shared services consumption for child farms can be reconfigured at any time (not true in SPS2003):

· 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 Shared Services Provider.

· Child farms can consume shared services from a parent farm when connected to the central network and then switch to consume services from its own Shared Services Provider when it is disconnected. Child Farm 3 (see diagram) illustrates a farm with a standby Shared Services Provider that is used when the farm is disconnected.

· Parent farms can be re-configured as stand-alone farms at any time. Parent farm administrators should alert administrators of affected child farms before reconfiguring the Shared Services Provider as a stand-alone Shared Services Provider.

The following limitations apply to Inter-farm shared services:

· Parent and child farms must reside within the same Active Directory forest. If the farms reside in different domains, there must be a trust relationship configured between the domains.

· Inter-farm shared services is not supported across a WAN. A child farm cannot be associated with a Shared Services Provider at 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 Microsoft 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] CAL of Office SharePoint Server, then the parent farm must also use the [Enterprise] CAL (as opposed to the [Standard] CAL).