Project Server 2010: Goodbye SSP, Hello Service Application

The new architecture in Project Server 2010 (from SharePoint 2010 of course) see the end of shared service providers and the introduction of Service Applications. For an excellent coverage of this change see http://blogs.msdn.com/russmax/archive/2010/01/20/sharepoint-2010-shared-service-architecture-part-1.aspx but here I’ll talk about how this affects Project Server.  The SSP is gone, but as far as SharePoint is concerned shared services are still around.  For Project, there is not too much change from 2007 – we are a very selfish ‘shared service’ that doesn’t like sharing.  A good comparison here is Search or Excel Services, where some of the definitions of the service application can specify the scope of that service application and then this can be ‘shared’ to a specific audience. Whereas Project service applications just have PWA instance within them and then all authorization and scope is set within the PWA instance itself – so you can understand why sharing the service application doesn’t work for Project.  So while there can be good reasons for having many different defined Service Applications for other SharePoint 2010 Service Applications – the argument for Project just isn’t there – you probably just need one, and this will have one proxy (one to one relationship of SA to Proxy) and this proxy will be in the default proxy group, and also any custom proxy groups for web applications that you wish to have PWA instances provisioned within them.

Service Applications, Proxies and Web Applications

One early catch in the Beta for Project Server 2010 was that customers were very used to SSPs in 2007 and wanted to use Service Applications in the same way – which doesn’t really make sense.  Unlike a Shared Services Provider, a Service Application does not have an admin account as such – so all project queue and event services will run as the farm administrator.  Also in 2010 one Service Application can work across multiple web applications – so again, one will work across your whole farm – and not the need to have multiples – in the way that web applications related to SSPs in 2007.

When creating a Service Application you will usually choose to create a proxy,and this will be placed in the default proxy group.  If you are creating multiple Service Applications (for whatever reason) then you will almost certainly need to create custom proxy groups and ensure that the default PSI Service Application is the right one in each custom proxy group for the specific web application.

The relationship between the web application where your PWA instance exists, and the Service Application that created it are via the proxy.  It is however possible to create a PWA instance in a web application where the proxy that should be servicing this PWA instance is not the default proxy, and therefore connectivity back to the Service Application (PSI) will not be possible – and the much dreaded ‘unexpected error’ will occur.  For a PWA site to connect to its Service Application its proxy MUST be the default within the proxy group for the web application.

I will follow up on this blog posting with one on troubleshooting these connectivity issues between web application and Service Application (PSI) and in that post I will also have some of the common ULS error messages you might come across.

I feel I’ve said the same thing several times here – but can’t say it too much, as early evidence says this will trip alot of people up.

Technorati Tags: