Blogs

KB: Completing an edit in the Service Manager console generates "Failed to execute Submit operation" error

  • Comments 7
  • Likes

eJust a heads up that we just published a new KB article that documents an issue where attempting to complete an edit in the System Center 2012 Service Manager console fails with the following message:

"Failed to execute Submit operation. Fix the reported error before submitting again.
This item cannot be updated because it has been changed by another user or process. To update the item, please close the item and open it again"

You can find the complete article here:

KB2830814 - Completing an edit in the Service Manager console generates "Failed to execute Submit operation" error (http://support.microsoft.com/kb/2830814)

J.C. Hornbeck | Knowledge Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/

App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Are there any plans to make any adjustments to make this issue less impacting?  This happens to us all the time, where workflows change the ticket while we are working on it.  We try to play careful when working on tickets (by never using the Apply button), but no matter how hard we seem to try it always seem to happen some (get hit a lot by "First assigned date", etc. updates handled by workflows).

  • Any plans to change it so it doesn't do this? Allow a popup stating changes are being made before the user edits the object?

  • I would also like to know if this is being addressed? This issue causes a huge amount of pain and a lot of wasted work. The best answer we have seen so far is the workaround to copy and paste information to save what you entered when you get the error. This works in simple edits, but users have to be careful not to do too much to a IR at once when hitting apply or they could potentially have to recreate a lot of work. It just takes too much time to click Ok and reopen the record to make multiple changes.

    support.microsoft.com/.../2830814 - they should update the article to have the "Resolution" changed to "Workaround"

    I'll be honest to mention that I have never seen any other tool or product have this problem. I am also very happy with Service Manger other than this major bug.

  • We have the same problem here, more so when the incident is first raised and our helpdesk team move in to assign the call since during the first 1-5 minutes workflows assign SLO's etc etc...

    We worked out a simple but effective work around, we changed the view criteria to include

    "AND [Work Item] Created date is less than or equal to (relative) [now-6m]"

    This means the call is "hidden" for the first 6 minutes of its life and no more locked errors (or at least reduced dramatically)

    Hope this helps.

  • Thank you all for the feedback. You can be assured that I will post new information as it becomes available.

  • Hi JC,

    Has a fix been released for this yet?  Its driving our users batty.

    For a multi-user application not to correctly handle well, multiple users correctly, is quite astounding for an othewise solid product.

    There are a number of avenues that can be considered for a fix, but can one of them please be implemented soon!!  

    We'd be happy with either of:

    - Dropping the checks back to a (non conflicting) property level

    - Alerting the user opening the form that it is already open by another user so they don't waste time inputting data (or vice versa)

    - Lock the form upon clicking 'apply' while the workflows ran or displaying some type of progress bar

    - even 'last update wins' would be an improvement.

    Currently asking the user to 'copy and paste' all the work they've done just isn't realistic.

  • This is almost a year ago, what is the status on this issue!?