Orchestrator Job Statuses

When you’re querying the Orchestrator DB for job statuses there’s a useful query to show jobs currently queued for execution. Running this query is a great way to see if any of your runbooks have got queues building up which could lead to problems:

Use Orchestrator
SELECT POLICIES.Name,
cOUNT(*)
FROM [Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs INNER JOIN
POLICIES ON [Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.RunbookId = POLICIES.UniqueID
WHERE ([Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.StatusId NOT LIKE ‘4’)
AND ([Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.StatusId NOT LIKE ‘3’)
AND ([Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.StatusId NOT LIKE ‘2’)
group by POLICIES.Name
order by COUNT(*) DESC

It’s also very useful to know what the different status flags mean so you can tweak the query if required.

  • StatusId is current stats of the job.
    • 0 = Pending
    • 1 = Running
    • 2 = Failed
    • 3 = Cancelled
    • 4 = Completed
Advertisements

Are you sure Logging Is Turned Off in Orchestrator?

If logging is turned on in Orchestrator it can quickly bloat the Orchestrator DB with logged data.

Logging should only really be turned on and off (through the GUI) for troubleshooting and debugging purposes, but it’s easy to forget to turn it off again and tedious to go through all runbooks one by one checking.

So, a quick way to check the status of logging in all your runbooks in one go is running this query against the Orchestrator DB:

Select Name, LogCommonData, LogSpecificData  from POLICIES where (LogCommonData = 1) OR (LogSpecificData = 1) and deleted = 0 order by name

As always, be careful when you’re running commands against DBs.

 

NOTE – There are ways that you can turn off debugging in one go – have a look here for more details

System Centre Orchestrator Release Details since 2012 SP1 – What’s in each Update Rollup

SCORCH 2012 SP1  UR1

No Updates for SCORCH

SCORCH 2012 SP1  UR2

Issue 1 – The Monitor SNMP Trap activity publishes incorrect values for strings when a Microsoft SNMP Trap Service connection is used.

Issue 2 – Inconsistent results when you use Orchestrator to query an Oracle database.

SCORCH 2012 SP1  UR3

No Updates for SCORCH

SCORCH 2012 SP1  UR4

No Updates for SCORCH

SCORCH 2012 SP1  UR5
Issue 1 – The Monitor Service activity does not let the configuration be saved if Monitor Service cannot resolve the hostname that is entered in the Computer Input property. If you try to save the configuration, you receive the following error message:  Connection to the selected computer has failed

Issue 2 – The Compress Files activity does not include files that are in subfolders that match the filter when the Include files in sub-folders option is selected.

Issue 3 – The Send SNMP Trap activity does not send the correct results for certain combinations of values.

Issue 4 – The SNMP Trap Variables are not retained in the correct order after the Properties dialog box is closed and then opened again.

SCORCH 2012 SP1  UR6

No Updates for SCORCH

SCORCH 2012 R2

New – You can install the web service and up to three runbook workers from System Center 2012 R2 Orchestrator Setup program. These can be used as part of the Windows Azure Pack for Windows Server configuration or to enable you to run runbooks and perform other automation tasks using Windows PowerShell cmdlets. For evaluation purposes, you should install a single runbook worker on the same computer as the web service.

New – Windows Server 2012 R2 is supported in this release.

SCORCH 2012 R2 UR1

No Updates for SCORCH

SCORCH 2012 R2 UR2
Issue 1 – After you add more than nine variable bindings to a Send SNMP Trap activity, the variable binding orders change immediately when you exit the Send SNMP Trap Activity Properties dialog box.

Issue 2 – The customer has a runbook that receives alerts from Operations Manager. This runbook passes the fields from received alerts to the runbooks that it invokes. The invoked runbooks consume the alert parameters and populate Variable Bind values in the Send SNMP Trap activity.

Issue 3 – The Monitor Service activity does not allow the configuration to be saved if it cannot resolve the hostname that is populated into the Computer input property. Therefore, if you use a variable or computer group to populate the Computer input property, you receive a “Connection to the selected computer has failed” error message, and you cannot save the activity configuration. This prevents you from using variables or computer groups with this activity.

 

 

 

 

 

 

 

 

 

 

 

 

“The client has been disconnected from the server. Please call ManagementGroup.Reconnect() to reestablish the connection.” Message in Create Incident Runbooks

I have seen this a couple of times where any of the the Orchestrator Runbooks related to SCSM fail to complete OK and show the message in the log:

“The client has been disconnected from the server. Please call ManagementGroup.Reconnect() to reestablish the connection.” Message in Create Incident Runbooks”

Every time it turned out that the clocks between the SCORCH server and the SCSM were out of sync. Correcting this fixed the issue.

 

How to make an array in Powershell to Work with Array Published Data in SCORCH

Recently I’ve had a tricky issue with SCORCH to get some CSV seperated data out of a column of a table and work on each item in the CSV data in turn in SCORCH.

This turned out to be a challenge to do out of the box because the DB activities like to deal with one row of data at a time, so I turned to the web and found a couple of very useful articles:

http://blogs.technet.com/b/privatecloud/archive/2013/06/27/automation-orchestrator-tip-trick-run-net-script-activity-powershell-published-data-arrays.aspx

This link explains how to create an array through powershell and then two ways to return the data back to Orchestrator.

Using the second method described in the article (Array Published Data) I got the data I wanted, but it was not working properly, because my data didn’t have a newline inserted between each item in the array, giving me one big array of 1 data item.

This blog showed me how to solve that problem:

http://www.developerscloset.com/?p=622

$Array = @()
$items = “1,2,3,4”;
$itemlist = $items.split(“,”);
foreach ($item in $itemlist)

{
$Array += $item
}

$Array

The bolded line was the piece of information I was missing.

Some other info I found useful when troubleshooting was to use
$array.count (to show how many items were in my array)