In our previous article, we discussed Permission Levels for Project Web Access sites. We talked about how they were too liberal for most organizations and how to change them.

Unfortunately for us, the fact of the matter is that any changes you make to the default permission levels (in PWA or in a PWS) are not permanent, since the two Membership Synchronization processes overwrite them.

The PSI Methods for these two processes (QueueSynchronizeMembershipForWssSite and SynchronizeMembershipForPwaAppRootSite) can be found in the WssInterop service, which resides at http://ServerName/ProjectServerInstanceName/_vti_bin/psi/WssInterop.asmx. As previously discussed, both of them will delete and recreate the permission levels (or roles, depending which part of what document/interface/article/SDK you read) whenever triggered either by you or by Project Server.

I recently encountered a situation where I would see literally hundreds of errors in the ULS logs like this:

01/18/2008 10:22:59.99 OWSTIMER.EXE (0×0600) 0×08F8 Windows SharePoint Services Timer 5uuf Monitorable The previous instance of the timer job ‘Config Refresh’, id ‘{3F51D43C-C7DD-403D-A63B-1163EA9B46A6}’ for service ‘{2F8D95DC-ECBF-4661-83AD-92CA4162CD4E}’ is still running, so the current instance will be skipped. Consider increasing the interval between jobs.

Every single Timer Job Definition was throwing these errors (sometimes hundreds of them) every time it was invoked. There were no other errors in the Application Log or ULS Logs, even with verbosity cranked all the way up. Alerts weren’t going out, the cube build was failing, and literally everything that relied on a timer job was nonfunctional. Restarting the Timer service alleviated the problem temporarily, but it would inevitably come back after the first invocation of the timer job.