While investigating a solution for a customer who has a pretty common problem I came across another new feature to be included in Project Server 2010 Service Pack 1.
The problem comes about from the requirement to regularly publish project schedules to ensure that reporting data is kept up to date, this is particularly important when using Project Server timesheets which effectively demands that every active project be published at least once per period.
Normally this is okay, but when managing small projects some PM’s may have dozens or more active projects resulting in a significant administrative burden.
What’s new in SP1?
It seems that one of the unannounced new features is the inclusion of an option to “Automatically Publish” Task Updates approved by a rule, apparently the Status Approvals rule configuration will include this to make many of our lives easier!
I look forward to seeing it, and will update this post post release.
Looks like a few others a confirming this, see Christophe’s blog for some screenshots:
The end of June is the date announced for the release of SP1 for Project, Project Server and SharePoint 2010, one new feature (or ‘fix’) that is very exciting is:
- Multi-Browser Support for time entry in Project Web App – Post on 5/17
- With SP1, Project Web App pages needed by team members to submit task status and timesheets are supported on FireFox, Safari, and Chrome.
Finally some support (albeit limited) for non-IE browsers!
Read more about SP1, here (Official Project Blog) and here (Office Sustained Engineering Blog).
Here’s a screenshot using Chrome:
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.
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:
- 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)
- 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)
- Active Directory Sync jobs trigger a permissions sync which acts just like #2.
The big differences are the following:
- During the sync NO permissions are removed. Thus correcting the old situation where an AD sync during business hours could result temporary permission losses.
- 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:
- Create a new Project Server group containing all users.
- Assign My Organisation Category to that group.
- Assign Permission ‘View Project Site’ to My Organisation category.
- Save the new group (and wait for queue jobs to complete).
- 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.
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? :)
See the following blog for information on how Excel Services impacts the above configurations!
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.
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:
(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:
(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.
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!
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!