Troubleshooting Workflows in Service Manager

Troubleshooting Workflows in Service Manager

  • Comments 4
  • Likes

I’ve been doing a lot of troubleshooting of Workflows in Service Manager lately as I have been working on some of these extension projects.  It’s not exactly trivial to figure out what is going wrong with a workflow, so I wanted to write a blog post explaining the process.  I’ll also point out a few common causes of workflow failures and the resolutions.

The easiest way to figure out the status of a workflow is to check the Service Manager console.  Go to the Administration workspace (you must be a Service Manager administrator to do this), expand the Workflows node and select the Status view.

image

You’ll see a list of all of the workflows in the system, including the workflow extensions that you may have made with the authoring console and imported into your environment.

image

Here you can get a good idea of which Workflows are currently running in your environment, enabled status, when it was created and when it was last modified.

If you select a workflow item in the list, down at the bottom you will see the history of all the times that workflow has run.  There are two tabs – one which shows only Failures and another which shows All.

image

In the example above, you can see that my workflow has failed twice and it shows the start and end time.  I can also see a few different actions:

  • View log:  This will open a dialog which will show you the log output from that execution of the workflow.  More on that in a minute.
  • View related object: This will open the form for the object that the workflow is running for.  Typically this would be a change request, incident, computer, etc.
  • Retry: Allows you to resubmit the workflow with the exact same configuration.  Be careful with this though as in some cases it may not be appropriate to rerun a workflow given your business logic.  For example, consider this timeline:
    • a workflow failed to run to process an incident –let’s say change the urgency to high
    • in between that failure and now some other workflow has run or a user has modified the incident manually which has changed the urgency to medium
    • At this point – what is the right urgency value – high or medium?  If you rerun the workflow it will change the value to high.  If you don’t it will leave it at the ‘high’ value applied by the other workflow/user.
    • Make sure you understand what it is that your workflow will actually do before you choose to rerun the workflow.
  • Ignore: Dismiss the failure.  You will not be able to retry the workflow after it has been marked ignore.

Now, let’s say you unfortunately have a failure.  Click on the View log link above for the failure you are interested in looking at further and you’ll see a dialog like this:

image

It’s a little hard to notice, but if you expand the Failure details section at the bottom you can see more information about the failure:

image

OK, so that is not super helpful, but in some cases you’ll get better error information here.

This particular error (-2130771925 ; 0x80FF002B) in my experience occurs because the following workflow support assemblies are not copied into the  Service Manager folder (%ProgramFiles%\Microsoft System Center\Service Manager 2010):

  • Microsoft.ServiceManager.WorkflowAuthoring.ActivityLibrary.dll
  • Microsoft.ServiceManager.WorkflowAuthoring.Common.dll

These assemblies ship with the authoring console and must be copied manually to the Service Manager folder on the management server.  Without them many of the workflows you design in the Service Manager authoring console will not work.

So, the dialog you see above is what you will see when the workflow has failed to run completely.  In this case the workflow failed because the supporting assemblies were not present.

If your workflow does happen to run successfully it may not necessarily do what you want it to do.  Take this example:

image

Here, my workflow is running successfully (meaning that it at least completes), but I am not getting the results I expected.  If I take a look at the log in this case I can get a better idea of what is going on.

image

So – this shows me that the workflow started, ran my powerShellScript1 workflow activity and then finished.  Still not enough info!

Time to go digging in the database!

select SubmittedBy, RunningAs, Status, convert(xml,Output), ErrorCode,ErrorMessage, TimeScheduled, TimeStarted, TimeFinished

from JobStatus

order by TimeFinished desc

Find the error you are interested in by filtering the data using WHERE and ORDER BY clauses on the table.  For example, filter it down using time range so there isn’t so much data returned in the results.  Remember – all time is stored in the database in GMT/UTC.

Then click on the Output link in the results:

image

 

You’ll see a bunch of XML that looks something like this:

image

It looks like a bunch of complicated data, but it can be really invaluable for figuring out where in the process a given workflow is failing.  For example, this particular error pops right out to me:

image

In this case, I had provided a computer name for the parameter on the workflow activity which couldn’t be resolved (my error).  This piece of information gave me the information I needed to figure out what was going wrong in my workflow.

Especially for workflows which use the PowerShell script activity, I recommend writing out to the Standard Out (write-host cmdlet).  Anything written to Standard Out will be captured and stored in the job status table.  This can be invaluable for troubleshooting workflows.

Here is an example of the output written by one of my PowerShell activities:

image

Another way to check on workflows is to check the Operations Manager (yes, it’s called Operations Manager – it’s a long story) event log on the management server.  In this case, I was getting events with Event ID 4000 from the HealthService source.

image

Hope that helps!

-Travis

Follow me on Twitter! (http://www.twitter.com/radtravis)

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Excellent set of instructions, thanks!

  • Hi Travis,

    I was using your solution for CSV connector but have following challanges.

    If a tried to seal the MP and use it it got imported succesfully but when tried to make connector it was showing error "Object reference not set to a reference of the Object." in the last tab of the Create Connector Wizard.

    Also i would like to know if i would be able to change the name of the MP as we need a standardized name for our environment

    Please share your thoughts

    Thanks

    Gaurav

  • What does it mean when the ImportADUserDataRule doesn't exist? It doesn't appear that my AD connector is automatically syncing, it only gets new data if I click on the connector and click "Synchronize Now".

    Is there a documented list of what workflows should be created out of box? For example, we are also not getting any email notifications (its configured). So I am wondering if there is workflow missing for this also?