by Martin Laukkanen | May 17, 2011 | Project 2010, Project Pro 2010, SharePoint 2010
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).
Update 16/07:
Here’s a screenshot using Chrome:
by Martin Laukkanen | Feb 26, 2011 | Project 2010, SharePoint 2010, Troubleshooting
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:
- 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.
HTH,
by Martin Laukkanen | Jan 12, 2011 | SharePoint 2010, Troubleshooting
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) 0x0660 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 (0x0554) 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:
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.
by Martin Laukkanen | Dec 4, 2010 | How to, SharePoint 2010
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;
- Open Central Admin go to Upgrade and Migration
- Select Check product and path installation status
You should see something like the following:
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).
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.
by Martin Laukkanen | Nov 27, 2010 | Troubleshooting
When trying to configure the SQL Reporting Services Add-in for SharePoint 2010 from Central Admin you might see the following error:
(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) 0x1460 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:nnSubject Name: CN=*.something.com, [… … snip … …]nnErrors:nn 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:
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!
