Managing Project Web App Site Permissions in Project Online and Project Server 2013

 Introduction

Imagine that you arrive at work and decide to connect to your Project Web App (PWA) to check the status of your projects.  When you open PWA, everything is pink!  It wasn’t like this yesterday, so what happened?

PWA_1

In the example above, a very creative project manager decided to “Change the look” of PWA, not realizing that this change impacted all users.  By default, members of the Project Managers group have powerful permissions to customize the PWA site.  In our experience, most organizations do not want to grant these rights to any users who are not application administrators.  This article describes a technique for implementing these security settings for the case where Project Server Permissions mode is deployed.  This technique is applicable to both Project Online and on-premise Project Server 2013.

Goal

The objective is to ensure that all PWA users, with the exception of PWA administrators, have no design permissions to the PWA site.

PWA Permissions Changes for Project Online and Project Server 2013

In Project Server 2010, the default permissions for Project Managers allowed powerful editing rights to the PWA site, just as in Project Online/Project Server 2013.  The difference is that in 2010 the administrator could change the permission level for the Project Managers group, and the permissions would not change subsequently.  In the newer versions, the selection of Project Server Permissions mode enables a feature called “Project Web App Sync”.  By default, this feature is enabled and synchronizes members of Project Server security groups with the corresponding SharePoint groups.  As one may see in the view below, there is a SharePoint group called “Project Managers (Project Web App Synchronized)” that has permission level “Project Managers (Microsoft Project Web App)”.  The Project Web App Sync function in Project Online and Project Server 2013 has the effect of automatically adding users to this SharePoint group when they are added to the Project Server “Project Managers” security group through Server Settings => Manage Groups.  The upside of this feature is that the administrator does not have to manually add users to the SharePoint group so that they can access PWA.  The downside is that even if you alter the permissions, they will revert back to the defaults.

PWA_2

Default Group Permissions

Let’s have a look at the default Project Managers (Project Web App Synchronized) permissions for the PWA site collection.  We should also be aware that, by default, the Business Intelligence Center inherits permissions from the PWA site.  Navigate to PWA, then click on the Settings (Gear) icon and select Site settings.

PWA_3

In the ribbon, select Permission Levels.

PWA_4

Click on Project Managers (Microsoft Project Web App) to view this permission level.

PWA_5

Note that by default members have Site Permissions such as Manage Permissions, Add and Customize Pages, Apply Themes and Borders, Apply Style Sheets, and Create Groups.  Also, all List Permissions are enabled, including Delete Items.

PWA_6

PWA_7

Solution

To ensure that “creative” project managers don’t inadvertently wreak havoc in PWA, we need to create a new SharePoint group with more benign permissions.  We will then add PWA users to this new group, and remove them from the old ones.

Create New Permission Level and Group

Best practice is to leave the out of the box groups and permission levels intact.  We will create a new permission level by copying one that is close to the desired result.  In this case, I will copy the permission level Contribute, but I will uncheck two List Permissions: Delete Items and Delete Versions.

From the Permissions Levels page click on the Contribute permission level.  Scroll to the bottom of the page and click Copy Permission Level.

PWA_8

Enter the Name and Description for the new Permission Level, disable (uncheck) Delete Items and Delete Versions, and then Save.

PWA_9

Next, create a SharePoint group and apply the new permission level to it.  From the Site Settings | Site Permissions page, click on Create Group.

PWA_10

Fill in the Name and About Me (Description), then scroll to the bottom and check the permission level you just created.  Save the changes.

PWA_11

PWA_12

Disable Project Web App Sync

By default, adding a user to a Project Server security group, such as Project Managers, will also add them to the corresponding SharePoint group on the PWA site.  To prevent this automatic synchronization we must disable it.  This function may be accessed through PWA Server Settings, in the Security section.  Uncheck the box next to Enable Project Web App Sync and save.  I don’t advocate disabling the Project Site Sync process, as this would require manually managing permissions on all project sites.

PWA_13

PWA_14

 

Modify Group Membership

The last step is to update the SharePoint group membership.  First, add all PWA users to the newly created SharePoint group.  The most efficient way to do this is by utilizing an Active Directory (AD) group that contains all the users who need PWA access.  Add this AD group to the PWA SharePoint group.

PWA_15

PWA_16

After you have added all the users (your AD group) to the new SharePoint group, you should remove all users from the SharePoint groups Project Mangers (Project Web App Synchronized) and Team Members (Project Web App Synchronized).

 

Conclusion and Recommendation

Utilizing the techniques described in this article will provide greater control over your PWA user permissions and ensure that your PWA site theme does not change unexpectedly!  Note that PWA security now has two components to manage: SharePoint and Project Server.  As an administrator you must make sure that your PWA users are assigned to both the correct Project Server security group and the correct SharePoint security group.  As with any security change such as this one, it is best practice to perform validation in a non-production environment first.  The advantages and disadvantages of the Project Web App Sync are summarized in the table below.

PWA_17

 

About Sensei Project Solutions
Sensei Project Solutions is a Microsoft Partner specializing in Project and Portfolio Management (PPM) deployments with Microsoft Project and Project Server on the SharePoint platform. With extensive experience on hundreds of PPM deployments and with thousands of users trained, Sensei Project Solutions brings a process-focused approach; and support for industry standards and best practices to all engagements. We offer a complete set of services to help an organization make their Microsoft PPM deployment successful, including full implementation and support services, training, as well as pre-configured solutions and report packs. info@senseiprojectsolutions.com


Related Content

Articles:
Closing Out a Project Schedule in PWA
Site Creation Settings in Project 2013 and Project 2016


Avatar photo
Written by Terry Kneeburg
Principal Consultant. Terry has more than 25 years combined experience in product development, project management, and consulting. He has been working with the Microsoft Project Server platform since 2004. At that time he led his mobile phone development organization in the deployment of EPM. Terry is passionate about helping clients achieve success in managing their project portfolios, delivering to companies in a variety of industries including Healthcare, Transportation, State and Local Government, Energy, Technology, Insurance, and Pharmaceuticals. He has conducted training classes for project managers, administrators, portfolio managers, and team members.
Share This Post
15 Comments
  1. Excellent article, Terry!

  2. Avatar photo

    Thank you, Dale!

  3. Avatar photo

    Daniele, the article is about permissions to the PWA site, and assumes that PWA lists and libraries are set to inherit permissions. If you have broken permissions inheritance, then you are already manually controlling permission levels and may need to review those.

    The project site permission sync is a separate setting (Enable Project Site Sync), which I recommend you enable so that you don’t have to manually manage permissions on every project site. With Project Site Sync enabled, the Project Manager and Team Members automatically get access to the appropriate project sites.

  4. Avatar photo

    Joseph, I don’t recall seeing this issue in any version of Project Server. Have you checked to make sure the projects are being published after the task updates are approved?

  5. Can permissions settings be different for PWAs in project online. One PWA with SharePoint and the other PWA with Project Server permissions?

  6. Avatar photo

    Jerry, yes you can do this in Project Online. Each PWA instance’s permission mode can be set independently of the others.

  7. Thank you Terry.

  8. Avatar photo

    Phil, the only way to do what you want is to disable Project Site Sync (Server Settings, Manage User Sync Settings). Please be aware that if you do this you will have to manually manage permissions on every project site as users will no longer be automatically granted access. Hope this helps.

  9. Avatar photo

    Luis, you may need to add each user individually to the SharePoint group. I have also seen the behavior you describe.

  10. Nice one Terry. 🙂

    One point. The Project Details Pages (PDP) library has unique permissions and this SP group needs to be added to it as well. Otherwise user gets a Site Permission Share Error.

  11. Avatar photo

    Daniel, the permissions changes to the Project Managers (Project Web App Synchronized) will be overwritten, so that’s why you must create a new group. It may appear initially that you are able to adjust the permissions, but they will revert. Hope this helps.

  12. How do you address the individual project sites and permissions based upon the issues in this article

  13. Hi Terry,
    I followed the recommended steps.
    1. Created a Permission level called “PWA Access” (copied from Contribute) – Removed the “Delete Items” and “Delete Versions”.
    2. Created a SharePoint Group called “PWA Users” (selected the “PWA Access”).
    3. Unchecked the “Enable Project Web App Sync” option.
    4. Modified the “PWA Users” group membership adding the AD group for ProjMgrs and TeamMembers.
    5. I then removed all users from the SharePoint groups Project Mangers (Project Web App Synchronized) and Team Members (Project Web App Synchronized)

    Presto! Project Managers and Team Members were limited and no longer had “Change The Look” option. However, we experienced an unexpected behavior. Top-Level Global Navigation disappeared for Project Managers and Team Members. The top navigation had links to My Work, My Resources, and My Portfolio.

    We have approximately 200 users in PWA Online. I have someone who keeps using the “Changing the Look” of PWA (the background, look and feel) by going to the cog and hitting “Change the look”. It changes it for all users. How can I lock this down and how do we do this and keep the top-level global menu?

    I ended up having to backout the change to restore the top-level navigation.
    Thank you – Noel

Leave a Reply