Skip to main content

Queue Failure - "User Synchronization for Project Web Access App Root Site and Project WSS Workspace"

Event

You see a queue failure - "User Synchronization for Project Web Access App Root Site and Project WSS Workspace"

You may see a ULS entry that looks something like this:-


10/06/2008 17:11:37.16 Microsoft.Office.Project.Server (0x07D8) 0x0CF0 Windows SharePoint Services Database 6f8g Unexpected Unexpected query execution failure, error code 1205. Additional error information from SQL Server is included below. "Transaction (Process ID 98) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction." Query text (if available): "{?=call proc_SecAddPrincipalToRole(?,?,?,?,?,?)}"


What this means

Some element of PWA or Project Workspace permissions synchronisation has partially or completely failed due to a deadlock. Users may not be able to access the PWA site and/or WSS Workspaces associated to Project files

Triggers

The User Synchronisation of Project Workspaces and PWA Root Site queue job is a resource-centric operation. This means that the job can be triggered in the following scenarios:-

• A Resource Record is Saved
• A Security Group is Saved
• A Security Category is Saved
• The PWA permissions list is Saved

The following actions describe some of those key activities that do NOT trigger this specific synchronisation job as they can be described as project-centric:-

• Adding/Removing Resources on Plans/Tasks
• Synchronisation of Project Workspace via PWA Server Settings

In a normal operating scenario you would not expect high volumes of these jobs to be created - if you do then you should check your processes to minimise these occurances (see end)

Processing

The process this job follows can be described loosely as:-

I. All PWA and PWS permissions are removed (including any Fine Grained Permissions)
II. For the first resource to be synchronised, PWA site permissions are added via the appropriate (Microsoft Office Project Server) Permissions Set
III. For this resource, PWS site permissions are added based on their Project Access Rights and via the appropriate (Microsoft Office Project Server) Permissions Set across ALL Sites
IV. Steps 2&3 are iterated for each resource

The primary job that runs this process (and is captured in logging) is the SynchronizeSingleUsermembershipsInWSS.


Why can this job fail?

There is an increased risk of this job failing if one or more of the following statements are true:
Triggers:

I. There are ongoing changes being made to the Security Model (Category/Group permissions changes)
II. There are ongoing changes to Security Group Memberships
III. There are large volumes of resource account changes being made

Contributing Factors where the triggers are evident:

I. There are a large number of Project Workspaces in the environment
II. Resources have access to a large number of Project Workspaces
III. There are a large number of Active Users in the environment
IV. More than 1 of the above jobs can be triggered at any given point


So how can I resolve this?

1 - By Resource
If this problem is reported for one particular resource then open and save the resource record in PWA-> Server Settings->Manage Users and Groups

2 - For all resources
if this problem is more widespread then you can Open and Save the "Team Members" group (if this does include all resources in the Enterprise Resource Pool). Note that this should be done outside of normal working time to avoid a repeat of the problem.

So how can I stop it happening again?


1 - Minimise the amount of Resource-centric changes are made on Production during standard working hours.

2 - To minimise the user impact, grant Authenticated User access to PWA via a User Group.

or alternatively to avoid the issue completely (in conjunction with point 2 above)

3 - Turn off automatic user synchronisation for PWA, WSS or ALL

>> Run the UpdateUserSyncSetting.exe tool to set the User Sync Settings. Jon
provided you with the documentation to run the tool. This only needs to be run on
one of the servers.
>> Set up a job that will run the appropriate sync tools during non-business
hours. Make sure to start it early enough that it will finish before business
hours and not interfere with SQL jobs like backups.
>> The tools that you will need to run will be based on what setting you use for the
UpdateUserSyncSetting.exe tool.

If you set the tool to:

0 - then you will not need to use the sync tools as this will be normal
behavior.
1 - then you will need to run the WorkspaceRDBUpdate tool.
2 - then you will need to run the WorkspaceUpdate tool.
3 - then you will need to run the WorkspaceUpdate and the WorkspaceRDBUpdate
tools.

Note: My preferred method for these settings is to turn all auto synchronisation off, then use the Security Model (and some processes) to drive Project-centric synchronisations to wss workspaces (which are not affected by this tool) based on group memberships and roles on the project, and use the Authenticated Users access to PWA

These tools only need to be run on one server as they just add the necessary sync
jobs to the queue.

Comments

  1. Hi Carl, Thanks for posting this info - it is very useful indeed. One question: where is the UpdateUserSyncSetting tool you mention? Does it come with PS2007, or is it something I have to obtain elsewhere?

    Thanks,
    Richard

    ReplyDelete
  2. i believe the official line is that it is only available via MS Support as there may be an unsupported risk associated. feel free to email me direct for more info

    ReplyDelete
  3. nice post thank for informasion

    ReplyDelete

Post a Comment

Popular posts from this blog

TPG Apps Highlights - Risk Matrix #projectonline #projectserver #risk

This post is the first of a series to highlight the apps available for Project Server and Project Online from the SharePoint store  ( https://store.office.com/search.aspx?productgroup=SharePoint&qu=tpg ) and direct via your local TPG office. The first of this series will look at the s imple plug-and-play apps that all users of Project Online can make use of quickly and easily.   T hese are: Risk Matrix  Milestone Trend Analysis (MTA) WBS Chart viewer Next we will focus on the challenge of  Resource Request Supply and Demand by demonstrating our more recent TeamLink and TeamManager apps. Team Manager App is a Resource Manager/Owner app for allocating resource supply to Projects and BAU activities and monitoring demands against commitments Team Link App is a PM tool for monitoring Project demands vs the supply provided by the Resource Managers  Finally I will highlight some of the benefits of our integration tools when used in the context of Project Online

Restoring PWA Site to another Web App in the same Farm

The scenario is this: SharePoint 2016 Farm with Project Server Two Web Apps Development UAT One PWA on Development Web App. I want to copy the PWA Site on Development web app to UAT to support a testing cycle. As far as I knew there were two options: 1) Content Database Restore and Attach Process would be backup your Dev Content Database, Restore to a new Content Database for QA, then mount the database on the appropriate web app and your off.... Problem:  Although you can do this with the -AssignNewDatabaseID switch in Powershell (to avoid two content db's having the same database id) the Site Collection (PWA) in the db still retains its SiteID which means there is a duplicate SiteID in the Configuration Database.  This stops the PWA site being created and alllocated correctly and becomes essentially orphaned. This method is only any good for MOVING not COPYING Back to the drawing board... 2) Backup-SPSite / Restore-SPSite I didn't believe this w

Issues update on #projectserver2013 - Timesheets and Publishing

Reporting Publish ** updated with links to other related discussions, and a VBA macro ** the following issue has been noted on publish since June 13 CU was applied: ReportingProjectChangeMessageFailed (24006) - Object reference not set to an instance of an object.. Details: id='24006' name='ReportingProjectChangeMessageFailed' uid='4d869e56-f625-e311-bb41-005056b90052' QueueMessageBody='Project UID='e3f49977-b2bc-e211-8559-005056b90052'. PublishType='ProjectPublish'' Error='Object reference not set to an instance of an object.'. I have seen this noted previously on a similar issue: http://nearbaseline.com/blog/2013/06/ms-reporting-project-publish-jobs-failed-after-aprilcu/comment-page-1/#comment-14741 This is  caused by Baselined Milestones having NULL Baseline Cost values Original bug note with potential workaround is here: http://blogs.msdn.com/b/brismith/archive/2012/05/23/project-server-2007-reporting-project-pu