by Martin Laukkanen | Jul 7, 2010 | Project 2010, Project Pro 2007, Troubleshooting
This is a new error that has been bugging me for a few weeks now:
The error message "Project Server encountered a problem with this error code:9000" occurs when attempting to save a project in Project Professional 2007 client:
Additionally you may receive a blank "Job failed" window when trying to check-in a project:
This problem is caused by an Internet Explorer login session to Project Web Access expiring and as a result the project client is forced to re-login, however this re-login only seems to be supported in Project Professional 2010 and not 2007 client running in backwards compatibility mode.
This only applies to Project Servers / SharePoint configured to use Claims authentication, or when Project Professional 2007 is using Forms authentication to logon to PWA. (I assume Project Pro can re-authenticate easily using NTLM)
The best workaround to this is to not use the connect / disconnect and work offline options in Project Professional as this does not re-log you in.
Additionally perhaps avoid opening PWA in a separate Internet Explorer window so as to not logout inadvertently.
Performance problems also exacerbate this issue.
Hope this helps someone!
UPDATE 11/09/2010:
Since posting the above I have run into this error on some other occasions not related to Claims based authentication. Specifically I found this error would occur whenever attempting to save one particular MPP file into a server. In that particular case reviewing the schedule and specifically the resource sheet turned up the cause:
Clearly this resource is corrupted (this is an English install) in some way, what this indicates is that the error 9000 is a generic ‘error of last resort’ it would seem.
by Martin Laukkanen | Jun 6, 2010 | SharePoint 2010
I just spent some time setting up my first claims based authenticated Project Server 2010 and thought I would post my experiences here, maybe that will help someone avoid the issues I had.
Firstly Bill Baer’s TechNet Blog has a great how-to article on the setup of claims-based authentication, unfortunately there are a few mistakes and omissions in the post that will cause some issues if you follow the steps as provided.
To clarify one mistake I noticed (where Bill asks you to update the Central Admin web.config twice) you must configure the web.config of the following:
- Central Administration Web Application
Security Token Service Error:
Secondly when updating the Security Token Service, in my default install I found that there was no <system.web> tag, and so placing the config after the </system.net> as instructed by Bill, caused the following error when trying to login:
ProtocolException: The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (application/soap+msbin1). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. T
Once I enclosed my <membership> and <rolemanager> tags in a <system.web> </system.web> all was good. Thanks to this thread for that solution.
Secure Store Error:
Finally once I got it all setup the I was getting errors trying to open my Excel data connections via Excel Services, the ULS log error was the following:
06/04/2010 12:52:42.78 w3wp.exe (0x1AA4) 0x1D94 Secure Store Service Secure Store 7493 Critical The Microsoft Secure Store Service application Secure Store Service failed to retrieve credentials. The error returned was ‘Access is denied.’. For more information, see the Microsoft SharePoint Products and Technologies Software Development Kit (SDK). e994ce5b-fcde-43e8-a32b-c2427a86fc6d
This one turned out to be very simple, I forgot to add my new claims ‘role’ group to the Target Application Members configured and used by my data connections. Editing the Target Application under the Secure Store Service Application and adding to the Members those users logging in using claims fixed that one.
