A very frequent request I get is how to change the default permissions assigned by Project Server to Project Workspace Sites for all projects, unfortunately this is not something that is configurable in Project Server so the only option out of the box is to disable the permissions sync and manage those permissions manually. Of course if you don’t want Administrators to manage every user manually this is not an option.

This is made more annoying if you want PM’s to be able to manage the site, as by default they only have Contribute like access.

There are a few options that exist out there, notably this one; Adjust the Default Project Web Access Permission Levels, which uses a SharePoint timer job to manage the default Permission Levels. However I have had need for something simpler, and so recently for a customer I implemented the following:

 

Modifying Basic Site Permissions using Project Events:

My solution is by intent extremely simple, so simple that I will include the main piece of code below (as well as having the full solution attached), in short what this code does is the following:

On Publish of any project does the following;

  1. Retrieves the OWNER of the Project
  2. Retrieves the Workspace Site of the Project
  3. Adds the Owner to the default SharePoint role SPRoleType.Administrator

So as you can see it only updates one user’s permissions, however it would be trivial to update the code to do more based on the Project Team and other requirements.

Here is the bulk of the code:

if (wssData.ProjWssInfo.Count == 0)
{
  LogEventEntry(String.Format("No workspace site found for project: {0}", 
    projectData.Project.First().PROJ_NAME), EventLogEntryType.Warning);
}
else {
  // Open the SPSite and web
  using (SPSite pwsSite = new SPSite(wssData.ProjWssInfo[0].PROJECT_WORKSPACE_URL))
  {
    using (SPWeb pwsWeb = pwsSite.OpenWeb())
    {
      // Handle Null Email Address
      String ownerEmail;
      if (resourceData.Resources.First().IsWRES_EMAILNull()) ownerEmail = "";
      else ownerEmail = resourceData.Resources.First().WRES_EMAIL;

      // Add the new role assignment to the Owner
      SPRoleAssignment roleAssn = 
        new SPRoleAssignment(resourceData.Resources.First().WRES_ACCOUNT,
          ownerEmail,
          resourceData.Resources.First().RES_NAME,
          "Project Owner");
      SPRoleDefinition roleDefn = 
        pwsWeb.RoleDefinitions.GetByType(SPRoleType.Administrator);
      roleAssn.RoleDefinitionBindings.Add(roleDefn);

      pwsWeb.RoleAssignments.Add(roleAssn);
    }
  }
}

 

The code is bound to both OnPublished and OnSummaryPublished (to get the Save from PWA also), and ensures that the Owner will always have Admin rights, and if not all the PM has to do is republish.

Download only the WSP package here with – basic – instructions.

Download the full source package here.

Notes:

  • As an Event the solution runs under the security context of the Project Server Event Service account, and so this user must be a user in PWA with appropriate access, I use administrator however it could get by with less.
  • This completely ignores the WssSync jobs created by Project Server, as such some actions such as AD sync and group membership changes can apply permissions outside of typical Publish events. However in my experience with 2010 this will not remove existing SharePoint permissions (see one of my previous blogs on this).
  • The solution is built with Visual Studio 2010 and packaged as a WSP allowing for simple installation using typical SharePoint means.
  • The solution uses Project Server 2010 WCF methods to access the PSI, and so without modification it will not work on Project Server 2007.
  • The solution logs error information to the Event Log and not the ULS, this is because I’m lazy. However it means that on Windows Server 2008 if the user (Event Service Account) is not a local admin it will fail and log nothing.

 

Post comments with any questions or additions even, but please note that I can’t provide support for the standalone WSP package.

, ,

Often I am asked by Project users about assignment units and how can you explain the behaviour in MS Project, most often the questions are around why the % assigned units of a particular resource assigned to a task (an assignment) can change unexpectedly.

The situation can be explained through the following scenario using MS Project 2007:

  1. A Project Manager creates a task of 10 days, assigns a resource and sets the Units to 20% (15 hours of work with 1.5 hours planned per 7.5 hour day) using the task settings of Fixed Duration and Not Effort Driven.

image

  1. Now the Resource submits a timesheet that contains Monday = 1.5h, Tuesday = 0h, Wednesday = 1.5h.
  2. After the status update is accepted into the plan the resource Assignment Units has changed to 23% and a gap is shown in the Gantt chart bar.

image

This behaviour is expected. The cause is due to the missing day (Tuesday) of work which results in an additional 1.5h of work being spread across the remaining days of the task resulting in each remaining day now having 1.72 hours of work, or put another way a ‘peak’ assignment units of 23%.

This can lead to some confusion when looking at project schedules as if like many people your organisation assigns resources to work on such % allocations, typically through an approval process which dictates the "maximum" % allocation for any given resource.

The solution for the PM of course is to reduce the remaining work to return the peak units back to 20% ie in the above example subtract 1.5h work from the total. To see this do the following to correct the units in the above example:

  1. The Project Manager now edits the remaining work for the given task and reduces it by 1.5h, now the Units returns to 20%.

image

 

What’s new in Project 2010?

This behaviour has changed significantly in Microsoft Project 2010! In fact the behaviour now is closer to what you might expect; Microsoft has introduced a new field in addition to Assignment Units you now have Peak Units which shows exactly what you might guess from the name in the example above, in short you can see both the original “assigned units” of 20% and the actual “peak units” of 23% together.

See the following quote from Microsoft:

"In Project 2007, and previous versions, when this value differs from 100% we show it next to the resource name in the Gantt chart. For Project 2010 we’ve made some changes to the way that the Assignment Units field is calculated. Primarily, these changes were made in response to customer feedback about the way calculations were impacted when resources entered overtime work. For this release we’ve clarified the definition of the Peak field and the Assignment Units field which previously had some functional overlap but now fill more defined, separate, roles. As a result of these changes the Assignment Units field is no longer automatically modified to be greater or less than default value of 100%; as a consequence the field does not show up in the Gantt chart as often as it used to."

Source: Assignment Units in Project 2010

For more information on task types, assignments and such here is another good read on the topic;

Task Types: Don’t Get Frustrated!

, ,

A long time ago (it seems) I blogged about reporting directly from the SharePoint workspace sites using SQL Reporting Services to get around the limitations with the reporting database refresh. Using XML provided a neat method for pulling data directly from all the out-of-the-box lists such as Risks and Issues, as well as other custom lists.

Unfortunately setup and maintenance was difficult requiring a little knowledge of web services as well as some XML syntax, but fortunately now with SQL Server 2008 R2 things have improved drastically!

What’s New: Now you can directly create ‘Microsoft SharePoint List’ data sources!

See the screenshot:

clip_image001

Better yet when you create a Data Set using the above data source the Query Designer is completely new:

clip_image002

Finally no more messing around with column names using XML and having to have specific views configured in your SharePoint sites.

That should make things much easier!

 

BTW. Lastly it’s definitely worth mentioning that the above also works with Report Builder 3.0!

, ,

I came across an unexplained issue recently with an ‘old’ Project Server 2010 customer, in short what happened was many of the permissions across the Project workspace sites were lost. Unfortunately the loss was triggered by performing a Playbooks (2010 version) backup of the server configuration which was even more concerning, considering that is such a commonly used tool.

In short we needed a way to restore all of the workspace site permissions to what they should be, without having to manually action each site.

 

Some background:

As it turns out Project Server 2010 has (once again) drastically changed the way that workspace site permissions are managed, fortunately changed for the better as now the behaviour is something like this:

  1. On first publish or creation of the workspace all appropriate users are granted permissions based on their group memberships and if they are a member of the project team. (Just as it previously worked)
  2. Subsequent publish jobs trigger another ‘Workspace Create’ job which now only adds new permissions but does not remove any existing ones, such as when a new team member is added to the plan. (This is similar to 2007 SP2)
  3. Active Directory Sync jobs trigger a permissions sync which acts just like #2.

The big differences are the following:

  1. During the sync NO permissions are removed. Thus correcting the old situation where an AD sync during business hours could result temporary permission losses.
  2. Manually changed permissions at the SharePoint level are respected. For instance if you remove a particular user from a SharePoint site, Project Server will not add it back in either of the standard permissions sync jobs above.

 

The Solution: To Restore All Permissions

As you may have found for yourself due to the new behaviour if a user is deleted from the SharePoint site, re-publishing a project will no longer fix the permissions. As such a new solution was needed in my case where permissions were lost across all sites:

  1. Create a new Project Server group containing all users.
  2. Assign My Organisation Category to that group.
  3. Assign Permission ‘View Project Site’ to My Organisation category.
  4. Save the new group (and wait for queue jobs to complete).
  5. Once confirmed permissions working delete the group (and again wait for the queue).

This will force a full refresh of the workspace site permissions across all users and all sites. Due the the new method of handling permissions it will only add each user with a minimum of ‘Reader’ unless they have another group which applies like Project Manager or Administrator, once you complete step 5 those unnecessary Readers will be removed, leaving only the correct permissions.

 

HTH,

, , ,

Following on from my previous post about Project Server and PerformancePoint in a multi-tenanted environment, realised that I had not told the whole story!

I neglected to include this when I wrote the above, Excel Services is another critical part of Project Server (more so than PerformancePoint really), and although it does have some support for Multi-tenancy it is far from perfect.

In short, when you configure Excel Services (no partitioning options are available) it does appear to honour subscriptions in the configuration, ie you can use a tenanted Secure Store to create Excel Services Application IDs, however the catch is that it will only talk to the Secure Store in the Default proxy group!

This presents a problem, as you read above PerformancePoint also only talks to the Default Secure Store, however unlike Excel Services PerformancePoint can not talk to a tenanted Secure Store app in the default group so you are left with a catch 22. Either both Excel Services and PerformancePoint can work together using a NON-tenanted default secure store, or one or the other cannot be installed!

*sigh*

If this stuff were simple we wouldn’t be here would we?

,

Update 21/01/2011: Update below regarding Excel Services and Multi-tenancy!

One of the exciting new features of SharePoint 2010 is multi-tenancy, if you’re working in hosted or shared environments then it is no less than a must-have feature.

Unfortunately in the real world of software nothing is perfect at RTM, and this would have to be one of those cases!

In short neither Project Server or PerformancePoint appear to support multi-tenancy in SharePoint 2010, it would seem that the feature has yet to be fully implemented for either service application, however the situation is not as bad as you might fear.

 

Project Server in a multi-tenanted environment

Firstly although Project Server does not accept any subscription related parameters when provisioning a new instance using PowerShell or the Central Admin, it does appear to work in a tenanted environment. Basically the fact that any provisioned PWA site is a site collection of its own means that once you have provisioned your PWA instance you can use the following PowerShell command to associate your PWA site collection with your tenant subscription:

Set-SpSite $PWASiteUrl -SiteSubscription $subscription

More good news is that once provisioned a PWA instance is able to communicate with other service applications belonging to the same subscription. Most importantly: Secure Store Service. Without that Excel Services wouldn’t work!

All is not good though, especially if you like to use the full feature set of the 2010 product, read on..

 

PerformancePoint in a multi-tenanted environment

This is where the news gets bad, it would appear that PerformancePoint in 2010 does not support multi-tenancy at all, it actually doesn’t appear to respect tenant subscriptions and so as a result you might end up with errors like the following when attempting to run Dashboard Designer or configuring the service application unattended account;

w3wp.exe (0x04E4)        0x0ED8        Secure Store Service        Secure Store        7557        Critical        The Secure Store Service application Secure Store Service Proxy is not accessible. The full exception text is: Access is denied.        adfdd2a3-b6e5-4d92-8c5e-5a44fd821969

w3wp.exe (0x04E4)        0x0ED8        Secure Store Service        Secure Store        d9ld        Unexpected        Unexpected exception from endpoint address

w3wp.exe (0x04E4)        0x0ED8        Secure Store Service        Secure Store        d9le        Unexpected        Logging unknown/unexpected client side exception: SecurityAccessDeniedException. This will cause this application server to be removed from the load balancer queue. Exception: System.ServiceModel.Security.SecurityAccessDeniedException: Access is denied

Some searching will lead you to a number of sources talking about the lack of a Master Key being created in the Secure Store which is most certainly the cause of the issue, unfortunately it appears that in the case where your Secure Store is created with tenancy enabled PerformancePoint is unable to see the Secure Store service application (and thus unable to retrieve the master key)!

Some deep reading led me to some TechNet articles detailing the requirements for PerformancePoint (sorry can’t find the link ATM), basically PPS requires that a Secure Store Service Application exists in the default proxy group, and as I’ve found that app also cannot be tenanted.

Fortunately this can also be worked around, maintaining a non-tenanted default Secure Store app dedicated to PPS does not as I see it introduce any security implications, in particular as you will have to provision a separate PPS service for each tenant in your farm (thus losing much of the benefits of multi-tenancy).

 

All I can say on this one is that I can’t wait for SP1 for PPS, maybe then we’ll even be able to name our databases and lose that BETA PowerShell command line syntax? :)

 

Update 21/01/2011:

See the following blog for information on how Excel Services impacts the above configurations!

, , ,

With a large customer going live on a fully multi-tenanted claims authenticated platform in the last month I’ve had the chance to really see the limits of these two new features in SharePoint 2010. This issue was one of the big impact problems that I’m hoping that I’ve now found the solution to, so with that in mind it’s definitely worth sharing.

Problem:

After a few days of working normally claims authentication stops working unexpectedly on any given server in the farm, the below errors are logged.

Event Logs

Log Name: Application

Source: Microsoft-SharePoint Products-SharePoint Foundation

Event ID: 8306

Task Category: Claims Authentication

Level: Error

Description:

An exception occurred when trying to issue security token: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs..

Log Name: Application

Source: Microsoft-SharePoint Products-SharePoint Foundation

Event ID: 8306

Task Category: Claims Authentication

Level: Error

Description:

An exception occurred when trying to issue security token: The security token username and password could not be validated..

Log Name: Application

Source: Microsoft-Windows-User Profiles Service

Event ID: 1511

Task Category: None

Level: Error

Description:

Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.

ULS Logs:

01/04/2011 13:38:52.17        w3wp.exe (0x037C)        0×0660        SharePoint Server        Shared Services        olgq        Exception       System.Runtime.InteropServices
.COMException (0x800703FA): Illegal operation attempted on a registry key that has been marked for deletion. at System.DirectoryServices.DirectoryEntry.Bind(…      

01/04/2011 13:38:52.17        w3wp.exe (0×0554)        0x0F30        SharePoint Foundation        Claims Authentication        8306        Critical        An exception occurred when trying to issue security token: The security token username and password could not be validated..       

 

Cause:

The third the Event log error above I included as although it is one that you often see, it was the message that eventually led me to the what looks like the source of this issue, with that combined with the “registry key that has been marked for” message in the ULS I was lead to the following DCOM blog:

A COM+ application may stop working on Windows Server 2008 when the identity user logs off

Resolution:

It seems that the Claims provider breaks when for some reason or other the App Pool account logs off unexpectedly, the solution (at least after 2 weeks with no reoccurrence) is as suggested in the above blog;

As a workaround it may be necessary to disable this feature which is the default behavior. The policy setting ‘Do not forcefully unload the user registry at user logoff’ counters the default behavior of Windows 2008. When enabled, Windows 2008 does not forcefully unload the registry and waits until no other processes are using the user registry before it unloads it.

The policy can be found in the group policy editor (gpedit.msc)
Computer Configuration->Administrative Templates->System-> UserProfiles
Do not forcefully unload the user registry at user logoff

Change the setting from “Not Configured” to “Enabled”, which disables the new User Profile Service feature.

‘DisableForceUnload’ is the value added to the registry

 

I’ll update this blog entry if the problem comes back.

, ,

It seems SharePoint 2010 gives a nice new way to say exactly what versions of the binaries are installed on any given server in your farm, this is a great enhancement from 2007 which effectively required a Windows Explorer properties check at times to be absolutely sure that all the servers had been updated!

Find it in Central Admin by;

  1. Open Central Admin go to Upgrade and Migration

clip_image001

  1. Select Check product and path installation status

You should see something like the following:

clip_image002

Specifically if you scroll down you will see the project server section under each server in the farm, and in my case you can see the RTM version number plus the KB2394322 (October 2010 CU).

clip_image003

Nice.

 

FYI that SQL method still can come in handy (when migrating for instance) so if you’re not familiar with it here it is:

USE ProjectServer_Reporting

SELECT * FROM dbo.Versions

Not exactly as much detail as the above method, but it does confirm what version server your databases should belong to.

, ,

When trying to configure the SQL Reporting Services Add-in for SharePoint 2010 from Central Admin you might see the following error:

image

(Error Text: Failed to establish connection with report server. Verify the server URL is correct or review ULS logs for more information. …)

Most common cause: Kerberos

There are actually a few causes for this, and usually the ULS will show the reason pretty clearly, for instance most commonly I see the following:

w3wp.exe (0x11E4)        0×1460 SQL Server Reporting Services SOAP Client Proxy  0000 High Exception encountered for SOAP method GetSystemProperties: System.Net.WebException: The request failed with HTTP status 401: Unauthorized

In that case the cause is likely to be related to Kerberos, if you’re using Windows Authentication mode and have multiple servers in the SharePoint farm then that is where you should look. A good test to prove that is if it works without error using ‘Trusted Authentication’.

 

Alternate cause: SSL

However recently I have found a new type of issue that causes this, here’s the ULS extract;

An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=*.something.com, [… … snip … …]\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority..

In this case the ULS log is very helpful indeed as it seems that SharePoint maintains its own certificate store which does not contain any of the usual certificates.

So the solution to this one is quite easy, you simply need to obtain and install the appropriate certificate.

With credits to this blog Calling an SSL Web Service from SharePoint 2010 (For example LinkedIn) you can download the certificates directly from Verisign:

https://www.verisign.com/support/roots.html

In my case it was the GeoTrust certificate, if you’re not sure then view the certificate by clicking the Padlock icon in IE and under Certification Path you can view the certificate hierarchy to determine who your root certificate is.

Once you have your certificate then open Central Admin, and under Security – Manage Trust add the certificate using New. It should then look something like this:

image

Once that’s done go back to the SSRS integration and you should now hopefully be able to complete the integration without further errors.

 

Final Thoughts

This SSRS integration has always had problems in my experience, all that I can suggest if you are still having issues is double check:

  • SQL Reporting Services 2008 should be installed with Service Pack 2 (or SP1 with CU8)
  • SQL Reporting Services 2008 R2 in my experience works without any updates, however you might like to try the latest patches: both SSRS and the SharePoint add-in are updated in SQL 2008 R2 CU4 (http://support.microsoft.com/kb/2345451)

Hope that helps someone out there!

, ,

This is probably the first major impact 2010 issue I’ve experienced, not the first issue let’s be clear, but the one causing significant impact to at least two of my major customers who are now well into production.

Problem:

For no apparent reason when attempting to Save a project from Microsoft Project Professional 2007 to the Project Server 2010 the following error is displayed:

image

(Text for Google: The file cannot be opened. … Project files saved in a version earlier than Microsoft Project 98 can’t be opened. If your file is from an earlier version … save in MPX format …)

 

After selecting Ok, any subsequent attempts to save report the following error:

image

(Text: An unexpected error occurred during command execution.)

 

This problem ONLY occurs with Project 2007 client version and attempting to open and save the file in Project 2010 will work as expected. Also it’s worth noting that once the error appears on one client, all clients will be unable to save the project.

Finally it is definitely not related to legacy projects, I have seen it occur on a test dozen line project based on a blank template.

 

Cause:

Unknown at this stage, although it is definitely some sort of corruption, likely in the Resource Sheet which can be proved by deleting all resources and resaving which will work immediately! It seems that the 2010 client has better error handling / correcting or perhaps that the 2007 client is introducing some errors!

 

Resolution:

We’ve (as in we at EPM Partners) have spent many hours on this issue with Microsoft as it seriously impacted one of Microsoft’s largest Asia-Pac 2010 customers, in the end with the support of a Microsoft PFE (onsite engineer) a resolution was found in the yet-to-be-released beta October Cumulative Update for Project Pro 2007.

So there is light at the end of the tunnel, however the problem is not yet closed, so far with over a week of testing post-cu this issue hasn’t reoccurred, but this is definitely one to watch out for!

, ,