Microsoft SharePoint Conference 2009: Day 2

A few highlights from today’s talks:

  • With SharePoint 2010, we no longer have a Shared Service Provider (SSP), instead we now have service application instead. All of the applications benefit from an internal load balancing scheme (fault tolerant round robin load balancing), meaning that as long as you start a service application on more than one server, you’re better protected from failure.  Oh, and yes, that goes for indexing as well!
  • The Service Application framework is extensible; this means you can write your own services to be hosted by SharePoint. These will, in turn, benefit from the internal load balancing scheme mentioned above.  Yes, you can also use a hardware load balancer and from what I gathered, even write your own load balancer!
  • All of your Service Application management can be done from PowerShell – if you don’t know PowerShell, now is going to be a very good time to learn…  If you want to have a look at the available applets, try the following in PowerShell:
    this will return the list of available commandlets.
  • You will be able to add delegated administrators for specific Service Applications. These delegated administrators will have their view of the Central Administration site trimmed to only those items they should see.
  • Claims based auth looks very interesting, and can be extended to allow 3rd party applications to provide additional claims.
  • SharePoint Designer 2010 rocks!

2 Replies to “Microsoft SharePoint Conference 2009: Day 2”

  1. Your 1st bullet point about “Shared Service Provider (SSP)” confused me. If you could explain a little more elaborately (may be a picture) that would be greatly appreciated

  2. SharePoint 2007 had a Shared Service Provider (SSP) which hosted some of the services required by SharePoint. These services were all grouped together. The SSP allowed us to create a configuration encompasing search, BDC, profiles and audiences which could be shared between web applications. In the normal (i.e. simple) case, only one SSP would be required. What if however we wanted another web application with the same search settings, but different BDC settings? A new SSP would have to be created and all of the required common setting duplicated over to the new SSP. The 2 SSPs were also completely independent of each other and could neither be scaled terribly easily, nor shared across multiple farms easily. The new architecture of Service Applications breaks up the SSP allowing us to have separate services for us to deploy as is most appropriate for the farms we’re deploying. The service applications can be installed and configured separately (including separate databases for each service application!) and can be scaled as we wish to meet demand. SharePoint 2010 also manages the load balancing of these service applications for us (unless we want to manage them ourselves). In addition, because all communication is now via web services, SharePoaint no longer cares where these services are run, so in an extreme case, we could have a SharePoint farm simply to run the service applications, whilst other farms consume the services provided. I’ll dig out some pictures and either add them here, or add another post showing the SharePoint 2010 architecture.

Leave a Reply

Your email address will not be published. Required fields are marked *