Custom Search

Thursday, May 7, 2009

SynchronizeSingleUserMembershipInWss error workaround.

A problem that seems to be plaguing systems with a high number of users and/or large number of Project workspaces is the infamous “SynchronizeSingleUserMembershipInWss” error.

This error happens when two jobs try to synchronize permissions on workspace simultaneously, causing a deadlock on the SQL server:

Microsoft.Office.Project.Server - Windows SharePoint Services Database xxxx Unexpected query execution failure, error code 1205. Additional error information from SQL Server is included below. "Transaction (Process ID xxx) was deadlocked on lock resources with another process and has been chosen as the deadlock victim.


Office Project Server 2007 groups and Windows SharePoint Services are synchronized whenever a project is published or the administrator selects a project workspace site on the Project Workspaces page and then clicks Synchronize. This type of synchronization also happens when a change is made to a security setting, such as changes to users, groups or categories. If these changes affect a lot of users or project workspaces, the amount of processing can make the job run very slowly.
If more than one job gets queued simultaneously, the chances of getting a deadlock increase. All this has been very well documented by Alex Angas’ document posted in his blog.

Now, I have been experiencing this “bug” at a couple of different clients, and have come out with solutions through two different approaches. The first one involves using third party, not supported and sometimes sparsely documented, but extremely useful tools from CodePlex.

There are two of them that combined could help you avoid having to deal with this “bug” at all.

If you are modifying multiple resources, you may want to look into using the EPM bulk Edit tool; this one will allow you to go directly against the Project Server Reporting store to pull back the list of resources. I have not used this one myself, but it may help some administrators out there.

The second one is Project Server Workspace Synchronization tool; this is a welcome addition to everybody’s Project Server tool belt. ProjectWorkspaceSync.exe synchronizes workspaces with users, risks and issues. You can use this tool together with un-checking the workspace permissions box in Server Settings / Project Workspace Provisioning Settings as described by Alex in his post..

This will avoid constant synchronization of workspaces, and schedule ProjectWorkspaceSync.exe to be ran at a time when there is little CPU utilization. The tool is simple and easy to use, all you have to do is run it from a command line and add the url of your PWA as the first parameter:

ProjectWorkspaceSync.exe http://ProjectServerName/PWA

There is a final fix that applies only to smaller farms. If you have a server with one, or maybe even two CPUs, you should configure the maximum number of job processor threads for the Project Server Queue service to one.

I have had good success minimizing the amount of deadlocks by doing this. By having only one thread running at a time, there are way less chances of two jobs dead-locking a table when changes to the security system are being performed. Of course, if you have a multi-server, multi-CPU or even only a multi-core server, you might not want to do this as your queue performance would take a serious hit by doing so,

Then again, if the issues being caused by the “SynchronizeSingleUserMembershipInWss” are causing too many headaches, you might rather deal with a slower system than with a bug ridden one.

No comments:

Post a Comment