In the last month I’ve had a few design sessions and conversations where more than just WSS and SharePoint Server are involved in the deployment.  In one customer it was wild… MS CRM, Performance Point, and Project Server plus the normal MOSS stack.  They were going to do it all in one farm with a bunch of app servers and even add a SQL Reporting server and SQL Analysis server.  It gave me a headache looking at their diagram. 

In an hour I had them with the same amount of production hardware, but in 4 farms.  SQL on the backend for storage was changed hardly at all.  I also added a more robust virtual dev and test environment to mimic the new designs. Was pretty sad.  <Update> Reporting Services with SharePoint Integrated mode is much better and has good deployment guidance on TechNet at Deplyment Planning for Reporting Services with SharePoint Integrated Mode which includes high availability solutions.</update>

Why so many farms?  Can’t project server live with MOSS?

7 Reasons I don’t install Project Server on SharePoint Server

1. The SharePoint database rules and Projects reporting capabilities and flexibility (history) – I’ve achitected, administered, and troubleshoot Project Server off and on since 2002.  The expectations around installing funky service packs and running analysis cubes and massaging the database and connectivity has a history with me.  I’ve had cool aid conversations around list scalability and the project databases with the project team.  They are drinking more cool aid than they use to, and the uptake of Project as a commodity has REALLY come a long way.

2. Service Pack and Integration testing (perceived?) – Around RTM I was working with Boris on the project TPM side who spent years in Europe on Project 2003.  He was just down the hall.  We’d have long conversations around templates, integration, and even spent time together talking about lists, GUIDs, and web app challenges.  The service pack testing and integration was one where I saw obviously the WSS integration testing, but the time spent on cross testing with MOSS seemed to come late.  There likely is some cross testing with MOSS, but this is where I start to get nervous about environments.  There’s a lot of test cases that will never make it in.  Don’t expect the SharePoint Server team to do cross testing with Project Server, and the Project team, what are they testing?  They are testing their bread and butter.  You know where I’m going.  Every service pack there is complexity around order of patching and what includes what.

3. If you’re on MOSS and you add Project Server it’s not much of a Lights on (It is the other way) – Many people would expect wow I’ll get all the project stuff that I can now integrate with my SharePoint collaboration sites.  Those project templated sites can be just as easily accessed from another farms with the data viewer web parts.  That Project template is nice, but does it really add what anything you need to your collaboration sites?  You tell me.  Love to hear responses to this.  I don’t see how you couldn’t get the same with a cleaner admin experience having it on a different farm.  (I can see getting the auditing, workflows, and web publishing features to light up if you were planning projects.)

4. Performance Footprint – Project is quite intense with it’s query and analysis structure.  I would suggest keeping those databases on different physical drives while I think sharing the high availability SQL environment is fine in most cases.

5. Portal GUID issues – Do some research on site to site migrations and disaster recovery with Project server and you’ll find it is actually a different kind of app.  They have some unique challenges and run some unique STSADM commands.  This next level of troubleshooting is one where you really may want to limit the exposure.

6. Future Upgrade challenges – Ok, so you’ve been running Project Server 2007 and MOSS 2007 for years and now you’re ready to go to 2010.  Hmmm.  Now complexity is really exacerbated (extreme).  Do I need to say more?  Those using project have these timelines and the collab people are ready for the platform yesterday to take advantage of X and Y.

7. Specialty Expertise – Try finding a the UBER Architect/consultant who can do EPM Enterprise Project Server and SharePoint Server.  You thought the SharePoint guys bill rates were high.  HA! (Now add the CRM, and Performance Point requirements to your project and try to find someone… Talk about jack of all trades and expert of none.  Sorry wild crazy consultant guy who doesn’t sleep.  You do rock! …but we all know you don’t have availability ‘cause you don’t even twitter and share your integration experience.)

Having had experience working with the project server team for the last 5 maybe 6 years.  My history tells me they aren’t drinking the full SharePoint list cool aid.  They’ve come a LONG way.  I give them a ton of credit.  From where they were in project central and in that whole evolution.  It’s this history that teaches me a lesson of their evolution of their database structure and analysis and comfort level of publishing schemas and encouraging people to do reporting on the databases.  It’s a different world despite the fact the great hooks built on WSS.  The middleware integration around features isn’t as mature as you’d expect.  The idea of features is awesome and if you find something that you need, it likely isn’t that much of a challenge to track down that piece of functionality and get it over to your collab environment.  I worked on a hosted design of project server with a contractor back in the 2003 days.  I installed a service pack on that environment and had to run a batch script over a hundred times (we were hosting one of the largest project server hosted deployment with over 100 databases).  My time in the trenches troubleshooting the connectivity to the “orgs” that we were hosting on project server had a different sort of middleware feel to it.  I’m happy to see them come to the commodity hosting game and take advantage of SharePoint scale and ease of supportability from where they’ve been.

One consideration is not what Project brings to MOSS, but the other way around.  What does MOSS bring to Project Server?  Maybe that’s a better way to look at it, and actually might be the route still of getting say auditing and deeper workflows and ECM on your Project sites.  Still you might want to keep your collab and other portals separate.  I came across a BDC project on Codeplex to pull in data from Project Server.  You could do that with 2 farms or not.

What about performance point?  The argument isn’t as clean, but yes I’d recommend the same until the next version. Usually a performance point box doesn’t need high availability, but could definitely get away with virtual servers.

What about Reporting Services SharePoint mode?  Definitely separate for HA.  If not HA then if you’ll never be HA, then ok, you can keep them together.  That’s for the smallish environments.

Other dynamics applications?  Today – keep ‘em separated.

Isn’t this all contrary to the Small Biz Server Mentality – Yes. I’m not a fan of the Exchange/DC/SharePoint all in one.  I think it’s crazy.  Definitely crazy now that we have virtual server technology.  No reason to mix these things.  Put ‘em all on the same host sure, but keep ‘em separated.

That’s my story and I’m sticking to it.  Ask me again in 2010.  What’s your story!!??

Oh by the way… Is it support to run these together?  Yep.  Here’s the articles on TechNet that prove the answer is yes.

Deploy Office Project Server 2007 with Office SharePoint Server 2007
Deploy Office SharePoint Server 2007 to an existing deployment of Project Server 2007
Deploy Office SharePoint Server 2007 and Office Project Server 2007 to a new environment

Apparently Christophe (The MAN on Project) did a talk on the better together story in Barcelona.  I hope he’s not mad at me for this post.  Deploying Project Server 2007 in an Existing SharePoint Server 2007 Farm.  No hard feelings Christophe, I’m happy to talk about SharePoint at your Project Conferences any time.

I find that Nilesh says it was “interesting and a real challenge to implement” in reference to a MOSS and Project install experience.

Reading through blogs on the topic to find some nuggets I love this question.  Brian Smith from Project Server’s Product Support’s answer makes is sound so easy.  Thanks Brian.

# re: Project Server 2007: Deploying Cumulative Updates

we have an environment where initially WSS and MOSS have been implemented and patched to IU, then Proj Svr installed +  SP1 (Office Svrs IU can not be run 2nd time) Which Feb CU patch should we use?

 BriSmith

Hi Matt,

You need both the WSS (961755) one and the MOSS Server one (961756) - this will cover for WSS, MOSS and Project Server. Brian.

Brian’s latest post on failures in step 8 of config wizard helps to bring out the scariness of wierdness in patching.

SHayden did a scary blog on “Forcing uninstallation of Project Server 2007 or MOSS 2007” (He rebooted to early and couldn’t even run psconfig?)