locked
Default Project Site Permissions Groups not added for Sites on Publish in Project Server 2013 RRS feed

  • Question

  • Config: Project Server 2013 July CU with migrated data, On-Premise, Project Permissions Mode

    This is a similar issue to the Forums post found here:

    https://social.technet.microsoft.com/Forums/projectserver/en-US/cbf74b4a-cd1d-4ff0-8135-a79fc9d40837/project-server-default-groups-when-we-create-new-project-site?forum=projserv2010setup

    The issue is not identical and I’m hoping someone can help me figure this out.  Let me break this down.  I have done a lot of troubleshooting, so please read the entirety of the post before jumping in with suggestions.

    We have two PWA instances.  The first has migrated data from Project 2010, the second has a separate Web Application and no migrated data. 

    We have ensured the “Manage User Sync” settings, all Group/Category permissions, and Project Site Provisioning Settings are identical between the two instances.

    The PWA instance with no migrated data works as expected – when you publish a new project from the project client, resources are given permissions to the site as expected.

    In the migrated PWA instance, when you publish a new project from the Project Client (or from PWA), the Project Server default groups are not added to the site. (the ones marked “Project Web App Synchronized”) 

    If you force sync from the “Connected SharePoint Sites” screen, the groups are added with the correct members/owners etc. in the groups.  Existing project sites still have the same permissions they did before migration.   If you make changes to the Project Team for existing projects, even the “force sync” option in “Connected SharePoint Sites” does not update the site permissions.

    When we first tried the sync, the “Connected SharePoint Sites” sync would add the wrong users to the groups. (similar to the issue in the linked forum post above) We toggled from “SharePoint Permissions Mode” and back to “Project Permissions Mode” and reconfigured the groups and categories to fix this, but the other issue remains.

    The “Enterprise Project Features” show as active for existing sites and new sites that are created.  We have tried deactivating and reactivating these.  We have also tried creating a new site from the default site template and our own custom template. (rebuilt in 2013, of course)

    This happens for any Enterprise Project Type, and for both sites that are created as “SharePoint Task Lists Projects” and those which are created as full project sites.  There are no errors in the queue, but the Sychronization jobs are not being triggered.

    At this point, our Project Site permissions structure is not working as expected with migrated data.  It is behaving as though it is still in "SharePoint Permissions Mode", even though the settings for "Project Permissions Mode" are present and I set it to the correct type more than once.   Has anyone else seen this issue?  Any more thoughts on how we might get it to work?  Without project specific permissions on our sites, an upgrade to Project Server 2013 may not be possible for our company.


    Elli J Project Solutions Specialist Blog: http://projectserverpants.wordpress.com/



    Wednesday, November 5, 2014 8:12 PM

Answers

  • I can see that everyone is dying to know the answer...no, but really, it's actually quite interesting.

    You know that handy dandy little "don't sync sites" checkbox in 2007 and 2010?

     

    I have a post about why you should uncheck it before performing certain resource updates here:

    http://projectserverpants.wordpress.com/2013/02/21/resource-upkeep-in-project-server-101/

    MS and I worked together to figure this one out - if that box is unchcked when you copy your databases for 2013 migration, you will experience the issue outlined above.  Super fun, right?  Hopefully they will come up with a solution (an addition to the migration scripts that checks the related value, a hotfix that switches it after the fact, maybe change the code to stop looking for obsolete value you can't change?) but until then, make sure that box is checked before you migrate your data!  

    We were able to identify the value in the DB and update it manually, but I'll leave it to them to share the specific info.


    Elli J Project Solutions Specialist Blog: http://projectserverpants.wordpress.com/

    Monday, December 1, 2014 5:47 PM