Unable to Open Project Site Access Denied Issue Project 2013 RRS feed

  • Question

  • This issue is happening to select projects and select project managers, they can view certain project sites but receive the error on other projects.  After some extensive testing it looks like if the PM is the owner of the project plan they are not getting added to any of the synced groups for the project site.  I can change the project owner to any another PM and it processes correctly and adds them to the PM synced group on the Project site.  As soon as I make the original PM the Project plan owner again the previous PM gets removed from the PM synced group and added to the Team member synced group, the way its supposed to work.  However the PM with the problem never gets added to any group.  I have to manually add them to the non-synced Owner group on the project site so they don't get removed from the synced PM group the next time the sync runs at midnight.

    As I stated it is happening on select project plans and select PMs.  I have tried replublishing the project plan via Project professional and the web and the results are the same.  If I create a new project plan and assign one of the PMs with the issue to the plan everything works correctly.  We noticed the issue a few weeks ago; most of the plans with the issue are several months to a year old so they were working correctly until recently.  They had also made PM owner changes prior to the issue on most of those plans and everything worked correctly.

    If anyone is experiencing this issue and has a fix please let me know.  I am trying not to open an MS support ticket if possible.

    Frank Miranda Florida Hospital MIS

    Thursday, September 25, 2014 7:30 PM

All replies

  • Hi Frank,

    One of the things to check is if you have any users that do not exist in AD as this may cause the permissions sync to fail for all or some of the users. An example that I have seen is: as one user did not exist in AD, the permissions were not synchronized even though there were no errors in the queue log, however, the users were not able to login into project server or access the project site.

    Some tests you can run are:

    1. inactivate and re-active the user
    2. to remove the user(s) that are experiencing the issue from the project managers group, save and add them back to the project manager group

    If in both cases the users are able to access the project sites and they are added to the corresponding synced groups, I would look for the users I mentioned above (do not exist in AD)

    I am assuming you are using Project Server 2013 in project server permission mode

    Hope this helps


    Friday, September 26, 2014 10:24 AM
  • Thank you for your reply Paul. 

    Yes we are running Project Server 2013 in project server permission mode.

    I've already checked several of the offending projects and verified that all the resources, including the PMs with issues, have valid AD accounts and are not local resources.  I have also removed and added all groups back to several of the users in question with no affect.

    The only step I hadn't tried was inactivate\reactivate the account which I just tried but it had no affect.  I opened the plan in Project Pro, published it and verified that the security permission sync processed.  I then check the Project Site and the problem persists.

    It only behaves this way with the current Project Plan owner.  I can change the owner to anyone else and it works correctly.  Very strange.

    Frank Miranda Florida Hospital MIS

    Friday, September 26, 2014 6:09 PM
  • Hi Frank,

    I would suggest checking the SharePoint logs then. Try to change the owner and changing back (as per your issue) and then look into the SharePoint logs and maybe more information has been captured there?


    Friday, September 26, 2014 9:02 PM
  • Thank you for the suggestion Paul.  I've already done extensive testing while watching the ULS logs live with a log viewer.  No errors are generated during publishing or the security sync tasks.  Everything processes correctly.  It's almost like the jobs to sync particular users are never generated therefore they are never processed.

    It's very difficult to troubleshoot the issue since no errors are ever shown in the logs.

    Frank Miranda Florida Hospital MIS

    Monday, September 29, 2014 3:14 PM
  • Hi Frank,

    Are you upgraded to the latest SP and CU?

    Hope this helps,

    Guillaume Rouyre, MBA, MCP, MCTS |

    Monday, September 29, 2014 3:25 PM
  • We are running SP1 with Aug 2013 CU.

    I've looked through all the subsequent CU's to see if this issue is resolved in any of them and I haven't seen it listed. I don't want to start randomly installing CU's as they tend to break things that aren't broken.

    If you know of a particular CU or Hotfix that addresses this specific issue I'd be happy to look into it.  As we are not having any other issues I am very hesitant to install a massive CU since Microsoft has a bad habit of using customers as their personal testing ground for CUs. 

    Frank Miranda Florida Hospital MIS

    Monday, September 29, 2014 4:04 PM
  • Hi Frank,

    Are you using only user groups to manage the permissions or do you manage the permissions for each user? I am just wondering if the user is assigned to a category or user groups that denies the access to a number of project/project sites? Maybe the category has only a limited number of projects and/or users and it is used to deny the access?


    Monday, September 29, 2014 6:39 PM
  • I checked that as well. All of the PMs, including the ones having issues, are members of the Project Managers group which has the My Organization category set.  My Organziation grants access to all projects to the Project Managers group.

    No permissions are denied, there are several that are unchecked, but none are denied.  The only permission that is globally unavailable is Manage Basic Project Security.  That permission has been unchecked under Project Web App Permissions so it is unavailable for everyone.  As a test I enabled it and performed further testing with no change so that is clearly not affecting the Site sync jobs.

    All resources, including PMs, are managed using groups no one is granted explicit rights within Project or at the SharePoint sites.  As a test I granted explicit permissions within project to one of the PMs with issues, it had no affect.

    Frank Miranda Florida Hospital MIS

    Monday, September 29, 2014 6:57 PM
  • Hi Frank,

    I would suggest opening a support case with Microsoft on this issue.

    Also, another thing you can try is to take a backup of the current project site and restore it using a different URL (Export and Import-SPWeb), point your project to the new site and see if that would help as maybe the project site template was corrupted at the time or something failed when the project site was provisioned


    Monday, September 29, 2014 9:35 PM
  • Hello Frank

    Add the project managers and past manager to the Build Team.  Once on the team and published, SharePoint should sync the permissions for accessing the project sites.


    Michael Wharton, MVP, MBA, PMP, MCT, MCTS, MCSD, MCSE+I, MCDBA
    Blog contains my field notes and SQL queries

    Tuesday, September 30, 2014 2:01 AM
  • Thank you for your response.  The PMs in question are already part of the build team, that is the first thing I checked as I know only members of the team get access by default to the site.  They even have tasks within the project plan.

    Frank Miranda Florida Hospital MIS

    Tuesday, September 30, 2014 2:30 PM
  • All the sites had been working correctly until 3 weeks ago.  Something happened and we started to notice the issue with certain PMs losing access to sites they'd had access to previously, sometimes for almost a year.

    We haven't made any updates or CUs to the servers other than the normal MS patch Tuesday updates.  Those patches are for the OS and do not make changes to any of the SharePoint or Project components.

    My biggest frustration is that I'm not seeing ANY errors anywhere, it's impossible to troubleshoot something when no errors are generated.

    Frank Miranda Florida Hospital MIS

    Tuesday, September 30, 2014 2:38 PM
  • Hi Frank,

    So far, you performed quite a lot of verifications and none of us could help you out.

    I'd say that your last chance would be to investigate deeper with your farm admin what updates have been performed on your farm just before the unexpected behavior appears.

    Than as Paul suggested, I'd open a support case with MS.

    Hope this helps,

    Guillaume Rouyre, MBA, MCP, MCTS |

    Tuesday, September 30, 2014 2:41 PM
  • All of the suggestions and comments have been helpful.  Yes, I have performed most of the testing already but there where a few that I hadn't thought of.

    I am the farm admin so I can say with confidence that other than monthly Windows updates no other updates pertaining to SharePoint or Project have been applied.

    At this point it sounds like my only choice is to open a ticket with MS support as it seems all the normal troubleshooting isn't producing results.

    Frank Miranda Florida Hospital MIS

    Tuesday, September 30, 2014 3:03 PM
  • I believe I've found the fix for this issue.  After opening a ticket with MS support and not getting anywhere with this issue I decided to do an in-depth review of all the Project and SharePoint 2013 CU's starting with December 2013 to September 2014.  To my amazement buried inside the July 2014 CU was a hotfix for this issue described almost word for word. (I will list all the relevant KB's at the end)  I contacted my support engineer inquiring about this hotfix and he stated it wasn't relevant because the "Synchronize Project Web App permissions to Project Site" was not failing or even generating any warnings in our Prod or Test environments.  I stated that is not always an indicator as ULS doesn't always catch all relevant errors.

    I informed him that I also found a second hotfix pertaining to the same issue released August 2014, apparently the first hotfix in July didn't totally resolve the issue and a second hotfix was released.  He was adamant that this would not resolve our issue and he requested or production databases because he was unable to replicate the issue in his test environment.  The reason, you may wonder, is because he was at a higher patch level that our farm.... Obviously!  His farm had the most current CU which included the hotfixes from July and August.  Apparently he didn't see the flaw in his logic.

    I decided to install the September CU on our test farm. Low and behold that fixed the problem, even though MS support stated the hotfix was not relevant to our issue.  I learned a long time ago to take MS support comments as suggestions instead of gospel truth, this isn't the first time they have confidently given me erroneous information.

    We are currently doing further testing to verify that this CU didn't break something else.  Unfortunately these rollups are not GA and Microsoft is very clear that you should only install them if the hotfixes pertain directly to your issue.

    Finding the hotfixes was a chore as Microsoft loves to create multiple KB's for the same thing and then nest (bury) them so you have to dig through four or five KB's to find the relevant fix.  I'll save you the trouble and list them below.

    Watch the September CU Webcast Brian Smith and team go into depth explaining why this issue has been happening and how they fixed it.

    Frank Miranda Florida Hospital MIS

    Monday, October 13, 2014 6:34 PM