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.
Can I take from your explaination here, that there should only be one "ProjectServer" Service Application per SharePoint Farm?
In a scenario where an organization is planning an organization wide SharePoint Server 2010 deployment, but the EPM group want to get their Project Server 2010 implmentation deployed prior to the organization wide Farm being available, can the Project Server 2010 SharePoint Farm and the orgainzation wide SharePoint Server 2010 Farm be integrated afterwards?
If so, should they be maintained as separate Farms?
How would the integration be accomplished?
Hi Wayne - and yes, there is no good reason to have more than 1 ProjectServer Service Application. In the scenario you outline there is no real way to integrate later - apart perhaps from indexing the Project Server 2010 SharePoint farm from the other one. For example you could not expose Project Server web parts on the other farm. You could migrate the Project instance over to the other farm (Content DB + 4 Project DBs and re-provision). Pros and cons? - having them separate can give flexibility when it comes to patching - but there are some better together scenarios too. You pays your money and you makes your choice - as they say.