Controlling Project OData permissions for Apps and Reporting

Project Server 2013 changed a lot when it comes to both security and reporting and I’ve had a few customers asking about configuring user access to OData both for reporting and apps (such as Bulk Edit), fortunately Microsoft has some good guidance available on MSDN covering this topic;

When Project Server 2013 or Project Online is in Project permission mode, you can explicitly grant or deny access to the OData feed for specified Project Web App users. For example, on the Edit User page in Project Web App, expand the Global Permissions section, and then in the General section, select the Access Project Server Reporting Service check box in the Allow column.

In the default SharePoint permission mode, not all Project Web App users have access to the OData feed. Only users in the following groups have access: Portfolio Viewers, Portfolio Managers, and Administrators

Source: https://msdn.microsoft.com/en-us/library/office/jj163015.aspx

So basically if using Project Permission mode then this is what you’re after (preferably from Edit Group, not edit user as MSDN suggests):

perms

Unfortunately as above article goes on to mention there is no granularity to the access, it is all or nothing so if you’re looking for the kind of flexibility that the cubes previously gave then unfortunately you’re out of luck!

What has this got to do with Apps?

OData and the REST Api’s used in CSOM / JSOM are closely related, and in the case of Project Apps that need to work with project data such as Bulk Edit, then we need to also grant access to “Use Remote Interfaces” in SharePoint, to do that you will need to check the Permission Levels configuration: Site Settings -> Site Permissions -> Permission Levels -> Edit

perms2

By default the Project Managers SharePoint Group has this already, so if for example you want to grant all Project Managers in PWA permissions to run Bulk Edit, then all you need to do is add the Project Server Global reporting permission above, and combined with the SharePoint permissions they will be able to edit all project information.

What if I want Granularity?

I’m not good a saying “no it can’t be done” :) so if you require reporting granularity then the solution would be to use the SSIS reporting to create your own local SQL replica where your DBAs can apply whatever permissions are required. Reason 999 why that SSIS solution is key to any deployment in the future!

How about Apps? The picture is a little better but at the same time less simple, REST is security trimmed, so a PM will by default only be able to update / modify the project to which he / she has permissions, great. However as Apps can leverage both OData and REST endpoints which work differently it may result in inconsistencies depending on how the App was designed, for example:

Bulk Edit (at the time of writing) will allow Read Access to all Projects as a minimum, BUT will only allow updates to projects that to which the user has the rights.

If you’re wondering about any other app, then these simple rules apply:

  • Writing data always requires REST – allows security trimmed granularity.
  • Reading sometimes requires OData – does not allow granularity.

 

I expect in the future this to change, from experience project server security has been a moving target since the very beginning, so perhaps we’ll see more granularity in the future.

Hope that helps someone out there..

Share and Enjoy !

Shares

Problems installing Apps in SharePoint farm

Recently while working with a colleague we came across a few easy to miss issues when configuring the App Management Service in a SharePoint farm and while troubleshooting those issues found a lack of online resources on what turned out to be super-simple issues to resolve. (Hindsight is great)

Issue 1: ‘Let’s try this again’ error installing from the App Store

After installing and configuring the services, app domain and catalog as required, we could now open the SharePoint App Store, and choose an app to install, however the following message was displayed and the installation of any App would never begin.

Capture

Error text: Everything is fine, but we had a small problem getting your license. Please go back to the SharePoint Store to get this app again and you won’t be charged for it.

Everything’s fine hey? Looking at the ULS revealed that this was caused by security:

w3wp.exe (0x0CA0) 0x1DF4 SharePoint Foundation App Marketplace High An exception was thrown while trying to import the app license. AppName:Bulk Edit; Exception:System.UnauthorizedAccessException: You don’t have the right to perform this operation. at Microsoft.SharePoint.SPAppLicenseManager.ImportLicense …
w3wp.exe (0x0CA0) 0x1DF4 SharePoint Foundation App Marketplace High Post app license acquisition did not result in a successful license import. HugState:Retry

But how can this be, we’re testing using the Farm Admin account and so we have all permissions! It turns out, that is actually the problem! While I can’t say specifically where / what setting causes this, in a typical SharePoint 2013 install the Farm Admin (/ Installer account) is intentionally restricted in certain ways, my guess is something to do with local computer policies or such.

Solution

Login using a user account (who can be Site Collection Admin and all that)!

Capture2

Yay my favourite app!

Issue 2: App installs without issue but does not work

Now we have our first app installed, however running it doesn’t quite work out. Unfortunately this time we get very little indication of the problem, in fact with Bulk Edit the app will start and look good, except nothing works! The buttons do nothing, and no data is displayed! :(

Capture3

Similar issues happen with other apps installed and without looking at the F12 browser debug console the only indication that there is a problem is the top right hand corner site icon image which is just a little ‘x’.

If you do debug you will see an error like this:

SCRIPT5009: ‘RegisterSod’ is undefined

File: Default.aspx, Line: 14, Column: 32

Basically that tells me as a developer that something is seriously wrong in the farm (SP.js is missing which the whole JSOM api requires)!

Cause & Solution

Fortunately the solution was simple: SP.js was actually missing! Well not exactly, as it turns out while we had provisioned a single PWA site collection at /PWA in our Web App, we had not actually created a Default Root site collection at ‘/’. This configuration actually can break lots of things including SSRS and so this comes as no surprise really.

Simply creating a root site collection (using Blank or any template) fixed the issue and now all apps work as normal.

 

Other potential issues

While possible the topic of another rather long post, here’s a list of other things to check if you get permissions issues trying to install apps (sorry this is from memory so pls comment below if you think any of this has changed):

 

Hope that helps someone else out there!

Share and Enjoy !

Shares

Queue error creating project site or synchronizing site permissions

It’s not often these days I come across what seems to be a new Project Server 2010 error! Having said that, I would expect the same error to occur on either 2007 or 2013 as it relates to AD sync.

Anyway while working with a customer recently I came across the following issue that had started occurring for all new projects being created as well as on any attempt to synchronize the site permissions from Server Settings – Project Sites.

The effect of the error was that users cannot access any of the affected sites.

Notably though the AD sync was not experiencing any errors.

Error Messages

GeneralQueueJobFailed (26000) – SynchronizeMembershipForWssSite.SynchronizeMembershipForWssSiteMessage. Details: id=’26000′ name=’GeneralQueueJobFailed’ uid=’677df8c5-7409-4e20-8a05-e98395aa2af3′ JobUID=’3ca3af00-2e08-49aa-b693-f1314fc09b96′ ComputerName=’…’ GroupType=’SynchronizeMembershipForWssSite’ MessageType=’SynchronizeMembershipForWssSiteMessage’ MessageId=’1′ Stage=”

And in the ULS log we see some more details:

01/14/2014 15:43:07.23         Microsoft.Office.Project.Server (0x1694) 0x1558 SharePoint Foundation General 8kh7 High  Access denied.  You do not have permission to perform this action or access this resource.<nativehr>0x810200ce</nativehr><nativestack></nativestack>        237e539d-3835-4ec0-84d3-383759fccdb6

01/14/2014 15:43:07.23         Microsoft.Office.Project.Server (0x1694) 0x1AAC        Project Server Queu cf0l  Critical Standard Information:PSI Entry Point:   Project User: ….  Correlation Id: 237e539d-3835-4ec0-84d3-383759fccdb6  PWA Site URL: http://server/PWA  SSP Name: Project Server Service Application  PSError: GeneralQueueJobFailed (26000) A queue job has failed …

Investigation and Resolution

I’ve highlighted the interesting bits of the logs above, and on searching for this specific issue the only references relate to Search Service indicating one of the following causes:

  • The FarmAdmin account is not a local admin on the servers.
  • One or more AD accounts has been deleted and recreated with the same name.

So after speaking with the AD team it turns out the customer was in the middle of an Active Directory restructure (alarm bells start ringing!) and specifically about the same time when this issue was first reported the AD team had moved a group of PWA users into a new sub-domain in the same AD forest.

Reverting that change immediately corrected the isssue! Phew.

Not completely done yet though, as that change will need to be re-done in the near future further investigation was required. It turns out that the migration of accounts was being done in a staged manner, and specifically service accounts and admin accounts (including our Farm Admin) were NOT moved with the users, which is what caused our issue here.

 

If anyone else comes across this issue in the future let me know, as I have a strange feeling that this might be the first and last time this particular issue breaks a Project Server. :)

Share and Enjoy !

Shares

PSI in 2013: Unhandled Communication Fault occurred

I’ve had the fun task of shoe-horning some 2010 PSI projects into Project Server 2013 recently, and the good news is that as promised the PSI is still there just as we remember it!

One particular exception I kept seeing in my code immediately when using SharePoint Permissions Mode (ie a Default install) was the following:

Exception: Unhandled Communication Fault occurred

 

Which came with the unusually helpful accompanying ULS log errors;

06/11/2013 10:05:54.39        w3wp.exe 0x161C)  0x29B0        Project Server  General  ab3be   Monitorable    Unhandled exception in the process of routing the request to the app server: Target=https://host/PWA/_vti_bin/PSI/ProjectServer.svc, exception=[InvalidOperationException] Operation is not valid due to the current state of the object., StackTrace= at Microsoft.Office.Project.Server.WcfTrustedFacadeHelperMethods.
TryGetImpersonationContextInfo(String originalTargetUrl, OperationContext context, ImpersonationHeader& impersonationHeader) …

06/11/2013 10:05:54.39       w3wp.exe (0x161C)  0x29B0        Project Server  Security  aibp8     High        Impersonation is not supported in SharePoint permission mode

 

The second log is the giveaway, I won’t be forgetting that limitation again!

Share and Enjoy !

Shares

Customising Workspace Site Permissions with Code

A very frequent request I get is how to change the default permissions assigned by Project Server to Project Workspace Sites for all projects, unfortunately this is not something that is configurable in Project Server so the only option out of the box is to disable the permissions sync and manage those permissions manually. Of course if you don’t want Administrators to manage every user manually this is not an option.

This is made more annoying if you want PM’s to be able to manage the site, as by default they only have Contribute like access.

There are a few options that exist out there, notably this one; Adjust the Default Project Web Access Permission Levels, which uses a SharePoint timer job to manage the default Permission Levels. However I have had need for something simpler, and so recently for a customer I implemented the following:

 

Modifying Basic Site Permissions using Project Events:

My solution is by intent extremely simple, so simple that I will include the main piece of code below (as well as having the full solution attached), in short what this code does is the following:

On Publish of any project does the following;

  1. Retrieves the OWNER of the Project
  2. Retrieves the Workspace Site of the Project
  3. Adds the Owner to the default SharePoint role SPRoleType.Administrator

So as you can see it only updates one user’s permissions, however it would be trivial to update the code to do more based on the Project Team and other requirements.

Here is the bulk of the code:

if (wssData.ProjWssInfo.Count == 0)
{
  LogEventEntry(String.Format("No workspace site found for project: {0}", 
    projectData.Project.First().PROJ_NAME), EventLogEntryType.Warning);
}
else {
  // Open the SPSite and web
  using (SPSite pwsSite = new SPSite(wssData.ProjWssInfo[0].PROJECT_WORKSPACE_URL))
  {
    using (SPWeb pwsWeb = pwsSite.OpenWeb())
    {
      // Handle Null Email Address
      String ownerEmail;
      if (resourceData.Resources.First().IsWRES_EMAILNull()) ownerEmail = "";
      else ownerEmail = resourceData.Resources.First().WRES_EMAIL;

      // Add the new role assignment to the Owner
      SPRoleAssignment roleAssn = 
        new SPRoleAssignment(resourceData.Resources.First().WRES_ACCOUNT,
          ownerEmail,
          resourceData.Resources.First().RES_NAME,
          "Project Owner");
      SPRoleDefinition roleDefn = 
        pwsWeb.RoleDefinitions.GetByType(SPRoleType.Administrator);
      roleAssn.RoleDefinitionBindings.Add(roleDefn);

      pwsWeb.RoleAssignments.Add(roleAssn);
    }
  }
}

 

The code is bound to both OnPublished and OnSummaryPublished (to get the Save from PWA also), and ensures that the Owner will always have Admin rights, and if not all the PM has to do is republish.

Download only the WSP package here with – basic – instructions.

Download the full source package here.

Notes:

  • As an Event the solution runs under the security context of the Project Server Event Service account, and so this user must be a user in PWA with appropriate access, I use administrator however it could get by with less.
  • This completely ignores the WssSync jobs created by Project Server, as such some actions such as AD sync and group membership changes can apply permissions outside of typical Publish events. However in my experience with 2010 this will not remove existing SharePoint permissions (see one of my previous blogs on this).
  • The solution is built with Visual Studio 2010 and packaged as a WSP allowing for simple installation using typical SharePoint means.
  • The solution uses Project Server 2010 WCF methods to access the PSI, and so without modification it will not work on Project Server 2007.
  • The solution logs error information to the Event Log and not the ULS, this is because I’m lazy. However it means that on Windows Server 2008 if the user (Event Service Account) is not a local admin it will fail and log nothing.

 

Post comments with any questions or additions even, but please note that I can’t provide support for the standalone WSP package.

Share and Enjoy !

Shares