A customer pain point brought to my attention this week is related to linking tasks to risks from PWA vs linking risks to tasks via the project site’s Risks list.

The customer noticed that, in Project Server 2010, linking a task to risk from PWA’s drill down view of the project schedule does not make that link show up in the Reporting database so he could report on it using SSRS (SQL Server Reporting Services).  However, he noticed that if he links the risk to the task from the Risks list, he was able to report on the link immediately.

I dusted off my Project Server 2010 test server (just kidding, it gets such frequent and heavy testing that I never turn the VM off) and created a project plan with a project site.

I opened the project site, and then clicked on the Risks list. I created a new risk and added a link to a task from the plan.  The queue presented this Reporting (Project Sync) job:

Next, I opened the schedule in PWA and drilled into the plan, then linked the risk there, but no reporting job materialized in the queue.  Nothing queue related happened at all, in fact, unless I saved the plan, but still there was no Reporting job (notice that I did not publish here, which definitely would have fired a reporting job).  Then, I published the plan and the Reporting (Project Sync) job fired.

So, when the user creates the link between task and risk from PWA, the user must publish the plan in order to make the Reporting (Project Sync) job run.  After that job runs, the information related to the link will be in the Reporting database.  When the user creates the link between risk and task from the Risks list, the user doesn’t need to do anything else because the Reporting (Project Sync) job runs immediately. 

This is because changes to Project Server Risks list on the site writes directly to published db so the reporting database has be to be updated. I ran a profiler trace and found a stored procedure that writes to the published DB when a risk to task link is made.  When you edit a plan in PWA, your changes do not impact the published db until you publish, so absent any changes, the published and reporting data still match.  Another way of looking at this behavior is to see that project managers may not want changes made to the plan published until they are ready for the changes to be publicly available. Changes to the site are publicly available without a project publish so the sync job fires when a task/risk is linked.

There real problem to my mind is that there is no way for users to know there is a difference in the behavior based on where you link the task/risk. That’s because there is no warning/dialog pop-up saying if you edit the plan in PWA, you won’t be able to report on the new link until you publish. The result is that a user links a task/risk via PWA and doesn’t know he can’t report on that link until he publishes while at the same time, the user can create the risk/task link from the Risk list and report right away.

From a database and code perspective, linking a risk to a task and linking a task to a risk are actually very different.  Strictly speaking, linking a risk to a task from the Risks list writes to the Published DB, which then requires a corresponding update to the Reporting DB. Linking a task to a risk from the Project Center drill down view writes to the Draft database – and remember, you can make changes all day to the Draft and never see those changes until you publish the plan.  While the actions the user takes appear to be roughly the same whether you link from a task to a risk or vice versa, the command being sent to the databases differ behind the veil of the user interface.  The behavior editing a plan and not seeing those changes until a publish occurs is perfectly in line with a project’s not being made public until a project manager wants them to be by publishing.

Because the project site is already public, linking a risk to a task causes an update to occur against the reporting database.  This behavior is unlikely to change in Project Server 2010, but the fact of the behavior should be relayed to project managers so they can determine the best choice for linking tasks and risks.

Naturally, this line of investigation led to testing on Project Server 2013.  Does the same thing happen there?

For testing, I created a plan called 0000 Linking Risks and published it with a project site on an out of the box instance of PWA.

In PWA, I drill into the project plan schedule and you see the URL below:

http://ps2013c:8080/PWAoob/Project%20Detail%20Pages/Schedule.aspx?ProjUid=807c7051-7881-e411-9433-001dd8b73e9d&ret=0

I selected a task, then clicked on the Options tab, and then on the Related Items button. At this point, the URL changes to the project site URL, where I can create the association.

This means I’m in the project site when I make the association, so the Reporting job fires when I save.  This DID NOT HAPPEN in Project Server 2010.

http://ps2013c:8080/PWAoob/0000%20Linking%20Risks/Lists/Tasks/DispForm.aspx?ID=2&ContentTypeId=0x010800AAD67843BFB5C64E81A19F453581A719&ShowRelatedItems=1

The fact I’m in the project site when I create the association means the behavior is different in Project Server 2013 and the Reporting (Project Sync) job fires because there is only one way to link a task to a risk.  I thought this was worth pointing out and it will make my customer happy to know.

Brian Smith has posted a very interesting blog article about synchronizing users in Project Server 2010 versus Project Server 2013.  He says there are behavior differences between Project Server 2010 and Project Server 2013 regarding user synchronization to project sites.  I quote, "One key part of this change should be taken into account when migrating – as there is one 2010 setting that no longer has UI to change it – and if it is disabled before migration it cannot be turned on again in 2013."  

Brian goes into details of that setting and provides a workaround after describing how the settings and behavior have evolved.

For anyone migrating from Project Server 2010 to Project Server 2013, this is a must read.

The cardinal rule of permissions: Keep It Simple

• The highest rule of permissions best practice is to keep your permissions scheme simple. 

  • If you can use the default categories, groups, and permissions with only minor changes, or none at all, do so!

  • Avoid creating unnecessary groups and categories. Having a large number of groups and categories within an instance of PWA can stress the authorization system, which can affect performance.

• Use the default permissions set.

  • The default permissions in combination with the RBS (resource breakdown structure) checkboxes on Categories is sufficient to efficiently manage permissions in most customer situations with as little overhead as possible.

• Always test permissions changes in a test environment on a copy of production data. 

  • Avoid making changes to production permissions without thorough testing.

  • Use Act as Delegate feature in your test environment to determine if your permissions changes have the impact you desire.

  • If you must change permissions directly in production, only check Allow checkboxes and avoid directly selecting Deny for anything.

• Utilize the RBS checkboxes available on Categories and configure the RBS lookup table to mimic your org structure, then…Update the resources’ RBS values on a regular schedule.

  • A permissions scheme that relies on the RBS allows you to use the default permissions and allows resources to see only things based on their org structure or other breakdown structure as defined by the customer.

  • Utilizing the RBS mean you must frequently update the RBS for new resources or resources whose org structure changes.  Typically, this update should happen at least weekly. 

• Avoid creating separate security groups for team members and project managers for each project plan.

  • This creates an administrative workload every time a project is created and then every time the project membership changes.

  • Imagine having 700 projects in flight and each has two security groups, one for project managers and the other for team members.

• Avoid allowing or denying permissions on specific users.

  • The more cases where users have rights that differ from the groups they are in, the more trouble you will have figuring out why the permissions are broken for certain users.

• Avoid utilizing Deny.

  • It is important to consider when you are configuring a permission to Deny that the Deny setting supersedes any Allow settings that apply to the user for that permission by means of other group memberships. Limiting your use of the Deny setting can simplify permissions management for large groups of users.

• Configure the category and group permissions, then leave it alone.          

  • Changes to the permission scheme should be infrequent.

  • Once you have settled on a permissions scheme, leave it alone unless there is a clear business need and a formal request has been received.

• Download the Project Server 2010 Administrators Guide from here for full descriptions of groups, categories, and permissions: http://technet.microsoft.com/en-us/library/gg663916(v=office.14).aspx

• The Administrator group in PWA > Server Settings > Manage groups should not sync with any groups in AD.  An inadvertent problem with that group in AD could cause administrators to be locked out of PWA when the resource or group sync runs.
  

I've always maintained a list of my own links to updates, but I learned of these two links today.  You can find and manage updates for SharePoint and Project Server with these two links.  I hope you find this useful; they both hold a coveted spot in my favorites for CUs now.

Find and manage updates for SharePoint 2013 and SharePoint 2010 in one place. Use the links on this page to get more information about updates and download the updates themselves.

SharePoint Updates: http://technet.microsoft.com/en-us/library/dn789211(v=office.14).aspx

Find and manage updates for Project Server 2013 and Project Server 2010 in one place. Use the links on this page to get more information about updates and to download the updates themselves.

Project Server Updates: http://technet.microsoft.com/en-us/library/dn789214(v=office.14).aspx

This link has been making the rounds lately and I wanted to share it.

SharePoint patching demystified by Stefan Gossner:  http://blogs.technet.com/b/stefan_gossner/archive/2014/08/19/sharepoint-patching-demystified.aspx