Posted on

What is Shared Services Provider?

Sometimes when we are working in a new environment and we have to talk with application teams to define the requirements and explain them the components that we have to implement, it is difficult to explain what Shared Services Provider (SSP) is and why it is very important for a MOSS environment. Some customers confuse this site with the Administration one that is generated by MOSS installation process on the first node, and don’t understand why this site exist in both web front end servers (if you are implementing a Load Balancer environment with SSP running on them).

The idea of SSP is to group certain services that really make sense to centrally manage and share between all web applications running on your farm. A good example is the profiles. With a SSP you can download them from AD once and then serve this information to your web applications; if I have two applications on my farm, https:\\Facilities and https:\\Finance, it doesn’t make sense that each application connect with AD independently and download the profiles…, they should share.

Some of the services shared on the SSP are:

  • Profiles
  • Audiences
  • Search
  • Excel Services
  • Business Data Catalog

As a general rule you need just one SSP on your farm (including just one on your company), but MOSS enables you the ability to create more than one if you want. Why could you need more than one SSP? The most common scenario is the Intranet/Extranet one. Maybe your MOSS farm hosts two primary web applications, one for your employees and other one for your customers. You probably want separate search and profiles because you don’t want to share this kind of information between both audiences. This could be a good reason to use more than one SSP: You want not share information between your applications.

Other advantage of SSP is that you can separate administration roles. For example, it is very common to have one group administrating physical server farm and other to manage and maintain the search, or to work with the audiences. As SSP run in a separate site than Administration site you can grant access to some people to the SSP site but not to the admin one. Once inside the SSP you can limit their access too; you can determine if they can:

  • Manage user profiles
  • Manage audiences
  • Manage permissions
  • Manage usage analytics

Do you need more reasons to justify the use of SSP?

Leave a comment