by Martin Laukkanen | Oct 15, 2010 | Project 2010, Troubleshooting
This is an issue I have seen now with two different Project Server 2010 clients;
Symptoms:
- Certain Projects cannot be opened in either PWA or MS Project.
- Oddly the same projects do not appear to exist in the Draft database, but DO appear in the Published database.
- Projects cannot be deleted from Server Settings after selecting the Published version and hitting delete.
Errors:
Delete Queue job fails and review of the ULS log shows the following:
10/14/2010 11:30:40.33 Microsoft.Office.Project.Server (0x14A8) 0x172C Project Server Server-side Project Operations 7gvo Critical Standard Information:PSI Entry Point: Project User: i:0#.w|domainadministrator Correlation Id: e63eca62-f9fb-40d6-af52-db59bff5b7cd PWA Site URL: http://project2010:82/PWA SSP Name: Project Server Service PSError: ProjectDeleteFailure (23006) The request to delete a project encountered a problem – the relevant job failed in the Queue. Project UID: 01c7c325-1704-4269-8316-ab1b0bc85d07. Sub-job type where failure occurred: Microsoft.Office.Project.Server.BusinessLayer.QueueMsg.
AdjustTimeSheetForDeletedProjectMessage. Sub-job ID where failure occurred: . Specific stage in the sub-job where failure occurred: . Does this failure block the correlated job group: Undefined. See the ‘Manage Queue’ page in PWA for more details.
Additionally enabling Verbose ULS logging for all Project Server events turns up this one:
10/14/2010 11:50:05.33 Microsoft.Office.Project.Server (0x14A8) 0x1434 Project Server Timesheet myzd Verbose PWA:http://project2010:82/PWA, ServiceApp:Project Server Service, User:i:0#.w|domainadministrator, PSI: Start ApproveProjectTimesheetLines(approvedTimesheetLines=’ ‘, rejectedTimesheetLines=… [GUID’s removed] … 10/14/2010 11:50:05.33 Microsoft.Office.Project.Server (0x14A8) 0x1434 Project Server Timesheet myzl Verbose Error is: GeneralItemDoesNotExist. Details: . Standard Information: PSI Entry Point: Project User: i:0#.w|domainadministrator Correlation Id: e63eca62-f9fb-40d6-af52-db59bff5b7cd PWA Site URL: http://project2010:82/PWA SSP Name: Project Server Service PSError: GeneralItemDoesNotExist (10000)
Resolution:
It took the enabling of Verbose logging to figure out the cause, the give away was the timesheet line delete job, it seems that for some reason the TS Line GUID’s above were causing the failure.
So the solution was relatively simple, identify the Timesheets (and respective lines) and delete them manually.
To that end I ended up creating a couple of SQL scripts;
Script 1:
Identify all projects which exist in the Published Database but not in Draft.
— Query to identify projects in Publish but not in Draft
USE ProjectServer_Published
SELECT PubProj.PROJ_UID, PubProj.PROJ_NAME AS Published, DrafProj.PROJ_NAME AS Draft
FROM ProjectServer_Published.dbo.MSP_PROJECTS AS PubProj
LEFT OUTER JOIN ProjectServer_Draft.dbo.MSP_PROJECTS AS DrafProj ON PubProj.PROJ_UID = DrafProj.PROJ_UID
WHERE DrafProj.PROJ_NAME IS NULL
Script 2:
Identify all Timesheets with lines against projects not in the Draft database.
— Query to identify timesheets with lines against projects not in draft
USE ProjectServer_Published
SELECT MSP_TIMESHEETS.TS_UID, MSP_TIMESHEETS.CREATED_DATE, MSP_TIMESHEETS.TS_CACHED_RES_NAME, MSP_TIMESHEETS.TS_COMMENTS
,RepTSP.PeriodName, RepTSP.StartDate, RepTSP.EndDate
,MSP_TIMESHEET_LINES.PROJ_UID, MSP_TIMESHEET_LINES.TS_LINE_CACHED_PROJ_NAME
FROM MSP_TIMESHEETS
INNER JOIN MSP_TIMESHEET_LINES ON MSP_TIMESHEETS.TS_UID = MSP_TIMESHEET_LINES.TS_UID
INNER JOIN ProjectServer_Reporting.dbo.MSP_TimesheetPeriod AS RepTSP ON MSP_TIMESHEETS.WPRD_UID = RepTSP.PeriodUID
WHERE
MSP_TIMESHEET_LINES.PROJ_UID IN (SELECT PubProj.PROJ_UID
FROM ProjectServer_Published.dbo.MSP_PROJECTS AS PubProj
LEFT OUTER JOIN ProjectServer_Draft.dbo.MSP_PROJECTS AS DrafProj ON PubProj.PROJ_UID = DrafProj.PROJ_UID
WHERE DrafProj.PROJ_NAME IS NULL)
ORDER BY CREATED_DATE
Note: For both script’s replace your ProjectServer_* name, and then run this script against your PUBLISHED database.
Running the 1st script is not mandatory, although it can be useful as in my case it identified a few more projects with this issue. However: Ignore the ‘eGlobal …” project(s) and do not attempt by any means to remove them, you have been warned!
The second script will identify line by line timesheets that need to be edited / deleted before you can delete from Published the problematic project. This needs to be done in the usual ways, probably by the Resource themselves unless using delegation or something similar.
Cause:
Good question! I was not able to identify the root cause of this one, although I did notice it occurring to me during a training session that I was hosting, in fact the issue occurred on the test project I was working on while testing the creation and use of Timesheet approval rules and of course submitting / approving / rejecting test timesheets. However despite that clue I was never able to reliably reproduce the issue, please leave a comment if you have any other ideas!
Hope that helps someone out there!
by Martin Laukkanen | Sep 1, 2010 | Reporting, Troubleshooting
I came across this little annoying issue while creating some linked PPS dashboards where one scorecard item would filter another report by the selected row (in this case a ‘Program Name’ custom field). I was stumped to get the following message when selecting my program:
Error running data source query
After much head scratching I found the problem deep in the logs which for Google’s benefit I will include some server log snippets here:
Log Name: Application
Source: Microsoft-SharePoint Products-PerformancePoint Service
…
Description:
An exception occurred while running a report. The following details may help you to diagnose the problem:
Error Message: Error running data source query.
<br>
<br>
Contact the administrator for more details.
Dashboard Name:
Dashboard Item name:
…
Parameters: Programme A
Exception Message: Error running data source query.
And
PerformancePoint Services error code 10116.
…
<Data Name="string1">Error running data source query.
Microsoft.AnalysisServices.AdomdClient.AdomdErrorResponseException: Query (10, 19) Parser: The syntax for ‘A’ is incorrect.
The problem turned out to be a space in my custom field value name!
Basically the hint was in the Parameter and the syntax, it seems that PerformancePoint fails to send my parameter correctly and as a result it sends ‘Programme A’ as two separate invalid parameters ‘Programme’ and ‘A’, hence the error on “The syntax for ‘A’ is incorrect”.
This was quickly proved by updated the custom field lookup table values to remove any spaces, which after a cube rebuild resolved the error!
Definitely chalk that one down to a little defect hidden in the code somewhere!
by Martin Laukkanen | Aug 6, 2010 | Development, Project 2010
This is a useful solution; with it you can update on a PDP an Excel spreadsheet saved in project’s workspace document library and then potentially update custom fields from the results.
However it is far from a complete solution to download and deploy.
First issue – Admin rights required to use Web-Part:
Installed as per instructions (build / package / run script), then when adding the web part this familiar error occurred:
“An unexpected error has occurred.”
A quick look at the ULS shows more details:
The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security.
Now that’s interesting as I had this exact same issue a few months back working with a 2007 PSI project, it turns out the answer is rather simple; the web service is attempting to write to the event log using “EventLog.WriteEntry” method calls, however in Windows 2008 and above this is restricted to Administrators only. So as the PWA users are not local admins the error was guaranteed.
A quick solution is to comment out each line in the code beginning with “EventLog.” of course that will disable the logging, so you would be better off doing that after you get everything else working. The file in the solution that you are after is CostAndBenefiXlsWebPart.cs in the WebPart.CostBenefit project and you’ll find about half a dozen envent log entries to comment out.
Second issue – The default site template location:
While your in that file commenting out lines, you’ll most likely notice this;
private string pdpSitePath = @”http://project.contoso.com/PWA/MajorPWSTemplateSite;”
Although the solution will work without changing this, as that is only used when no workspace site exists (like when in server settings – project detail pages), updating that to point to your http://server/pwa/template workspace site template will fix any file not found issues when setting up your PDPs.
Third issue – Location of the Excel document used:
If you’ve gotten this far then like me you might be seeing something like this:
No item exists at http://servername/_layouts/xlviewer.aspx?list=b73da3b8-b48e-400c-8fe0-9b6a48442518&id=1&DefaultItemOpen=1&Edit=1. It may have been deleted or renamed by another user.
A little digging turned up the cause of this one to be the embedded ID in that URL “&id=1”, which means that it is trying to open the document with ID 1 in that particular list. This again is hard coded in the same .cs file as above (line 191), so you can either make certain that in your template above the first file saved to the Project Documents folder is your xls sheet, or modify the code again.
All done.
So now we should have a working webpart referencing our Excel sheet saved in the project workspace site, there are some obvious limitations, not least of all the inability to use any other spreadsheet in the webpart. But I guess that’s why they call it a “solution starter”.
Update 23/10/2010: Most of the points above have been fixed in the more recent updates to the solution starter package, make sure you update your code from Codeplex: http://code.msdn.microsoft.com/P2010SolutionStarter
by Martin Laukkanen | Jul 31, 2010 | SharePoint 2010, Troubleshooting
When restoring SharePoint 2010 databases or sites I have recently come across the following problem:
Access Denied to all Sites for all users, including Site Collection Admins.
This appears similar to old 2007 restore issues which were fixed using the STSADM MigrateUser command, however in this case it seems that the STSADM (or PowerShell move-spuser) commands doesn’t fix the issue. And I have definitely made certain to change the Site Collection admin on the restored site collections using Central Admin.
A little investigation revealed that the reason is the use of Claims (or Forms) Authentication in either the source or destination web application, so in my case where my Test environment used Claims (both NTLM and LDAP) but my Prod was only going to use NTLM authentication the restored sites were inaccessible (including PWA!).
Fortunately in my case I found a workaround; setup my new Web App to use Claims, however only enable NTLM authentication, effectively resulting in a pure NTLM setup. However that won’t always work, in fact I have another case where the source data (from an old 2007 portal) is using NTLM and I want to migrate it to 2010 using Claims, in that case another solution will be required.
I plan to investigate further using the "move-spuser" powershell command as that seems to be the solution, it just seems that something is preventing it from migrating the users as expected. I’ll update this blog with my results.
by Martin Laukkanen | Jul 30, 2010 | Project 2010, SQL, Troubleshooting
Came across this issue when building my cube using SQL AS 2005 with 2010 for the first time;
[7/23/2010 9:28 AM] Failed to build the OLAP cubes. Error: Failed to process the Analysis Services database PS2010TestCube1 on the PRJDBCLUSTER server. Error: OLE DB error: OLE DB or ODBC error: Class not registered.
Errors in the high-level relational engine. A connection could not be made to the data source with the DataSourceID of ‘Project Reporting data source’, Name of ‘Project Reporting data source’.
Errors in the OLAP storage engine: An error occurred while the dimension, with the ID of ‘PS2010TestCube1’, Name of ‘Assignment Owner’ was being processed.
Server: The operation has been cancelled.
Fortunately the solution was not too hard to come by; it seems that you need to install the SQL 2008 Native client on the SQL 2005 server in order to fix this one.
Hope that helps someone!
