Manually adding users to Project Workspace / Project Site in #ProjectServer #PS2010 #PS2007 #EPM

July 11, 2011 at 11:41 am | Posted in Administration, Functionality | 9 Comments
Tags: , , ,

This post will detail the errors seen when trying to add or edit items in a Project Site / Project Workspace in Project Server when adding users manually to a Project Site when they don’t have the correct permission in Project Server. For the purpose of this guide I will base this on Project Server 2010 but the same applies for Project Server 2007.

A bit on the background information to start with so that it makes it clear later on in the post why you see these errors. Project Server has its own permission model that works differently to the SharePoint permission model. Users are added to Project Server via the PWA > Server Settings > Manage Users interface and not the SharePoint Site Actions > Site Permissions interface. This is because users will be added to the PWA site based on their Project Server permissions, to an extent the same can be said for the Project Sites. Although Project Sites appear and function the same as a normal SharePoint site, certain lists / document libraries work very differently to standard SharePoint lists / libraries. The Project Documents library, Risks list and Issues list link back to Project Server so therefore when editing / adding items, firstly the SharePoint permissions will be checked, then the Project Server permissions will be checked. If the user doesn’t have the correct permissions in Project Server, then they will see errors, even if they have full control on the Project Site. Each error is shown below.

In this example I have added a user directly to the Project Site, the user has Full Control of this Project Site, also this user does not have any access to PWA.

Project Documents:

When adding a document to the Project Documents library the user will see this error pop up once they click OK to add the document:

image

When they click, “Go back to Site” they will see that document has still been uploaded:

image

The error is thrown when the Project Server permissions are validated. The error below can be seen in the SharePoint ULS logs:

System.Web.Services.Protocols.SoapException: ProjectServerError(s) LastError=GeneralSecurityAccessDenied Instructions: Pass this into PSClientError constructore to access all error information    at Microsoft.Office.Project.Server.WebServiceProxy.Security.CheckUserProjectPermission(Guid projectUid, Guid categoryPermissionUid)     at Microsoft.Office.Project.PWA.CustomFieldWebControls.CustomPWALinkField.OnLoad(EventArgs e) 

As you can see from the error above, it fails when checking the Custom PWA Link field as this is used to link the Document back to a task in the Project. As this user doesn’t have access to Project Server the error is thrown.

Risks and Issues lists:

Users will not be able to create an item on the risks or issues list if they do not have the correct permissions in Project Server, they will see the error below when clicking New Item:

image

The error below can be seen in the SharePoint ULS logs:

System.Web.Services.Protocols.SoapException: ProjectServerError(s) LastError=GeneralSecurityAccessDenied Instructions: Pass this into PSClientError constructore to access all error information    at Microsoft.Office.Project.Server.WebServiceProxy.Security.CheckUserProjectPermission(Guid projectUid, Guid categoryPermissionUid)     at Microsoft.Office.Project.PWA.CustomFieldWebControls.CustomPWALinkField.OnLoad(EventArgs e)    

As a minimum, users will need permission in Project Server to use these lists, I would also recommend that you let Project Server control the users permissions to the Project Sites. To do this check the box “…automatically synchronize Project Web App users with Project Sites when they are created…”, on the PWA > Server Settings > Project Site Provisioning Settings page.

image

This will synch the users to the Project Site when the Project is published, it will add users to the Project Sites based on their Project Server permissions and therefore less of an administration overhead. The permission the users get on the Project Site can be seen below:

  • Project managers who have published a project or who have Save Project permissions on a project are added to the Project Managers (Microsoft Project Server) site group.
  • Team members with assignments in a project are added to the Team members (Microsoft Project Server) site group.
  • Other Project Server users who have View Project Site permission on a project are added to the Readers (Microsoft Project Server) site group.

Hopefully that explains why you see these errors on the Project Sites.

Advertisements

9 Comments »

RSS feed for comments on this post. TrackBack URI

  1. Hi

    Thank you for the above article. It is exactly the same problem i am facing, and I can understand / could guess the root cause of the problem.

    However, could you please clarify on the following :

    Project managers who have published a project or who have Save Project permissions on a project are added to the Project Managers (Microsoft Project Server) site group.

    Team members with assignments in a project are added to the Team members (Microsoft Project Server) site group.

    Other Project Server users who have View Project Site permission on a project are added to the Readers (Microsoft Project Server) site group.

    My Reservations for using this approach is, how does the Project server differentiate the Team members of one Project from the Other? since it appears to be using the same “Team member” group for each of the project site thus enabling the access for all the project teams to each of the project sites?

    Same goes for the other group.

    I would wish to believe that, the Project server is intelligent enough to add another layer of somewhat dynamic authentication / resolution , i.e. while a person access a Project site the server checks if the user is part of the resource on that project or not, albeit being part of global “Team Members”…. if it works this way, i am happy to synchronize permissions.

    Please let me know of your thoughts..

    Thank you

    Amir

    • Hi Amir,

      The Team members (Microsoft Project Server) group is local to that Project Site, so only Project team members (users added to the project team) with assignments on that project plan will be added to the Team members (Microsoft Project Server) group on that one site.

      Hope that helps
      Paul

  2. Hi Paul,
    This is a good overview. A couple of points that I’m still foggy on;
    1) even if the check box to auto-sync is not checked, will a user still need to have the correct permissions in PWA? We’re wanting users that don’t use PWA to be able to access docuements and such in the workspace. We were able to do this in ’07 but are running into issues in ’10.
    2) Similiar to Amir’s questions above, does a “Project Manager” (someone with save project permissions) need to be on the project team to auto sync?
    Thank you for your time,
    Kevin R Bittinger

    • Hi Kevin,
      Thanks for the feedback. Answers below:
      1. Even with auto sync disabled the users will still need the correct permissions in Project Server. If you want users to access documents on the Project Sites that do not have access to Project Server I would create a new custom document library rather than use the Project Documents library.
      2. For a user to appear in the Project Managers project site group the user does not need to be on the project team. The users who have published a project or who have Save Project permissions on a project are added to this group.

      Thanks
      Paul

  3. We are experiencing this same error message in the ULS logs whenever someone tries to View or Edit Properties on a Project Document after the Properties have been edited one time.

    The documents were migrated as part of the Project Site when moving from our old 2007 Project Server onto our new 2010 Project Server.

    The Links property of the document was pointing at the old URL and ProjectUID prior to touching the properties. Upon saving from the Edit Properties dialog, the Links property changes to point at the new URL and Project UID. But then users who try to View Properties after that only get a SharePoint runtime error message and ULS shows the CustomPWALinksField.OnLoad error you show above.

    Any insights?

  4. Never mind – we discovered a Deny permission on Project Server after peeling back the onion a bit further. This posting was a great clue though.

    • Glad to hear you got the issue sorted.

      Paul

  5. Hello Paul,

    Many thanks! Very helpful. If we were LinkedIn I would give you an endorsement right away!

    • thank you 🙂


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

Blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: