Project Server and Synchronizing Users to Project Sites

This blog post looks at some slight behavior differences between Project Server 2010 and Project Server 2013 regarding user synchronization to project sites.  One key part of this change should be taken into account when migrating – as there is one 2010 setting that no longer has UI to change it – and if it is disabled before migration it cannot be turned on again in 2013.  I’ll get into details of that setting and a workaround later, but first I will set the scene for how the settings and behavior have evolved. 

In Project Server 2010 we had a checkbox in Server Settings, Project Site Provisioning Settings for Project Site Permissions – labeled “Check to automatically synchronize Project Web App users with Project Sites when they are created, when project managers publish projects, and when user permissions change in Project Server. When the check box is cleared, Project Server users are never synchronized with Project Sites.”:


In my example it is unchecked – this is reflected in the published database in the MSP_WEB_ADMIN table in the WADMIN_AUTO_ADD_USER_TO_SUBWEB column – which has 0 when unchecked and 1 when checked.


If I create a new project and add some resources and then publish – I see just the following jobs in the queue and I don’t see any permissions set for the resources in my plan.

Project Save from Project Professional  
Start Workflow Success
Project Publish Notifications
Project Publish Success
Reporting (Project Publish)
Project Site Create
Reporting (Project Sync)
Reporting (Enterprise Project Type and Workflow Information Sync)

If I go to Server Settings, Project Sites and select the project, then click Synchronize in the header:


then I see a couple of queue jobs executed:

Project Site Membership Synchronization
Reporting (Project Sync)

However, I still do not see my expected users added to my site.  Only when I check the checkbox in the first screenshot, and then click Synchronize on the Project Sites page do I see my users get added.  So this checkbox controls the addition of users to my subweb.

There are some other settings in 2010 that had no UI, but could be set programmatically (or by editing the database and were documented in the article and the table was the same MSP_WEB_ADMIN, but this time the column is WADMIN_USER_SYNC_SETTING:


As you can see, mine is set to 0, which means all synchronizations are enabled.  If I change this to 2, this still has no effect on the site synchronization as long as the checkbox is checked.  Sync happens both on site creation and also using the Synchronize button.

Now lets jump forward to 2013.  The dialog in my first screenshot has no equivalent in 2013, and in a new installation the database setting for WADMIN_AUTO_ADD_USER_TO_SUBWEB  is defaulted to 1.  The WADMIN_USER_SYNC_SETTING now has some UI – under Server Settings, Project Permission Sync Settings.  I should add that this only appears when you are using Project Server Permissions mode.  The dialog looks like this:  , and if you are interested in the behind the scenes activity in the pub.MSP_WEB_ADMIN table the values for :


If you are interested in the behind the scenes activity in the pub.MSP_WEB_ADMIN table the values for WADMIN_USER_SYNC_SETTING follow the numbers documented at like so:

Enabled                            Value=0.       Enable all synchronizations.

DisablePWA                     Value=1.       Disable synchronization with Project Web App.

DisablePWS                     Value=2.       Disable synchronization with project sites.

DisableEmailSync             Value=3.       Disable email synchronization.

DisableAll                         Value=4.       Disable all synchronizations.

DisableVisbilityProjects    Value=8.       Disable Visibility projects synchronization only.

DisableEverything            Value = 255. Disable everything.

Unchecking Enable Project Site Sync will give me a value of 10 in the database – as it disables project site sync and sync with SharePoint Task List Project (or visibility projects as they are sometimes called).

With these settings, which are equivalent to the ones described in the final 2010 test above  (DB value was 2 rather than 10 as visibility projects didn’t exist),  if I create a new project and publish, and/or if I click Synchronize on the Connected SharePoint Sites page I DO NOT see any synchronize queue jobs and NO users are added to my site.  In 2013 there is no longer a single click option to synchronize sites if I have used the new UI in front of the WADMIN_USER_SYNC_SETTING values to turn off site sync.

The other gotcha, and the piece that got me looking deeper into this topic in the first place is the issue I alluded to in the intro.  What if I am using 2010 and have that box unchecked – then migrate to 2013?  In this case it can leave you confused as to why your users aren’t able to access their sites after you create a project.  The behavior you will see is that on initial publish of a project, assuming you create a site, then even if you have ‘Enable Project Site Sync’ enabled you will still not see your users added – and neither will you see the expected additional ‘Project Web App Synchronized’ groups – you will just see the default members, Owners and Visitors if you go to Site Settings, Site Permissions:


If you click on the Synchronize option you will see things put right – and the new groups will get added and your users added.  So we still take notice of the old DB setting which carried over from migration – but only on the project publish.


This last piece is certainly a bug – not sure at this point how it will be addressed, but we will be updating our upgrade documents to suggest checking that box before migration.  If you have migrated from 2010 (or earlier!) and are not seeing permissions on sites set as expected when you publish a plan then take a look at the database (change ProjectWebApp to the name of your database),


should return a 1.  If it shows a zero then you could run

Update [ProjectWebApp_PPM].[pub].[MSP_WEB_ADMIN]

This will show (1 rows(s) affected) as it resets the value.

We are reviewing this behavior change – so I will update if we do make any changes here.

For Project Online this last piece can never be an issue – as it will always be a 1 – and Project Online now has new defaults for the other Project Permissions Sync Settings – so by default we don’t sync anything.  And like 2013, if you have this sync turned off then Synchronize in Connected SharePoint Sites does nothing.

Comments (28)

  1. anonymouscommenter says:

    Brian, thank you for this very detailed explanation.
    I would like to add that currently there is a bug with Project Server 2013 that blocks Project Site Permissions synchronization alltogether. After installation of September 2014 CU for Project Server and SharePoint Server, the Project Site Permissions sync
    fails. Queue jobs are created but the job ‘Prepare Project Web App Permission Synchronization For Projects’ fails for all existing Project Sites, due to a change in behavior in the September 2014 CU.
    Microsoft is aware of this issue, but no date has been communicated when it will be fixed.

  2. anonymouscommenter says:

    Hi All,


    Could you provide more information about this issue? We are suffering the same behaviour after applying last CU’s.

    All existing project sites (those that were created before the update) are not found when ‘Prepare Project Web App Permission Synchronization For Projects’ fires. With the new ones (those that were created after the update), everything works fine.

    You said that "Microsoft is aware of this issue, but no date has been communicated when it will be fixed". Where did you get this information?

    @Brian Smith: Do you know anything about this issue?

    Kind regards,

  3. anonymouscommenter says:

    Hi again,

    Based on log files, what is happening (on projects created before the update) is that Project Server tries to open the project site using the url http://server/myprojectsite instead of http://server/pwa/myprojectsite (note that /pwa is missing).

    I’ve analyzed the assembly ‘Microsoft.Office.Project.Server.dll’ (15.0.4667.1000 – Nov 2014 CU) in order to get more details. I found some differences with the SP1 version at ‘Microsoft.Office.Project.Server.BusinessLayer.PSPermissionSynchronizer.SynchronizeProjectSites(…)’.

    I can’t figure how is possible that this code works with new project sites but not with older ones.

  4. anonymouscommenter says:

    @Ricardo Herrera:
    I have logged a support ticket with microsoft about this issue.
    If possible for you, I can only advice you to also open a support case with Microsoft. The more people that complain about this issue, the earlier it will be fixed.
    You analysis of the ULS log files is correct. After the September 2014 CU, the URL used for accessing the project sites is missing a key part.

    Also note that for new project, you can still have this issue if you create the project site from ‘PWA Settings -> Connected SharePoint Sites’ instead of automatic creation.

    Based on my analysis, the root cause of this issue is that with the September 2014 CU, Microsoft changed the way the project site URL is saved in order to implement a new feature that allows project sites to be created in different site collections (already
    available in Project Online).

  5. anonymouscommenter says:

    @Hans: Thanks for reply!

    Sorry, but our customer can’t open a ticket (:() I hope that Microsoft fixes this issue soon. Maybe in a January CU released as a Christmas gift. By the moment, we will try to find a workaround…

    Kind regards,

  6. Hi Hans, Ricardo, we do have a fix coming through and it will be available in the February CU. I will be doing more investigation on this as the original repro only appeared to be a problem when a project site was a subsite of another site – so http://server/pwa/project1/project2
    for example. Looking at the test cases for this fix it looks good for all combinations but I hadn’t personally seen this fail for normal sites so thanks for bringing this to our attention. The bug was certainly in the code parsing the site – so I will double
    check the fix resolves the issue for both new and existing sites.
    Best regards,

  7. Hans.H says:

    Hi Brian, Thank you for the information.
    About the repro: it’s not only a problem for subsites, but also when you provision the project sites in a separate site collection. If you want I can send you the full repro steps.

  8. anonymouscommenter says:

    Hi, I would like to confirm Hans observation that its not only happening for sub sites, any project site provisioned other than under root site collection is causing this issue. Until the official fix to come, resolution is to re-configure your project
    sites to be created under root site. (credit goes to my colleague Peter who has identified this resolution)

  9. anonymouscommenter says:

    I was just about to open a case on this issue and want to chime in to say my environment was patched from SP1+April CU to December and I’m having the sync issues as well. In the logs I can also see that it is looking for the wrong URL (in my case, http:\mydomainprojectname
    instead of http:\mydomainpwaprojectname. We don’t have any subsites of Project sites in our farm.

    Do you know if this fix is still scheduled for Feb?


  10. anonymouscommenter says:

    I opened a case on this linking back to this blog, but there was no mention of any existing bugs similar to this one in my call. In my instance, we found that the WSTS_SERVER_UID was wrong on projects receiving the permission sync error. The WSTS_SERVER_UID
    matched the ID of the root site instead of the ID of the PWA site. We manually switched the WSTS_SERVER_UID of a failing project to the "correct" UID and then permission sync worked.

    We then tried to use Bulk Site Update to fix the rest but the job actually went and changed ALL of the project sites’ WSTS_SERVER_UIDs to the incorrect UID of the root site collection instead of the PWA one. To get past that, we deleted the root site from the
    database, reran Bulk Site Update, and this time it set WSTS_SERVER_UID correctly for all of my Project Sites, and permissions sync worked correctly for those project sites.

    The thing I’m unsure of is if permissions sync was always failing prior to us updating to the December CUs and we just never knew about it, or if it always worked regardless of that WSTS_SERVER_UID until some change included in a CU we didn’t originally have
    installed. I also don’t know why project sites created prior to us installing the December CU were pulling the wrong WSTS_SERVER_UID, nor do I understand why the fix required the deletion of the root site.

    All that said – Brian – is this similar to any notes for the upcoming fix you mention? I’m trying to figure out how best to manage my case.

  11. anonymouscommenter says:

    Aaron I am experiencing the same issue and would like to know exactly what steps you performed in order to correct this issue. This issue has caused me to become more familiar with PowerShell and SharePoint than I really wanted. LOL Feel free to contact
    me directly


  12. anonymouscommenter says:

    Are you familiar with the steps that Aaron followed to resolve his issue? I would really like to know what they were in hopes of solving my issue. See my comment above

  13. anonymouscommenter says:

    We are experiencing the same issues and are in the process of installing the Feb CU. Anyway this may be related but I am not sure. We are seeing an issue when the "Project Owner" is changed. When we change the project owner the project site owner is not
    changed. This is really an issue when someone moves on and they can’t be here to add a new owner. Even an admin can’t add a new owner and must put people outside of a group.

  14. anonymouscommenter says:

    I thought I understood what Aaron was doing to resolve the site sync error. I decide to see if my thought process was correct.

    So here is what I did using a standalone site that does not get the error.
    1. Used GET-SPDatabase to get a list of all databases.
    2. Opened SQl mgt Studio
    PWA Database

    3. I then checked the list obtained in step 1 and found no match. My though being that the GUID should match one of the databases in step 1

    My question is what database do I use and how do I find it’s GUID?

  15. anonymouscommenter says:

    The Microsoft engineer I was working with did not think my issue was the same as the one here even though the ULS logs and queue error were pretty much the same, I think because the KB for the CU says basically what Brian says, which is that it’s more
    of an issue with a project subsite of a project site, vs my issue which is just a regular project site, not a subsite. I guess. I went ahead with a SQL fix vs installing the Feb CUs. I’m curious though if you’re seeing the same thing as me.

    Here are the steps I use to find project sites with the wrong ID. Against the DB containing your /PWA site collection, run this query):

    select * from webs where fullurl = ‘PWA’

    and then you can run this one (assuming you have a root site collection):

    select * from webs where fullurl = ”

    Note the SiteID for PWA and for the root site. This SiteID for PWA should match WSTS_SERVER_UID which is a value for each project site within the ProjectWebApp database. In my case, the SiteID of the root site was what a bunch of project sites had for WSTS_SERVER_UID
    which is incorrect.

    Now to check those WSTS_SERVER_UIDs, run this query against your ProjectWebApp database. So let’s say I have a project named "Aaron Project" and it’s one that gets the permissions sync error, I would run this query:

    select PROJ_NAME, WPROJ_STS_SUBWEB_NAME,WSTS_SERVER_UID,wproj_issue_list_name,WPROJ_STS_SUBWEB_NAME from pub.msp_projects where proj_name = ‘Aaron Project’

    When you run that query, see if the column WSTS_SERVER_UID matches the SiteID of your PWA site collection. In my case, I had a ton of project sites where the WSTS_SERVER_UID matched the SiteID of the root site instead of the PWA site, and every one of those
    sites was experiencing this permissions sync issue. I have no idea why project sites picked up the wrong UID but I do know that most of my newer ones generated in the last few months have the correct UID.

    If this is the issue you have, like me, the fix is pretty simple. You just need to update the WSTS_SERVER_UID to the correct value. I take no responsibility for this next part! Please back up your DBs before you do any of this. 🙂
    Update pub.msp_projects set WSTS_SERVER_UID = ‘CORRECT_UID_HERE’ where Proj_Name = ‘Aaron Project’

    If you can now do a permissions sync without issue (via Connected Sites or just a publish from the client) you should be good to go.

    I’m still curious what the Feb CU is doing to fix the similar issue..

  16. anonymouscommenter says:

    Thanks Aaron for the reply

    Not being a DBA or SharePoint person I am not sure what you mean by:
    select * from webs where fullurl = ‘PWA’
    select * from webs where fullurl = ”

    Could you write the exact SQL select statement you use? That way I can apply it to my environment.?

  17. anonymouscommenter says:

    Those are the exact query you would run against your content database. The first one will pull information for the PWA site collection. The 2nd one will pull information from your root site collection. Or, if you just want to list ALL of your sites, you
    would do this:

    select * from webs

  18. anonymouscommenter says:

    OK this has become a quest. It is forcing me to learn more about SQL, SharePoint and PowerShell then I wanted to know. LOL
    Below are the sites


    When I use the first query I get nothing. Shouldn’t the PWA site show up?

    When I perform the 2nd query I do get two of the three.
    ED716FEF-27F3-4F4F-A719-65E7E5202868 A75DF6F0-3045-4592-9462-1762A9917C69 my/personal/sharktracker
    9FF3063F-8F09-4C69-AF6F-E473F0D57169 BD6BF01F-6D20-4519-A2D5-F45F23AC4A2A my

    When I list the WADMIN_CURRENT_STS_Server I get the following.

    So what am I doing wrong?

  19. anonymouscommenter says:

    Is your PWA site in a different content database? If you run select * from webs and PWA isn’t there, I would guess it’s in a different DB maybe.

  20. anonymouscommenter says:

    Here’s a thread with other people having this issue (and also referencing this blog). One guy says the FebCU isn’t fixing the issue with existing sites. Can’t confirm this myself as we fixed the UID in SQL.

  21. anonymouscommenter says:

    Brian – a simple question compared to some of the questions/observations posted by others. I noticed in the queue that there is a job Project Site Create that appears to show each time a project is published. Am I being a pedant, consumed by existential
    angst or missing something? Surely once a site has been created on initial publication it exists and as such does not need to be created again – what does Project Site Create actually mean?

  22. Dominic Moss says:

    Posting this again after signing in so I can get notifications. Brian – a simple question compared to some of the questions/observations posted by others. I noticed in the queue that there is a job Project Site Create that appears to show each time a project
    is published. Am I being a pedant, consumed by existential angst or missing something? Surely once a site has been created on initial publication it exists and as such does not need to be created again – what does Project Site Create actually mean?

  23. Is this 2010 Dominic? In 2013 we changed the job name to Project Site Update – as it does more than create – it will check and re-sync permissions etc. It does look odd when it is called create, but the first think it will be doing is checking if the site
    already exists so will not try and create each time.
    Best regards,

  24. Is this 2010 Dominic? In 2013 we changed the job name to Project Site Update – as it does more than create – it will check and re-sync permissions etc. It does look odd when it is called create, but the first think it will be doing is checking if the site
    already exists so will not try and create each time.
    Best regards,

  25. anonymouscommenter says:

    I can alo say that the issue seems to be not solved neither in February nor in March 2015 CU (not tested with April 2015 CU yet).. Also needed to manipulate the WSTS_Server_UID in pub.msp_projects table to fix it

  26. anonymouscommenter says:

    hi my name is sajal saxena i am completed my pwa site with all the important requirements (features and roles)
    but there is some issue which i facing when i am created my PWA through the system administration , its takes some time and after its get provisioned but when i click on this PWA link its takes lot of time around 45-50 minute but still its not open i dont know
    what to do so please any one give help to e.

  27. Landon Howell says:

    Has the cumulative update been released that includes this fix?
    I see this one available but I don’t see this fix included.


  28. HanoYs says:

    Hi Brian, Thanks for the greate description …
    I have a question though .. in 2013, how do delete these groups when deleting the corresponding project, you see .. each project has 4 security groups, and when deleted these groups remain

Skip to main content