A couple of days ago, I posted on 10 Things SharePoint Admins should know about Project Server. That prompted SharePoint consultant Shane O’Hanlon (@GetOffMyPatch) to challenge me to list 10 Things Project Server Admins Should Know About SharePoint. Now, I would hardly claim to be much of a SharePoint expert…despite playing one at various SharePoint Saturdays, attending the local SharePoint User Groups, and having worked with some of the finest SharePoint consultants out there…but I figured it was worth a shot.
So here goes…..10 Things Project Server Admins Should Know About SharePoint (and for a wider post on Things Project Server Admins Should Just Know Anyway, please see here).
First, a bit of a caveat. These items may only be relevant to Project Server Admins who fit a specific profile. Will the Project Server Admin be the person installing the SharePoint farm on which it sits? (I certainly hope not.) Will the Project Server Admin be the person who is in charge of the disaster recovery solution? (Maybe/maybe not). So take these specific recommendations in the general sense in which they are proffered and filter them to your own specific roles and responsibilities.
1) Know How to Build Your Own Environment. Even if your organization gives you a shiny new hosted DEV environment to play with, nothing beats having your own Hyper-V image under your own control that you can break to your heart’s content and use to test out various data recovery and configuration scenarios. It’s far easier to restore to a previous snapshot than to submit an application to the server admins to get your DEV server refreshed every week – and it will save your doughnut and/or bagel budget when you have to start bribing them to do what you ask. Building your own farm is also a fantastic learning experience.
2) Understand the SharePoint Architectural Hierarchy. If you don’t know the difference between a web application and a site collection, go learn. Figure out how PWA and the BI Center fit into that schema. If you have the chance to catch the Shane Young/Todd Klindt roadshow, take a snapshot of “The Best SharePoint Slide Ever Made” and that should simplify everything. (And if anyone knows where that would be available online, please mention so in the comments list.)
3) It’s All About The Governance. Remember that projects are temporary. That means they eventually end. Lots of stuff is produced in the making of that project, not all of it valuable. Figure out what you’re going to do with that content. Project Server by default likes to create a site for every project, often resulting in thousands of abandoned project sites scattered through the farm. Implement a monitoring approach to flag unused or orphan project sites. Last but not least, make sure you have change and release management procedures in place – and just as important, make sure the folks in charge of patching the servers are in tune with your organizational reporting schedule. Don’t go deploying new patches and changes on the evening before your quarterly PMO report is due.
4) Size Does Matter. Often overlooked in the initial planning stages, make some rough assessments as to how much data will be stored on each project site. That will impact the fundamental architecture of your Project Server farm.
5) Plan Your Project Sites. Perhaps repeating the point about governance, but don’t simply start provisioning your farm with all sorts of project sites. Any changes to the content types or available metadata will have to get pushed out to each of those sites individually. Consider all of the changes you will need to make and build your template accordingly. Leverage content types to cascade changes out to already provisioned sites. Don’t know what content types are? See point #9.
6) Embrace the Complexity. Just because you are now a Project Server administrator, don’t try to implement a full SharePoint farm on your own. People study years to get up to speed on SharePoint (and then get recruited by consulting firms due to the market shortage of qualified consultants). Money spent architecting your farm and deploying it properly is money very well spent. That being said, don’t make a junior admin mistake and assume that all SharePoint consultants are created equal. There’re folks who are good at development, infrastructure and/or architecture. Some focus just on search. Don’t just assume that because they have SharePoint on their resume, they actually know how to design a system with Project Server.
7) Test Your Disaster Recovery Process. The Project Server disaster recovery process is separate (but related) to the SharePoint content recovery. Trust your SQL and SharePoint admins to implement disaster recovery, but verify that you personally, with your skill set, can restore all of that data to a new target environment (see Point #1).
8) Don’t Do The Express Installation. I hesitate to get this far down into the weeds on a technical issue, but this is probably the one absolute “No No” in the Project Server world that pops up on the forums every now and then. Don’t do the Express Installation. Project Server, and more importantly, the BI features, do not work well with SQL Express. Honestly, I am not even sure this option is still available in 2010 because I just gloss over it so quickly, that I don’t even think about it. Deploy a full farm with SQL, even if you’re just doing that on a single server.
9) Get Trained. Seriously. Go find a SharePoint class or two and take it. Try to find something offered by a reputable instructor. You don’t have to be an expert, but if you can get the basics up to the level of say, Site Collection Owner, you’re in good shape.
10) Learn to Love Your ULS Logs. ULS logs in 2010 are fantastic. Learn how to read them. Get into the habit of checking them on a daily basis or at the first sign of trouble. Even better, download the ULS log viewer utility from Codeplex and watch them in real time.