10 Things SharePoint Admins Should Know About Project Server

It’s a rite of passage within every Project Server implementation.  At some point, I sit down with the SharePoint administrator and brief them on what it is exactly that they’ve gotten into it – what exactly they’ll be supporting going forward.  Sometimes it’s part of the demo process.  Sometimes it comes much later.  Here’s the discussion in written form.

Top ten things a SharePoint Administrator should know about Project Server 2010 (in no special order):

1) Project Server schedule data resides in an additional 4 databases for each instance of PWA provisioned.  These databases need to be included in your disaster recovery plan, and are accessible from the Central Administration Farm Backup page.  Collaboration content is stored in your SharePoint content database.  A full backup/restore plan will need to accommodate all 5 databases – more if you plan on deploying multiple Project Server instances.  Note also that search will natively index any site based content, but will require the configuration of External Content Types to index the Project Server databases.

2) Despite its name, the Project Web Application is a site collection.  PWA is the top level site in the site collection.  However, PWA should never be the top level site collection within a Web App.  There should always be a top level site collection within the Web App, even if it’s a simple team site with security blocking anyone from accessing it.

3) The security structure within PWA is separate from the SharePoint security structure. Project Server maintains its own pool of users, which may be drawn from AD or other authentication mechanisms.  That pool is managed in its own interface.  This pool controls access to the main PWA site, and may be used to drive security on the individual project collaboration sites (see the next point).

4) Each project creation event may/may not provision a collaboration site (depending on the Project Server configuration).  The project collaboration site is essentially a plain old team site with the Project Server feature activated.  That site may be hosted within the PWA site collection or, with some configuration, outside of the PWA site collection.  Security on these sites may be automatically managed from within Project Server or that linkage may be turned off and replaced with a traditional SharePoint security model in cases where the organization has policies requiring AD-based security on SharePoint sites.  The same governance discussion that took place around your original farm needs to take place around these sites, i.e. disaster recovery and document retention policies, particularly as these sites are often intended to be transitory sites that get decommissioned at the end of the project.

5) Project collaboration sites may be edited within specific limits.  Most organizations decide to customize the default project site template – which indeed can be mapped to specific project types for the automatic provision of differently branded sites.  Content types do not come provisioned by default but may be easily implemented within the project site.  Four lists/libraries are provisioned as part of the Project Server feature: Deliverables, Issues, Risks and Project Documents.  Those entities may be edited, but do so with caution.  Project Server expects to see specific fields attached to each item within those lists and libraries.  Those fields may be hidden, but not deleted – and additional fields may be added as needed.  The Project Server feature also provisions a number of Web Parts to surface Project Server data.

6) Project Server requires SharePoint Enterprise features (and the concomitant licensing requirements). The upside of this is that Project Server relies on all of the SharePoint reporting tools to report against the Project Server databases.  Excel Services, PerformancePoint and SSRS may all be used, with the Project Server database providing your data source.  Project Server also provides the feature to optionally build OLAP cubes of project and resource data, which may in turn be used to provide additional data to reporting tools.

7) Patches are released on the same frequency as SharePoint patches.  In fact, patches are bundled with the bimonthly Office Server cumulative updates and service packs.  That being said, patching Project Server is a bit more sensitive as you should generally try to ensure that all client installations of Microsoft Project Professional are patched at the same time as Project Server.

8) Users need a client access license (CAL) to access Project Server.  More importantly perhaps, users need a CAL to access Project Server data.  As always, when in doubt about licensing issues, always refer to your Microsoft licensing specialist, but the rule of thumb that I’ve always followed is that if they are accessing real time data from the Project Server database, they need a CAL.  This means that even if you’re surfacing Project Server data via External Content Types into an External List on a non-Project Server farm, you still need a CAL to access that list.  The corollary to that rule that I learned recently is that for the most part, if you need to ask whether or not you need a CAL for a specific scenario….you need a CAL.

9) Project Server may be deployed on the main corporate intranet or within its own farm.  Architecting a Project Server deployment is a discussion that needs to happen early on in the process.  Consider whether the benefits of making Project Server available to the sites on your intranet outweigh the benefits of deploying Project Server to its own isolated farm.  Check online for a number of discussions around this topic.

10) Do not try to implement Project Server on your own.  Always consult with your local Enterprise Project Management implementation partner even if it’s just to put together a couple of roadmapping sessions.  Simply standing up Project Server with a “build it and they will come” approach almost never works.

That’s my list.  What’s on yours?

Advertisements
10 Things SharePoint Admins Should Know About Project Server

31 thoughts on “10 Things SharePoint Admins Should Know About Project Server

  1. Good stuff as usual, Andrew. Point number 10 is very important. I’ve worked on many remediation projects that started as a “this can’t be that hard, it’s Microsoft…like Office” and actually forced a step back because users didn’t know what to expect, how to use it and how to get value from it.

  2. Ian Moss says:

    Great article! Just wondering, is it possible to migrate Project Server 2007 to SharePoint 2007? Even though we might lose some features and functions, but could we be able to migrate the data into SharePoint so that we be able to access Project Server documents and lists in SharePoint? Is it possible to keep version history as well? What issues will we encounter? Thanks in advance!

  3. Antonio Maio says:

    Great post. Thank you. Question for you – do farm level solutions that were built for SharePoint (built on the SharePoint 2010 Server Object model) just work with sites/libraries/lists within the Project Server web app? Or are modifications required?

    1. Good question. For the most part, I haven’t seen many issues. You might want to watch out for a couple things: The Project Server lists have a different list type ID (or whatever) than the SharePoint lists. So for instance, the SharePoint Issues list is of type 123, and the Project Server issues list is of type 000 or something like that (it’s been a couple years). So make sure if you reference that to account for it. Other than that, some PWA security settings may impact the user experience in the list, i.e. if you can’t access PWA, you can’t connect the items to tasks. Make sure you validate for stuff like that and you should be in ok shape.

  4. Great Post,
    Quick addition may be can be considered as #11 😉 Just kidding
    “Project Server is not just a service / site within sharepoint, it’s a complete application based on sharepoint platform”

    Have often encountered this feel & had to explicitly clarify, DONOT consider PWA just as a sharepoint site / collection rather its a whole application in itself, if you do so you are shooting yourself in your leg 🙂

    1. Typically when deploying Project Server 2010, you would create a Web Application. Within the Web App, you would create a top level site collection – and probably restrict access to the Admin. Then, you would create PWA as the second site collection within the Web App. Bad things happen when you try to implement disaster recovery and your PWA site is the top level site collection.

    2. Ilia says:

      Excellent article, thanks!
      My guess or interpretation of #2 would be that the “top level site collection” in question is rather the root site collection, the one that has URL identical to the SP Web Application. I am not aware of hierarchy or order in the Site Collections within the SP Web Application (but learned that it is never too late to learn, so anything is possible).

  5. Can you please elaborate on the following: “That site may be hosted within the PWA site collection or, with some configuration, outside of the PWA site collection.”

    I’ve never liked the idea of piling every project site (as an SP Web) under one site collection. At a certain point, that’s going to make data recovery scenarios “iffy” because a site collection’s data can only reside in a single content db.

    Do you have any recommendations or resources for allowing the autoprovisioning of a site collection per project, rather than a web which appears to be the default approach?

    1. The general guidance for 2007 and 2010 was to keep your site collections below a manageable size for backing up in a single database – usually around 100GB or so. Hence, I’ve been involved in some implementations where we had one site collection per project. In these instances, we were talking large multiyear construction projects where we only created a handful each year. For this, a manual process was sufficient, although I suppose you could write an event handler to catch new projects, and then provision a site collection automatically.

      I would question whether or not this would make sense if you don’t think a single site would ever hit the size limit. The other option would be to create a site collection to capture your sites, and when you hit a certain size threshold, create a second for additional sites. It’s a bit of extra work to ensure the webparts work in that site collection….and you’d have to justify that work.

      My impression is that in 2013, things are a bit more portable, and with advances in backup technology, that 100GB rule is no longer strictly adhered to – but it’s been a while since I’ve run into a scenario where it would make sense to create a site collection per project. I have run into scenarios where projects are provisioned in other site collections – but that’s usually due to organizational structure rather than technical reasons.

  6. bill says:

    My company is swimming in #10 right now… our consultant left far too early in the implementation and inhouse WSS resources are limited. My immediate concern is that our inhouse admin wants to make changes to the Risk/Issues ‘category’ field values…so get rid of the Category1/2/3…etc..and replace with ‘escalation, external dependency, yadayada… We are on Project Server 2013 onpremise and SP 2013 if it matters. Do you know of the definitive or most assured way of doing this w/o hosing existing 1,500 live projects? As I understand it we have to create a new site template and add the new Category column values…save that as our new site template and associate to an EPT of choice … not a problem for new. Question though is would they go about updating existing 1,500 active projects with new values for the dropdown … shell script…sql script (thinking not since it seems to be a sharepoint content thing) … I am just not seeing anything definitive … any help would be greatly appreciated

  7. Been down that road many times before. You basically have a choice of running a custom Powershell script or manually changing the existing sites (sounds tedious, but it’s doable w/ enough time). On the positive side, you may want to validate how many of those sites are still active for the live projects. We find organizations tend to overestimate how many existing projects are actually “live.”

    Note that you’ll need to figure out some logic to map existing risks to the new categories – or simply leave them blank. I’d also recommend using content types in the future to negate this as an issue (see a couple of blog posts on content types for risks and issues)

      1. It does seem so since the hub is at the farm level and the paw is a site collection in the farm but I can’t find a def yes or no. Thx anyhow!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s