Cascade Skyline - with Microsoft Logo and Project Support header - author Brian Smith

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: An unknown error has occurred in Project Center, Resource Center or Tasks

    • 10 Comments

    Thanks to my friends at one of our great TAP partners for this resolution. I love it when customers solve their own problems, and love it even more when they tell me about it so I can tell you.  Happy to give them credit for the resolution too – but only when I hear back from them that they are ok with the glory… ***Update *** and have the all clear to name Accenture, and Kranti Deshpande.  Thanks for all you work on the TAP and beyond!

    The error is in red text where the grid should be – and isn’t a normal pop-up that you’d expect from SharePoint, but just text.  This appears on the Project Center, Resource Center and also Tasks and Timesheet pages

    image

    No scripts errors, but I did find some useful things in the Event Log when I reproduced the error.  I have copied this at the foot of this blog – mainly there for the search engines, but Event ID 3, WebHost is the important piece. Nothing jumped out at me from the ULS logs – I think this is more an IIS to client issue rather than SharePoint – but I did see some http binding messages (BasicHttpBinding) at about the right time

    The issue was that in IIS Manager the Authentication for the site was set to use Windows Authentication, but in the Advanced Settings, Extended Protection was set to a value other than Off.

    image

    Just setting back to Off resolved the issues – and no IISReset required.

    And for the search engines – the error…

    Log Name:      Application
    Source:        System.ServiceModel 3.0.0.0
    Date:          7/2/2010 3:44:42 PM
    Event ID:      3
    Task Category: WebHost
    Level:         Error
    Keywords:      Classic
    User:          domain\user

    Computer:      servername
    Description:
    WebHost failed to process a request.
    Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/19339735
    Exception: System.ServiceModel.ServiceActivationException: The service '/_vti_bin/PSI/ProjectServer.svc' cannot be activated due to an exception during compilation.  The exception message is: The extended protection settings configured on IIS do not match the settings configured on the transport.  See inner exception for details.. ---> System.NotSupportedException: The extended protection settings configured on IIS do not match the settings configured on the transport.  See inner exception for details. ---> System.InvalidOperationException: The ExtendedProtectionPolicy.PolicyEnforcement values do not match.  One policy has a value of Always, while the other has a value of Never.  These values must match exactly.
       --- End of inner exception stack trace ---
       at System.ServiceModel.Channels.HttpChannelListener.ApplyHostedContext(VirtualPathExtension virtualPathExtension, Boolean isMetadataListener)
       at System.ServiceModel.Channels.HttpTransportBindingElement.BuildChannelListener[TChannel](BindingContext context)
       at System.ServiceModel.Channels.BindingContext.BuildInnerChannelListener[TChannel]()
       at System.ServiceModel.Channels.MessageEncodingBindingElement.InternalBuildChannelListener[TChannel](BindingContext context)
       at System.ServiceModel.Channels.TextMessageEncodingBindingElement.BuildChannelListener[TChannel](BindingContext context)
       at System.ServiceModel.Channels.BindingContext.BuildInnerChannelListener[TChannel]()
       at System.ServiceModel.Channels.Binding.BuildChannelListener[TChannel](Uri listenUriBaseAddress, String listenUriRelativeAddress, ListenUriMode listenUriMode, BindingParameterCollection parameters)
       at System.ServiceModel.Description.DispatcherBuilder.MaybeCreateListener(Boolean actuallyCreate, Type[] supportedChannels, Binding binding, BindingParameterCollection parameters, Uri listenUriBaseAddress, String listenUriRelativeAddress, ListenUriMode listenUriMode, ServiceThrottle throttle, IChannelListener& result, Boolean supportContextSession)
       at System.ServiceModel.Description.DispatcherBuilder.BuildChannelListener(StuffPerListenUriInfo stuff, ServiceHostBase serviceHost, Uri listenUri, ListenUriMode listenUriMode, Boolean supportContextSession, IChannelListener& result)
       at System.ServiceModel.Description.DispatcherBuilder.InitializeServiceHost(ServiceDescription description, ServiceHostBase serviceHost)
       at System.ServiceModel.ServiceHostBase.InitializeRuntime()
       at System.ServiceModel.ServiceHostBase.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.ServiceHostingEnvironment.HostingManager.ActivateService(String normalizedVirtualPath)
       at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath)
       --- End of inner exception stack trace ---
       at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath)
       at System.ServiceModel.ServiceHostingEnvironment.EnsureServiceAvailableFast(String relativeVirtualPath)
    Process Name: w3wp
    Process ID: 4580

    Technorati Tags: ,
  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Don’t Trash the Cache!

    • 44 Comments

    I was going to use the title asking ‘why are people still deleting the cache?’ until my colleague Corrie came up with this much better one!  Rather than asking why you are still doing it – I am telling you not to!

    I know there is a lot of history behind this one, and for those of you that used Project Server 2007 in its early days there were some challenges such as the ‘check-in pending’ saga that got people in to the habit of deleting the project cache.  We fixed the problem, then we fixed it again (and again) and you should not generally be seeing any issues with leaving your cache alone to do its job.  However, many customers I talk to are routinely deleting the project from the local cache before they open it and then again after they close it! Why!?!  Its job is an important one – it saves you having to pull that data from the server again – which will reduce network traffic, the hit on both the web services and the database, which means they can be getting on and doing useful stuff.

    I’ll also address a miss-conception misconception (thank you Trevor - not addressing the misconception that I can spell...) here that I have heard from a number of customers – the choice of where to load the project from – cache or server?  You don’t have a choice – Project will load it from the cache if it is there, and then load any incremental pieces it needs from the server, to get you the current version of that plan.  In the screen shot below:

    image

    the line actually reads ‘Retrieve the list of all projects from Project Server’.  It does not also read – ‘…and open any I might choose after clicking this link from the server and ignore the local cache’.  You don’t get the choice and you don’t need to choose.

    I’m sure many of you will not have read this far before clicking the comments option to tell me of all the problems you are having.(and I’m sure some of you are still having problems).  First check that you have the latest cumulative updates and service packs.  If you are still really having issues unless you delete the local cached copy then we certainly need to hear about it so we can fix the problem rather than have you waste your time and system resources doing things that you should not need to do.

    I will admit that there can be times when as support engineers we will ask you to remove your local cache to troubleshoot specific scenarios.  The cache itself also has intelligence that allows it to decide that it may have some bad stuff – and it will get a new clean copy of data from the server (symptom of this will be several files in the cache directory with 1,2,3 etc. at the end).  There have also been a few bugs we have worked on recently which ONLY surface when the user has cleared their cache!

    So please, if you have been deleting your cache as a matter of routine, then either stop – or speak to your PMO or IT people and ask why they have you do this – and if we need to fix something else then we can take a look.

  • Brian Smith's Microsoft Project Support Blog

    To Add or Update - That is the Question. The PSI and custom fields - Updated

    • 49 Comments

    This posting was inspired by a support call concerning custom fields - but does apply to other entities in the Project dataset and others.  The question was around the QueueUpdateProject and QueueAddToProject web services calls that are part of the Project web service in the PSI.  If you use the wrong call then the error message is usually helpful telling you you can't add with the update call and vice versa.  But the thing that does catch people out are the custom fields... 

    By default a project dataset will not contain any rows in the ProjectCustomFields data table unless they have either been set (through PWA, Project Professional or the PSI) or they contain formulae, or are based on a lookup table with a default value defined.  So for a freshly created project (from Project Professional) when looking at Project Information it appears that all custom fields are there - and some may even look to have values (number fields will show 0) whereas in fact once saved there are no rows in the dataset for project custom fields (except as mentioned above - formulae based, and default lookup tables values).  So if you want to set a custom field via the PSI your code should check if there is a row already present for that custom field (identify by the MD_PROP_UID or MD_PROP_ID) and if it is there then you can change the value and use QueueUpdateProject - and if it doesn't exist then you will need to create a new blank project dataset and add a new project custom field row and set the values (including a new GUID for CUSTOM_FIELD_UID, the projects PROJ_UID and the MD_PROP_UID for the field you want to set) then use the QueueAddToProject.

    (Update - Although this logic holds true for adding/updating tasks to a Project dataset you can in fact ADD a new custom field row to an existing project dataset and use the QueueUpdateProject method - and it will work.  You do not need to use the QueueAddToProject method - although this will work too, assuming it only contains the additional custom field row!  Thanks to Martin for pointing this out - through experience.)

    Just to confuse the situation we have a bug currently when using the PSI or creating an Activity Plan/Proposal that can duplicate custom field rows.  If you have any project level custom fields that use graphical indicators but do not have formulae then you can get duplicate custom field rows created for each of them.  I'm not sure yet if the bug is they get created at all (as they do not get created in Project Professional projects) or that they appear twice. I will post an update when I have more information.  For now a quick workaround is to not use graphical indicators for this type of field.  Cleaning up existing ones may be a little more challenging and I would suggest a support call.  Although this causes problems for the PSI when updating these duplicated rows (so this affects changes for Activity Plans , Proposals and use of the Edit Project Properties in PWA) you can still make changes in Project Professional through the Project Information dialog.

    The errors you might see - (these are generic so you could see these errors for other root causes):-

    When updating a custom field for an Activity Plan or Proposal you will get an error dialog box:-

    Windows Internet Explorer
    An error has occurred when saving your project to the server. Please contact your system administrator for assistance.
    [GeneralUnhandledException]

    When updating a custom field through Project Center's Edit Project Properties option the error will display at the top of the page in red:-

    The project could not be saved due to the following reason(s):

    An unknown error has occured (occurred is mis-spelled in the error).

    When updating through the PSI this will result in a GeneralUnhandledException.

    One final point - setting or updating a project custom field for an existing Project Professional created project through the PSI or Edit Project Properties will also introduce this problem.  The extra duplicates will get added as well as the custom field you are setting.

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Orphan baselines breaking the reporting publish

    • 19 Comments

    *** Update 7/31/2013 - This was fixed in the June 2012 Cumulative Update for Project 2010 – and was a client fix - http://support.microsoft.com/kb/2598351.  Customers can load the latest Cumulative Update for Project 2010 and it will include this fix.  The fix will stop the problem happening again but does not fix up any existing issues – so they may need to clean up the database using the guidance below.  If you need help then open a support incident with us – we do not charge for bug related incidents – so we can help you through this.  You should also use the feature on the server to control which patch level  of Project 2010 can connect to Project Server to ensure that this problem is not re-introduced by a user with an unpatched version of Project 2010. ***

     

     

    This problem has been around for a while and I know some customers were running into it very soon after the release, but we had been struggling to get a repro and understand exactly what was causing it.  We now understand the root cause and have a fix coming hopefully in the June 2012 Cumulative Update for Project Professional 2010 (no promises – but that is the current target) and there are some ways of working that can limit your chances of running into this – so decided we should share this to avoid continued inconvenience until we get the fix out there.

    First lets take a look at the symptoms.  The most usual indication of the problem, as the title suggests, is orphan baseline values leading to the error when publishing – a Failed But Not Blocking Correlation problem on a Reporting (Project Publish) job that will show several of the following errors if you click through for the error details:

    ReportingProjectChangeMessageFailed (24006) - The INSERT statement conflicted with the FOREIGN KEY constraint "FK_MSP_EpmTaskBaseline_ProjectUID_TaskUID". The conflict occurred in database "ProjectServer_Reporting", table "dbo.MSP_EpmTask". The statement has been terminated..

    GeneralQueueJobFailed (26000) - ReportingProjectPublish.ReportProjectPublishMessageEx

    These failures are for the reporting job – so will mean that reports based on the reporting database, and any fresh OLAP cube builds could be missing data.

    Sometimes there may also be a crash on saving, either with a fairly generic MSSOAP 16 Send Incomplete error from Project Professional 2010 (though a subsequent save will work fine), or from PWA a queue error -

    GeneralQueueException (9131) A Project Operation failed due to a Queue Exception. Sub Job ID is: . Exception details are: System.NullReferenceException: …at Microsoft.Office.Project.DataEdit.Assignments.AssignmentCalendarUpdateHelper.ConvertActualContourToElapsed(,,,

    There may then be issues with users accessing timesheets – The view failed to load.  Press OK to reload this view… (and OK will not help).

    image

    The error that will be found in the ULS logs will refer to a Calendar whose UID cannot be found…

    Exception occurred in method Microsoft.Office.Project.Server.BusinessLayer.Statusing.StatusingGetMyWorkForGridJson System.InvalidOperationException: CacheProjectBaseCalendars could not find project calendar for project. CalUid=0c13de33-2a07-4310-b091-c77990d9dd6a   

    The root of all these issues is that when you use any of the Save & Send options (XML, CSV, Excel etc.) that we are incorrectly changing some of the GUIDs associated with entities such as the tasks and calendars.  Now this isn’t affecting the main tasks and assignment GUIDs as these bad values are not persisted back to the database – but we do however create a new baseline for these non-existent new task GUIDs, and can also save a bad calendar GUID – which leads to the Timesheet problem.

    First the best way to avoid this issue, and then on to the detection and clean up at the database level.

    If you do need to use Save & Send then the best practice until we release the fix for this is to first save the plan to the server, and publish if you need to.  Then do whatever you need to with Save & Send, and then immediately after this – close and check in the plan – but do not re-save to the server.  Discard changes if it asks – but of course you will have needed to save BEFORE you did the Save & Send (just making sure you are paying attention) to avoid losing any changes you really needed.  As the bad stuff will also get persisted to the local cache, this is one of those rare occasions when you will find me suggesting that the project is removed from the local cache – after ensuring that the save and check-in completed successfully.

    WARNING – the following steps are direct queries against the Project Server databases – please be sure you are working against the right databases when using these – and have a database backup should any problems occur.

    The detection of this condition is pretty straightforward, as we are just looking for baselines that exist for a task that does not exist, so the following query executed against the Draft database will do this (Change the name to match your specific DBs – the default ProjectServer_ names are used below:

    -- Detect for orphan baseline task records that can cause reporting publish job failures.

    USE ProjectServer_Draft -- specify the appropriate draft database

    select PROJ_NAME, MTB.PROJ_UID,TASK_UID,TB_BASE_NUM from MSP_TASK_BASELINES MTB
    inner join MSP_PROJECTS MP on MTB.proj_uid=MP.proj_uid
    where TASK_UID not in (select TASK_UID from MSP_TASKS)

    This will return rows if the condition exists – and identify which projects – as before clean-up you will probably want to get them removed from the PM’s local cache as otherwise they could be re-introduced.

    The next scripts do the cleaning up in the DB, and they are simply deleting baseline records where the tasks are non-existent.

    -- Script to run on the draft DB
    USE ProjectServer_Draft -- specify the appropriate draft database

    delete from MSP_TASK_BASELINES where TASK_UID not in (select TASK_UID from MSP_TASKS)

    -- Script to run on the published DB
    USE ProjectServer_Published -- specify the appropriate published database

    delete from MSP_TASK_BASELINES where TASK_UID not in (select TASK_UID from MSP_TASKS)

    I hope this helps to understand the nature of the issue and ways to avoid it until the fix comes along.  Our apologies for the inconvenience I know this has caused many of our customers – and hopefully for those who have needed to re-run the clean-up scripts regularly this may give a way to reduce the pain.

    If you need any assistance with these steps then feel free to open a support incident – and when I say free I mean free – this is a bug and we do not charge for incidents that are due to bugs (or we will refund – which amounts to the same thing).

    The ULS log entry associated with the initial Queue errors above (for the benefit of the search engines):

    05/01/2012 11:57:55.67    Microsoft.Office.Project.Server (0x1D74)    0x335C    Project Server    Reporting    atwj    Critical    Standard Information:PSI Entry Point:   Project User: REDMOND\brismith  Correlation Id: e1f4e953-7dea-448a-a528-709075c698bf  PWA Site URL: http://brismith8100/PWA  SSP Name: Project Server Service Application  PSError: ReportingProjectChangeMessageFailed (24006) RDS: The request to synchronize change(s) to project Project UID='216733b0-e194-469a-afc3-9235da4ce4c1'. PublishType='ProjectPublish' failed.  Message: 'ReportingProjectChangeMessageFailed'. Message Body: The INSERT statement conflicted with the FOREIGN KEY constraint "FK_MSP_EpmTaskBaseline_ProjectUID_TaskUID". The conflict occurred in database "ProjectServer_Reporting", table "dbo.MSP_EpmTask".  The statement has been terminated. Error:(null)    e1f4e953-7dea-448a-a528-709075c698bf

    and for the Timesheet error:

    05/01/2012 12:13:29.65    w3wp.exe (0x2444)    0x23D8    Project Server    Task Statusing and Updates    btw9    High    CacheProjectBaseCalendars: could not locate data for calendar 0c13de33-2a07-4310-b091-c77990d9dd6a for project 216733b0-e194-469a-afc3-9235da4ce4c1    e5dd4eaf-551a-469b-a3e0-1f60e2f3d1af

    05/01/2012 12:13:29.85    w3wp.exe (0x2444)    0x23D8    Project Server    General    0000    Exception    Exception occurred in method Microsoft.Office.Project.Server.BusinessLayer.Statusing.StatusingGetMyWorkForGridJson System.InvalidOperationException: CacheProjectBaseCalendars could not find project calendar for project. CalUid=0c13de33-2a07-4310-b091-c77990d9dd6a     at Microsoft.Office.Project.Server.BusinessLayer.TimePhasedDataAccess.CacheProjectBaseCalendars()     at Microsoft.Office.Project.Server.BusinessLayer.TimePhasedDataAccess..ctor(StatusingPageLoadDataSet dataset)     at Microsoft.Office.Project.Server.BusinessLayer.Statusing.ReadStatusTimephasedDataForResource(IList`1 gridChanges, Guid[] vAssnUids, IDictionary`2 assn2proj, StatusingTimephasedPeriod[] tpdPeriods, DateTime tpStart, DateTime tpEnd)     at Microsoft.Office.Project.Server.BusinessLayer.Statusing.<>c__DisplayClass57.<CreateTimephasedDataColumnFiller>b__56(IEnumerable`1 Keys)     at Microsoft.SharePoint.JSGrid.GridSerializer.BuildOutput()     at Microsoft.SharePoint.JSGrid.GridSerializer.ToJson(Serializer s)     at Microsoft.SharePoint.JsonUtilities.Serializer.SerializeToJson(Object o)     at Microsoft.Office.Project.Server.BusinessLayer.Statusing.GetMyWorkForGridJson(JsGridSerializerArguments gridSerializerArgs, String gridChangesJson, String projectAssignmentsMap, Guid viewUid, String timephasedStart, String timephasedEnd, Byte pane, Int32 durationType, Int32 workType, Int32 dateFormat, Boolean clearPersistedProperties, Nullable`1 rowFilterType)     at Microsoft.Office.Project.Server.Wcf.Implementation.PWAImpl.StatusingGetMyWorkForGridJson(JsGridSerializerArguments gridSerializerArgs, String gridChangesJson, String projectAssignmentsMap, Guid viewUid, String timephasedStart, String timephasedEnd, Byte pane, Int32 durationType, Int32 workType, Int32 dateFormat, Boolean clearPersistedProperties, Nullable`1 rowFilterType)    e5dd4eaf-551a-469b-a3e0-1f60e2f3d1af

  • Brian Smith's Microsoft Project Support Blog

    A couple more cube build error messages you might come across.

    • 8 Comments

    A couple more cube build error messages I have seen recently.  The first is related to a time out with Analysis Services 2005 and the clue is that failure will be just over an hour into the build (assuming the timeout is still the default 3600 seconds).  The error is:-

    • Failed to build the OLAP cubes. Error: Analysis Services session failed with the following error: Failed to process the Analysis Services database <cube name> on the <Analysis Server name>  server. Error: Internal error: The operation terminated unsuccessfully
    • Internal error: The operation terminated unsuccessfully. Internal error: The operation terminated unsuccessfully. OLE DB error: OLE DB or ODBC error: Unspecified error. Errors in the OLAP storage engine: An error occurred while processing the 'Assignment Timephased' partition of the 'Assignment Timephased' measure group for the 'Assignment Timephased' cube from the <cube name>  database.

    The first part of the error message will be localized if you are using a MUI - the second will not.

    To resolve the issue set the advanced property ExternalCommandTimeout to a value that will allow the building of the cube.  The default is 3600 (seconds) which is one hour.  Increasing to 36000 will be ten hours.  The value could be increased further or reduced depending if the cube builds within this modified time.

    To change the value of the timeout property go to Management Studio for SQL Server 2005 and connect to Analysis Services.  Right click the server name in the left pane and select Properties.  Check the option to Show Advanced (All) Properties then scroll down to ExternalCommandTimeout.  Change the value in the Value column then click OK.  A restart is not required.

    Another workaround would be to reduce the complexity of the cube build by either limiting dates or removing some or all added dimensions.  This workaround is unlikely to be a workable answer for most customers.

    The fact that a restart of the service is not required leads me to the second error message, which can appear if you do restart and then immediately try another cube build:-

    • Failed to build the OLAP cubes. Error: Analysis Services session failed with the following error: Failed to connect to the Analysis Services server <Analysis Server name>. Error: File system error: Error opening file; \\?\C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Data\DBCUbe260.0.db\0.CryptKey.bin is not a disk file or file is not accessible. Errors in the metadata manager. Processing for the database will be disabled because an error occurred while loading the '<random cube name>' database cryptography key. One possible reason for this error is that the service account has changed. File system error: Error opening file; \\?\C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Data\FarmPWA.0.db\0.CryptKey.bin is not a disk file or file is not accessible. Errors in the metadata manager. Processing for the database will be disabled because an error occurred while loading the 'FarmPWA' database cryptography key. One possible reason for this error is that the service account has changed.

    There may well be other scenarios that give the same error, but for the scenario where you have just restarted the server then just try the build again and all will work. 

    Technorati Tags: Project Server 2007

Page 4 of 93 (462 items) «23456»