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

December, 2011

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Operation still processing–don’t shoot the messenger

    • 7 Comments

    Decided to make this post as we have been getting quite a few questions about this dialog – Operation still processing.

    image

    It can occur in various places within Project Web App and in my case I have made it appear in Project Center by creating a new project based on an Enterprise Project Type (called “Large”) that is using a project template which has around 2500 tasks.  In this case the full text says

    “The Create operation has been queued, but is taking longer than expected to process.  To check the status of the creation queue job, visit the My Queue Jobs page. Once the job has completed, the new Large will be listed in the Project Center.
    Click OK to close the project and return to Project Center.”

    This isn’t an error – I wouldn’t even go so far as to say it is a warning – merely an informational dialog that we programmed to appear in cases where whatever you are doing is taking a little while to happen – usually around a minute or so.  It could be that something has gone wrong – more likely it is just taking a while – so have a look in the queue.  Possibly by the time you have read the message the job has completed.  It could be that you are creating a quite large plan from a template – or perhaps there are other jobs in the queue that mean yours is just waiting.  So this shouldn’t be treated as an error – unless when looking in the queue you find a bigger problem – like I did when writing this posting….  Possibly more on that in another posting if a reboot of my abused server doesn’t make my issues go away.

    *** Update - Turns out in my attempted repro of this condition and using a large template I exposed a bug.  If you have a template of around 1600 tasks or bigger (the exact failure point will depend on other factors - could be as high as 4500) then you may experience a stack overflow when this hits the queue in the Project Create stage.  It will sit there processing for ever - and if you look in the ULS logs you will see evidence that the queue has restarted -

    12/30/2011 07:46:48.20 Microsoft.Office.Project.Server (0x1EF4) 0x2798 Project Server General 8zdb High [SERVICE] ProjectQueueService14: ProcessWatcher signaled 
    12/30/2011 07:46:48.20 Microsoft.Office.Project.Server (0x1EF4) 0x2798 Project Server General 8zdk High [SERVICE] ProjectQueueService14: ProcessWatcher restarting service for f0bf6473-d0bd-4442-8d28-65466f8f6dc0 PID: 8160 

    In the application event logs you will see an event 1000 Application Error followed by one or more Windows Error Reporting event id 1001:

    Faulting application name: Microsoft.Office.Project.Server.Queuing.exe, version: 14.0.6015.1000, time stamp: 0x4d0ffe25

    Faulting module name: KERNELBASE.dll, version: 6.1.7601.17651, time stamp: 0x4e21213c

    Exception code: 0xe053534f

    Fault offset: 0x000000000000cacd

    Faulting process id: 0x%9

    Faulting application start time: 0x%10

    Faulting application path: %11

    Faulting module path: %12

    Report Id: %13

    When the queue restarts it will just attempt the project create again, and after around 4 minutes you will see the same errors repeated. Best open a support incident to let us help you recover from this if you run into it.  So far I am not aware of any customers running in to this.  ***
     

     

  • Brian Smith's Microsoft Project Support Blog

    December Cumulative Update Announced for Project and Project Server 2010 and 2007

    • 6 Comments

    Take a look over at http://blogs.technet.com/b/projectadministration/archive/2011/12/14/microsoft-project-server-and-sharepoint-server-2007-and-2010-december-2011-cu-announcement.aspx for the full details.  Also don’t forget the webcast in January giving you the inside scoop on what we are delivering in these Cumulative Updates.

    TechNet Webcast: Information about Microsoft Project and Project Server December 2011 Software Update (Level 200)

    https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032493964&culture=en-us

    A couple of my favorite fixes – the correction of an earlier problem that saw many non-English sites having English headers on the Project Center, My Tasks and Resource Center pages, and a change to single entry mode behavior so that you do not see unexpected changes to your timesheet entered data.  More about these and all the other fixes on January 10th Webcast with Adrian Jenkins and me.

  • Brian Smith's Microsoft Project Support Blog

    Project 2010: Events now raised by changes in Project Information dialog

    • 0 Comments

    This will be the first of a couple of postings about some changes in behavior that you might see once you install the December Cumulative updates.  This one is specifically about the client, and the Project Information dialog.  In the past if you changed a field value within the Project Information dialog then this would not raise the ProjectBeforeTaskChange or ProjectDeforeTaskChange2 events.  The values in Project Information relate to the project summary task (Task 0) and in Project 2007 these events would fire regardless of where the change was made.  Now, with the December CU these events are available to you.  However, there are a couple of things you need to be aware of:

    1.  Firstly the event will fire once for the complete dialog, so unlike if you were changing values in the Project Summary task you may need to allow for and have your users prepared for multiple pop-ups (depending what you code does) once they click OK on the Project Information dialog.

    2. If you cancel then you will lose all your changes – so make sure users are aware they may need to go back and check the values if for some reason your code rejected one of the changes.  For example if you popped up a dialog for each change and accepted a couple then rejected one the values that had been accepted get cancelled too.

    3. There appears to be a bug which we are investigating whereby the Project Department field will always raise the event even if it has not been changed.

    I know that we didn’t have the issue with the Department field in 2007 – I will double check the behavior of the second bullet and see if that has also changed since 2007 – and if that should be considered a bug too.

    *** Update - looks like this wasn't the behavior in 2007 - you could cancel any of the individual events and not roll back other changes - so I'd consider this a bug in 2010.  No promises on any fix dates though.

    One workaround to avoid cancelling if you thought the Department field had been changed would be to check if the value has actually changed – something like:

    If ((Field = FieldNameToFieldConstant("Project Departments")) And (NewValue = vOldValue)) Then Exit Function

    should help.

    *** Update - you may also see this same issue with the Notes field.

Page 1 of 1 (3 items)