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.