Alex Angas

A crucial foundation of SharePoint is its powerful permissioning model. This is a series of three posts that discusses SharePoint permission assignment in a Project Server project workspace. Part 1 explained how permissions are assigned and problems with the feature’s design. Part 2 discusses a particular bug (i.e. the feature’s implementation). Finally, Part 3 has some solutions.

We’ve looked at the problems with this feature, so what can we do about it? Well the new Project Server 2007 eventing model isn’t broken, so if you have a developer handy use that!

First, uncheck the Workspace Permissions box in Server Settings / Project Workspace Provisioning Settings. Then, have a look at the WssInterop event WssWorkspaceCreated. This fires whenever, um, a workspace is created. The initial state of a created workspace is with permission inheritance broken and the service account assigned to the workspace with Full Control.

From here, use SPWeb.EnsureUser for each user you’d like to give access to the workspace. This works by adding the user to the SPWeb if they haven’t been already. This does not give the added users any permissions to the workspace. SPWeb.EnsureUser also works with Active Directory groups, so a model where every user needs read access can be simply accomplished. Finally, use SPWeb.RoleAssignments, SPWeb.RoleDefinitions, and SPRoleAssignment.RoleDefinitionBindings to assign users the correct permissions (sorry, hopelessly glossed over but there are examples out there on how to use these).

Something else to note about a custom solution is that despite unchecking the Workspace Permissions box earlier on, Project Server’s behaviour does not change when giving access to the PWA site. It will still handle this for you according to the rules in Part 1, leaving you to configure the permissions for the workspace with custom code.

This works fine and if you are able to make use of Active Directory groups, is fast as well. Plus now that you’ve gone custom, you have all of the freedom (and traps) of flexibility and the ability to create your own permission assignment rules. Don’t forget you’ll need to invest time in creating custom administration pages to manage those as well.

So what about going forward and sticking with the product for a solution? For Project Server 14 or 2009 or 2010 I have no idea if there will be any changes to the workspace permissions functionality. If you agree that this feature needs looking at, please give feedback to the Project Server team as they do read it and listen (I’ve had great responses from Treb Gatte and Brian Smith on other issues). Hopefully bugs will be fixed and the feature improved next release!

Thanks for reading and I hope this helps someone else out there with similar experiences.

Tags: permissions, Project Server, SharePoint, workspaces

A crucial foundation of SharePoint is its powerful permissioning model. This is a series of three posts that discusses SharePoint permission assignment in a Project Server project workspace. Part 1 explained how permissions are assigned and problems with the feature’s design. Part 2 discusses a particular bug (i.e. the feature’s implementation). Finally, Part 3 has some solutions.

If you’ve been having some great successes out of your Project Server solution you’ll probably be building up quite a few users and workspaces. One particular customer I’m aware of has over 1000 of each. To try and get around the inflexible rules outlined in Part 1, they’ve decided to give every user at least read access to every workspace. Unfortunately this has uncovered a particularly nasty SQL deadlock bug.

10/06/2008 15:33:59.86 Microsoft.Office.Project.Server (0x1540) 0x12C4 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 151) 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(?,?,?,?,?,?)}"


The bug happens when one or more of the following operations is occurring at a time:

1. Creating a new workspace by publishing a project (queue job “WSS Workspace Create”)
2. Resynchronising workspace permissions from Server Settings / Project Workspaces (queue job “WSS Workspace Membership Synchronisation”)
3. Changing a user’s Project Server groups which results in changes to SharePoint permissions (queue job “User Synchronization for Project Web Access App Root Site and Project WSS Workspaces”)

When the bug hits, permissions are only partially assigned so as this happens again and again, a user’s consistency of access disappears. The only solution is to try and resynchronise the workspace with fingers crossed that it succeeds without another SQL deadlock. But you’re completely out of luck when running a batch job that affects several workspaces such as number 3 above. The workspace it reached before everything went horribly wrong doesn’t appear to be logged!

Because of the SQL deadlock failures, the SynchronizeMembershipForPwaAppRootSite() method in the WssInterop web service has been looked at. This performs a complete resynchronisation across all workspaces, functionality that is not available through the UI. Unfortunately with testing in UAT (less powerful than production but still a three server farm), this operation was going to run for days. Also, no other sync jobs could occur at the same time or else it would be SQL deadlock again!

Bugs are the worst, but implementation is also a shocker because of the huge length of time these jobs take to run. For example, up to 7 minutes for numbers 1 or 2 above, and 15-45 minutes for number 3 depending on number of users with changed permissions. This is exacerbated as more workspaces are created (the problem seems to be more related to number of workspaces rather than number of users). The server environment where this issue is occurring is very powerful and speed should not be an issue.

We’ve seen from Part 1 the deficiencies in design of this feature, but now also it’s implementation. So things can only get better in Part 3, coming next!

Tags: permissions, Project Server, SharePoint, workspaces

A crucial foundation of SharePoint is its powerful permissioning model. This is a series of three posts that discusses SharePoint permission assignment in a Project Server project workspace. Part 1 explains how permissions are assigned and problems with the feature’s design. Part 2 discusses a particular bug (i.e. the feature’s implementation). Finally, Part 3 has some solutions.

Project Server has its own SharePoint security groups which almost precisely equate to the standard SharePoint groups of Read, Contribute, Design and Full Control. The TechNet article Coordinate Project Server and Windows SharePoint Services security is the official word for exactly how permissions are assigned. Essentially just as SharePoint has its own built-in list of groups for “Read”, “Contribute”, “Design” and “Full Control”, then Project Server comes to the party with “Readers (Microsoft Office Project Server)”, “Team members (Microsoft Office Project Server)”, “Project Managers (Microsoft Office Project Server)” and “Web Administrators (Microsoft Office Project Server)”… blurrgh!

Here is a simplified summary of the rules that explain how users get their permissions. This is without the “(Microsoft Office Project Server)” suffix but with standard SharePoint group names in brackets:

• User that publishes the project has Project Manager (Design) permissions
• Users assigned to tasks within the project have Team Member (Contribute) permissions
• Users on the Resource Sheet of a project have Reader (Read) permissions
• Users that have Manage Windows SharePoint Services permission have Web Administrator (Full Control) permission over all workspaces
• Users that have Save Project permission have Project Manager (Design) permission over all workspaces

This looks complicated and it is. Try explaining to a project manager that access to documents in their workspace depends on who is added to the project’s Resource Sheet. It just doesn’t make sense! Then try explaining to an administrator why there is a group called “Readers (Microsoft Office Project Server)” as well as the standard SharePoint group called “Read”. It just doesn’t make sense!!

Then there’s the inflexibility of the rules themselves. There are no options – they are either on or off. And if you don’t go with MS on this one folks and uncheck the box for Workspace Permissions in Server Settings / Project Workspace Provisioning Settings, then only the Project Server service account is given access to new workspaces! This is hardly useful to the humble user needing to assign permissions who will never get their hands on this particular username and password. It just doesn’t make sense!

Don’t worry, there are solutions. However, they don’t come until Part 3! Next we look at how Microsoft’s solution is also slow, and even worse, buggy.

Tags: permissions, Project Server, SharePoint, workspaces