We have been asked to provide additional information on SharePoint Farms (Single or multiple) – this 2010 blog from Christophe is one that we like to reference.
Your First Question should be are you at the same version of SharePoint? If not you will need to have separate farms until both are at the same updated version of SharePoint.
Do you have more questions – just ask us.
Enjoy,
The MPN Team
~~~~~~
[Update 11/30/2010 – another great reason to deploy it in a single farm is the ability to integrate Project Server web parts in other location within a farm, see this documentation on TechNet for more info. Plan for Project Server 2010 Web Parts]
Following a number of questions on this topic at Tech.Ed a few weeks ago and this recent post from Joel Oleson: Project Server 2010 and SharePoint 2010 Coexistence please find below my humble opinion on this question: Should Project Server 2010 be deployed in a standalone Farm or should it be deployed in an existing SharePoint Farm?
First lets start with an overview of the two deployment scenarios:
- Together/Coexistence - Single farm with both Project Server and SharePoint Server 2010
- Apart/Standalone - Dedicated Project Server Farm running SharePoint Server 2010
As a reminder please find the version compatibility below (see recent Tech.Ed presentation below); in a nutshell you cannot mix 2007/2010 version of Project Server and SharePoint:
So while mix scenarios are not supported, it is possible to go from 1 to 2 (Together to Apart) or the reverse from 2 to 1 as shown below
So back to the initial question, which scenario to choose (again there are plenty more pros and cons I have put together in these slides listed below), well it depends as listed below, but I would recommend a single farm for the following reasons:
Why Together (#1) in no particular order:
- Single Infrastructure: You can leverage the same infrastructure you have put in place for your farm, for instance lets say you have architected the farm for high availability on all tiers (redundancy/multiple servers at the Web Front End and Application tiers, and a SQL cluster for storage), why buy another set of hardware for a Project Web App (PWA) Farm and duplicate resources? Similarly why not apply software update, cumulative updates at the same time, why duplicate efforts across farms?
- Content Management: If you have two separate farm all the SharePoint content generated during the usage of Project Server (document artifacts etc…) cannot be stored in your main content management farm, hence you will duplicate your Enterprise Content Management efforts (governance, digital asset management, record management, etc…), similarly you cannot integrate PWA web parts across farms (we will publish an article this month on what PWA web parts can be integrate in different sites/pages of a Farm)…
- Project Server is a SharePoint App: yes it is and yes it’s not free! but since 2007 we have been build on SharePoint so again why a separate farm. As an anecdote since we are built SharePoint if you deploy Project Server in a standalone farm (scenario 2) you are effectively deploying a second SP Farm in your organization… The 2010 version has gone a long way in terms of scalability, stability/quality so why not deploy it in the same intranet farm according to documented best practices and as usual monitor it so you are always pro-active if issue arises or if the PWA is becoming resource constrained. So why start putting every Service App/Web App in separate Farms, isn't the power the consolidation from a IT and functional point of view?
While with the 2007 version most customer deployment I saw was about a 50/50 split between 1 and 2 (I did talk to a few customers that did not realized what they lost from a functional point of view by separating the farms and were looking for non-supported workaround); in 2010 with the tighter integration with SharePoint 2010 (the Business Intelligence/Reporting capabilities used by PWA or the Demand Management/Workflow capabilities to name a few) and the fact that organization want a consolidated infrastructure for Collaboration (whether its document management, performance management or project management) I would strongly recommend option 1. To follow up on Joel’s arguments (yes this is a constructive argument and Joel and I know one another!):
- Licensing – one could argue that it could cost more to have two farms, if for instance you have redundant servers in both farms you will need to purchase more SharePoint Server licenses for instance. Additionally while its important to focus on acquisition cost, a more important vision is to look at Return On Investment, Total Cost of Ownership and measure the true value of a single/multiple farm over their lifespan. Again you will loose value and incur additional maintenance cost by going with two separate farms as mentioned above.
- Performance – well yes potentially but if you Farm has been architected properly by SP experts and if it’s monitored according to best practices then performance should not be an issue, typically the bottle neck at the end of the day is the database tier (SQL serv
