Assuming you have a solid understanding of Shared Services in SharePoint Server 2007, and what they provide, we next investigate the differences of Inter-farm SSPs and Intra-farm SSPs. Intra-farm SSPs are multiple SSPs within the same SharePoint Server 2007 farm. Remember that farm = configuration database, so Intra-farm SSPs will all share a common configuration database. First, most installations should have a single SSP. The best practice is to have as few as possible. While it is feasible to have up to 20 SSPs in a single farm, it overcomplicates your configuration and management and is rarely needed. Index and query functions are the primary reasons to create a second SSP in a single farm. Real-world experience has shown four SSPs to be the real performance limit in a SharePoint Server 2007 farm.

Inter-farm SSPs are created for several reasons, but usually for performance increases or process isolation. First, large implementations sometimes build entire SharePoint Server 2007 server farms for the sole purpose of providing Shared Services. This allows dedicated hardware and software for things like searching, queries, Business Data Catalog, and truly global audiences. Second, creating a second SSP can create a boundary between the Shared Services being provided and the consuming SharePoint Server 2007 farm.

There are limitations to Inter-farm Shared Services, however. The first limitation is that Excel Calculation Services cannot be provided or consumed between server farms. This is rarely an issue, but it is one that must be planned for. Second, you cannot consume Shared Services over a Wide Area Network. There is a lot of gray area between a local gigabit network and a regional network, such as a campus area network. A good rule of thumb for Inter-farm service design is that you must control the fiber that connects two server hosting points. So dark fiber that you light, connections between campus buildings, and high-speed regional links might work. You should consult Microsoft with your specific design if you will cross network connections that are not on the same Local Area Network (LAN). It probably depends on who you ask at Microsoft whether you will be supported or not. Whatever the answer–get it in writing.

Designing Intra-Farm Shared Services

As previously mentioned, one SSP is sufficient for most installations. The following are some requirements that might force multiple Intra-farm SSPs:

  • Hosting multiple Web applications in a charge-back mode for internal customers. Each customer may require a different set of Shared Services.

  • Sarbanes-Oxley (SOX) or HIPPA regulations might require a separate SSP for Records Management.

  • Specialized organization units such as legal or human resources.

Multiple Intra-farm SSPs should not be considered when absolute isolation is required for security. Some server roles, such as Excel Calculation Services and Search queries, cannot be isolated to a specific SSP. If you require absolute isolation for security, you should consider hosting Shared Services in an entirely different server farm.

Note

You cannot associate query servers with a specify index server. Each query server in the farm will build indexes, and return query results, for all SSPs in the farm. If you require query server isolation, you must build a second SharePoint Server 2007 server farm. You also cannot associate Excel Calculation Services servers with a specific SSP.

Multiple SSPs in the same farm allow for dedicated Shared Services for one or many Web applications. Figure 16-12 shows a possible logical architecture of a SharePoint Server 2007 server farm using three SSPs.

Each Web application can be associated with one SSP.

Figure 16-12. Each Web application can be associated with one SSP.

Each farm must have a default SSP. You may have multiple Intra-farm SSPs, but one of those must be the default. The default SSP is associated, by default, with all new Web applications in the farm. You can change the association later if desired.

Note

You cannot delete the default SSP. If you want to replace the default SSP, you must create another SSP, make it the default, and then delete the original.

Important

Use caution when re-associating Web applications with SSPs. All site settings that are inherited from an SSP, such as search scopes, audiences, Excel Calculation Services, and My Site settings, will be lost.

Designing Inter-Farm Shared Services

Inter-farm Shared Services implementations are much rarer than Intra-farm Shared Services, but can still serve a useful purpose when there are requirements for process isolation for the reasons of performance and security. Inter-farm Shared Services are the consuming of Shared Services from another SharePoint Server 2007 server farm. There are some limitations when consuming Shared Services from another farm, such as:

  1. Cannot be consumed over a WAN.

  2. Excel Calculation Services cannot be shared Inter-farm.

  3. You must provide authentication between farms.

  4. You cannot consume another Shared Service, such as Search or Audiences, on a per-service basis. With the exception of My Sites, you must consume the entire provider’s Shared Services, or none.

At first glance, many administrators have planned to use a centralized farm for organizational Shared Services, and then provide these services to geographically dispersed SharePoint Server 2007 server farms. Because the consuming farm is actually making a SQL connection to the provider’s Shared Services database, WAN connections are not possible. It is very likely you could make it work with a low latency, high-speed connection. Be aware that it is not supported by Microsoft. If you have a geographically dispersed environment, read the last section in this chapter, "Geographically Dispersed Deployments."

So why implement Inter-farm Shared Services? If you create a dedicated, centralized SSP, you can offload the overhead of these services from your production collaboration and publishing farms. The following scenario assumes the purpose of multiple farms is for performance, but the same logical designs will work for security as well. Figure 16-13 shows an example of a dedicated server farm for a centralized SSP.

A centralized SSP offloads processing from busy collaboration farms.

Figure 16-13. A centralized SSP offloads processing from busy collaboration farms.

When creating a central SSP, it is best to do so in the beginning. It is not required, however, and in fact we can change the SSP consumption at any time in SharePoint Server 2007. As is discussed in the Microsoft SharePoint Products and Technologies Administrator’s Pocket Consultant (Microsoft Press, 2007), you can associate and un-associate with providers at any time. There are some limitations when providing Shared Services to another farm:

  • Only one Intra-farm SSP can provide Shared Services to other farms.

  • A farm can only consume Shared Services from a single provider.

  • When re-associating with another SSP or creating a local SSP, all site customizations based on the previous provider will be lost. Search scopes, audiences, and BDC connections are the most common.

Inside Track: Using Inter-Farm SSPs

If Intra-farm Shared Services are Web applications consuming from SSPs within the same farm, then Inter-farm Shared Services are Web applications consuming from SSPs outside the farm. Because of the WAN limitation (can’t consume SSP across the WAN), many people discount a solution with more than one farm. Consider this: It really isn’t that strange to create two farms in the same region. Why, you may ask? You may decide that you want to do collaboration with out-of-the-box functionality—for example, custom master pages and layouts—but pretty much no custom assemblies or custom site definitions or Web parts. On the other farm, you create your intranet portal with custom Web applications for your business and it becomes much more application-centric.

Why Have the SSP in a Separate Farm?

  • If you have multiple farms, then creating an SSP in a dedicated farm consolidates management for Search, Profiles, My Sites, and so on.

  • The number of servers and disk space for Query can be reduced. If high availability of the site is important, but search isn’t, you could save considerable disk space by having your Index/Query/WFE SSP farm all on one box, thus reducing the storage needed for Query since it would be on the same box. You could even use the same SQL environment for the two farms.

  • Political reasons can be important. The SSP is a very hot commodity. By putting it in its own farm, you can optimize the disks, SQL, and the management from top to bottom could then be managed in a vacuum.

What You May Not Know

  • You may want to run Search in a separate farm with the Search SKU (Microsoft Office SharePoint for Search Standard or Enterprise) and have it provide Shared Services. Unfortunately, this won’t work. Both parent and child farms need to be the same SKU (hence same features).

  • Excel Calculation Services show up as a Shared Service. It’s basically just configuration for the safe locations. The Excel Calculation Services are still with the consuming farm for rendering and calculation purposes.

  • Forms services are always on the front ends for rendering. There’s actually no real way of offloading the forms rendering to an application tier server. You can offload document conversions, however.

  • Contrary to some rumors, there is no magic latency calculation to consuming Shared Services over the WAN.

Shared Services Providers can be configured to provide services to multiple SharePoint Server 2007 farms. Utilizing Shared Services Providers across farms has the following benefits:

  • Reduces the number of services that provide the same role.

  • Dramatically reduces hardware, resource, and network bandwidth use.

  • Centralizes administration of Shared Services Providers.

Shared Services Design Notes

  • Intra-farm Shared Services are offered by a parent farm to one or more child farms.

  • A provider farm is configured to provide Shared Services to other consumer farms.

  • Consumer 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 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.

  • Child farms can only consume services from one SSP. However, a child farm can include more than one SSP for its own use.

  • Shared services consumption for child farms can be reconfigured at any time, and can disassociate from a parent farm and be configured to either consume Shared Services from a different parent farm or use its own SSP.

  • 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 SSP as a stand-alone SSP.

The following limitations apply to Intra-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.

  • Intra-farm Shared Services are not supported across a WAN. A child farm cannot be associated with an SSP 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).

Joel Oleson, Senior Technical Product Manager, Microsoft

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.149.214.32