For those of you who don’t know what I am talking about a bit of overview. In MOSS 2007 there is this new concept of Shared Services Providers(SSP). The idea being that there are certain services that really make sense to centrally manage and share. A good example being profiles. With a SSP we can import all of the profile information from AD once and then our various web applications can consume the data. So maybe we have http://marketing and http://accounting it doesn’t make sense for each one to maintain identical profile information, they should share.
The major services that are handled by the SSP are:
Profiles and Audiences
My Sites
Search
All of Excel Services
All of the BDC (Business Data Catalog)
Below is an example screen shot from MOSS 2007 Enterprise:
Sometimes the easiest way to think of Shared Services is the Parent vs. Child relationship. The Parent (your SSP) goes out and does all of the work (pulling BDC data, indexing content, hosting My Sites) and the child (your web applications) come to the parents to ask for $5 (request data from the BDC, or view a calculated Excel sheet). Does that help?
Multiple SSPs
One of the most overwhelming things about SSPs for some people planning is how many should I have? It is easy to see from the interface that you are given the opportunity to create more than one. When should you do this?
As a general rule of thumb most companies will use one SSP. This is my default answer. So why do they give you the ability to run multiple SSPs? There are cases where you want separate search or profiles. The most common? Extranet/internet scenarios. Maybe your SharePoint farm hosts two primary web applications. http://portal for your intranet and http://ourcustomers for your extranet. In this scenario you probably want separate search and profiles. And now you have found the reason to have multiple SSPs. You don’t want to share information you want unique information for both.
Another advantage of SSPs
Separation of roles. In some medium and large environments it is not uncommon to have one group administering the physical server farm while another group needs to just maintain search. Well the SSP concept makes this very easy. Since the SSP is its own SharePoint site collection you can define a users access so they can NOT access central administration but they CAN access the SSP. And once they get into the SSP you can even limit them. Once inside the SSP you can determine if they can:
Manage user profiles
Manage audiences
Manage permissions
Manage usage analytics
Best I can tell if you give them access to the SSP all of the other SSP functions they will have rights to. Guess it needs more testing.
Still this separation of services from the actual administration of the server can be quite useful. Epically in companies where the less access I give a user the better.
Moral of the story
SSPs are very helpful and important to understand. They should be part of your initial planning. They can be secured at a very granular level or they can be give broad access. Just mark this topic down as something else you need to full think through before you start rolling out SharePoint. And when all else fails just have one SSP.
paulgilbride.com 