Project Server 2013 Multi-tenacy. RRS feed

  • Question

  • Hi guys,

    Any documentation you have regarding Project Server 2013 Multitenancy.

    Like Creating feature packs and create hosted Project Site collections.

    Thursday, January 9, 2014 9:52 PM

All replies

  • Hi Prashant,

    Please find some links about PS2013 multi tenancy:


    Hope this helps.

    Guillaume Rouyre - MBA, MCP, MCTS

    Friday, January 10, 2014 2:27 PM
  • I haven't seen any documentation so far but you can start with Sharepoint document, as  Project server is sharepoint app only 

    Multi-tenancy is more relevant to SharePoint 2013 than Project Server 2013, but since Project Server runs inside of SharePoint, Microsoft mentions it in their marketing materials.

    Multi-tenancy in SharePoint 2013 provides more separation of data and services between tenants / groups, and I see it typically being used in scenarios where multiple companies are sharing the same SharePoint farm through a SharePoint hosting company (or Microsoft SharePoint Online). Those companies obviously want their "stuff" to be completely separated from other companies who are sharing the same infrastructure, so Microsoft provides more of that separation in SharePoint 2013 than they did in SharePoint 2010. There is also a tenant administration layer that is added below the Central Administration layer where each tenant has a certain level of control over how services are configured within their silo.

    If you are deploying SharePoint 2013 within a single company, however, you probably do not need to complicate your implementation by enabling multi-tenancy... unless it is a huge company with several large divisions who want more separation between them. Provisioning multiple PWA instances -- assuming that the groups want complete separation of their data, resource pools, etc. -- will probably meet your needs.

    When you provision a new PWA instance in 2013, you must specify a SharePoint Web Application under which to provision the new PWA instance. When you create the new web application, you can assign it a separate SharePoint content database; therefore the data stored in the Project Sites, such as Risks, Issues, Documents, etc. will be in that separate content database.


    Saturday, January 11, 2014 5:31 AM
  • All the above is basically sound.  There are a number of methods to isolate data and the idea of specific content databases for each PWA instance is perfect along with unique project server data database.  Host header site collections is another method that can be used, if you don't wish to create a bunch of web applications.  However, unique web apps may be required to maintain isolation for installed features and other web specific security, 3rd party apps, etc.

    Some Points to consider:

    Project Server is not multi-tenant aware in the SharePoint sense.

    Project Server as a Service Application can only be used with the Default Service App connection group.  This implies that all PWA instances in the same farm use the same (1 and only 1) Project Server service application.  Project Server knows how to handle more than 1 instance, so no issue there.  But it is unlike other SharePoint applications such as Excel which you may have many instances of Excel Service application and associate to specific web applications via the service connection groups.  Not so Project Server.

    Also, you will now introduce other business problems, such as how to report against all instances - by default PWA reporting is "per instance" and there is no cross instance feature.

    this begs the question of Resources - one of the primary functional areas of Project Mgmt.  Each PWA instance has its own Resource Pool.  No sharing.  this may be good or bad depending on the business model.  But overall, this will have a breakdown effect from a " Corporate Portfolio" perspective.  Not just resources, but also projects.

    As has been discussed in this forum elsewhere, you also introduce reporting configuration question such as the ProjectServerApplication entry in Secure Store.  While there may be work-arounds, it causes additional administrative overhead to maintain strict separation.  Or you use a single common entry and "live with the limitation" but ease the admin burden.  Personally, I think it works fine to use a single entry, put all "report authors" groups in there, and simply maintain data isolation at the SQL layer.

    you will also need to architect your farm appropriately, to accomodate the load for many PWA instances all sharing common resources in the farm.  it is a matter of scale and size.  3 pwa instance which are all small data set and low usage would not be an issue.  25 large dataset high usage would be for any farm, unless the app servers and SQL servers (and web and WF, reporting, etc.) are also scaled out.  I typically propose that each group contribute what would be their equivalent environment (1 web, 1 app, 1 sql, for example) and that be joined into the farm.  that groups "data" databases (app and content) can be hosted on their own SQL server, and they bring a few additional resources to the party (BYOS = bring your own servers!).  You get the idea.

    It raises support concerns for patching, downtime, etc...all groups must comply, since only 1 set of servers. 

    As you can see, this is a complex and varied topic, but one worth discussing!

    Bottom line, Project Server was primarily designed to be a single PWA associated with a single business (unit).

    Hope this helps,

    Thanks, Eric S. Pcubed

    Thursday, January 16, 2014 6:27 AM