Project Server 2010: Where did my SharePoint list notifications go?

In Project Server 2010, and in 2007 too for that matter, Project Server manages the setting of permissions on the various SharePoint sites used for Project Server.  So for example when you add a user to Project Web App (PWA) they will also be added with the right permissions to the PWA site itself.  If you then add them to a project then depending on your settings they would also get added to the SharePoint site for that specific project plan – enabling them to use the Issues, Risks and document features. This can lead to potential issues depending on how you have configured Project Server, how many users you have and also which features of SharePoint you are using.  This post deals with the last point, but I will be publishing another post shortly that deals with the other issues you can come across – particularly what can happen if you have very many users with access to very many projects, and hence access to very many sites.

But first – alerts and notifications.  We had a customer who found that they could set notifications on a list on a project site through a subscription, so that they could get notified of any additions, changes etc.  However, they noticed that they were not getting the notifications they expected and when they examined the list again the subscription was gone!  It transpired that the method Project Server uses to keep the user list in sync (the various settings within groups and categories – and team changes within a plan) was breaking this feature.  Basically we remove and then add back the users ensuring they have the correct permissions – but unfortunately in the process we lose any subscriptions they may have to be notified of changes in the list!

So if this is a feature you are using and wondering why it keeps breaking – or perhaps it is a feature you would like to use – then it may be best to disable the synchronization with the project sites to avoid this problem.  This would of course mean that you would then need to manually keep control of the user permissions on the sites.  If you go this route then I would also suggest that adding users to groups rather than individually is the best way to go.  More on that in a future post…

The setting can be changed using the PSI and the Admin Web Service and the UserSyncSettings method.  The enumeration of values that can be set are detailed at, and the method described at

Turning off the Project Site sync is achieved by the enumeration DisablePWS.

*** Update 7/24/2013 – the values shouldn’t be 1,2,4,8,16 – but 0,1,2,3,4 – the members should enumerate correctly – I’ve now corrected the table and example below – sorry, I thought I’d done this a long while ago… ***

Member name Description
Enabled Value=1  0. Enable all synchronizations.
DisablePWA Value=2 1. Disable synchronization with Project Web App.
DisablePWS Value= 4.  2. Disable synchronization with project sites for the user.
DisableEmailSync Value=8  3. Disable email synchronization.
DisableAll Value=16  4. Disable all synchronizations.

This relates to settings in the MSP_WEB_ADMIN table of the Published database in the WADMIN_USER_SYNC_SETTING column.  So for example a query such as:

Update [ProjectServer_Published].[dbo].[msp_web_admin] set [WADMIN_USER_SYNC_SETTING] = 2

would do the same as using the method to set the enumeration:

int syncSettings =  (int)SvcAdmin.UserSyncSettings.DisablePWS;

We’d certainly prefer you to not touch the DB correctly – but I’m guessing that many of you would find it much easier to execute a SQL query to update the value than to write the code necessary to do the same (I certainly would!).  Wouldn’t it be nice if we could do it via PowerShell?  That is something I am looking into – and the Admin web service is an ideal candidate to be wrapped up like the Project and Security web services have been at by Mike Shughrue.

As mentioned I will be following this up with another post with some other considerations around turning off the automatic sync particularly if you have large numbers of users who each have access to large numbers of sites.

Comments (2)

  1. Dan says:

    We have a related issue. We use automatic sync, but we have some document libraries/folders/list that do not inherit permissions. For example we have a doc library called PM files and only the PM, PMO head, and executive sponsor have access. Our issue is whenever we change permissions via PWA, for example add or remove permission for the Project Manager group, it first removes all permissions, but then does not add them back to the libraries/folders/list that do not inherit. The net result is that these folders “disappear” from view and our SharePoint admin must add the permissions back. It seems to us that it should not remove permissions on the libraries/folders/lists that do not inherit. Is there an approach you would recommend to help with this problem?

  2. Hi Dan, and yes, this is a common annoyance with our permission system.  I understand that if you create SharePoint groups and then make your specific permission settings by assigning these groups then these will not get removed.  I haven't tried this recently but am sure it used to work that way.

    Best regards,


Skip to main content