This is a really useful query because it actually shows you what runbook instances are currently running and on what runbook servers:
SELECT
J.[RunbookId],
P.[Name],
A.[Computer]
FROM
[Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime.Internal].[Jobs] J
INNER JOIN [dbo].POLICIES P ON J.RunbookId = P.UniqueID
INNER JOIN [dbo].[ACTIONSERVERS] A ON J.RunbookServerId = A.UniqueID
WHERE
J.[StatusId] = 1
ORDER BY
P.[Name] DESC
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.
Select Name, LogCommonData, LogSpecificData from POLICIES where deleted = 0 and ((LogCommonData = 1) OR (LogSpecificData = 1))
This is a very useful query to check on the SQL server side which of your enabled runbooks have got logging turned on for Activity Specific data.
If you’ve followed best practice and numbered your runbooks you can make it sort by number, to make it easier on the eye:
Select Name, LogCommonData, LogSpecificData from POLICIES where deleted = 0 and ((LogCommonData = 1) OR (LogSpecificData = 1)) order by Name asc
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.
Where you’ve got high volumes of orchestration jobs and you don’t have quick access to the Orchestration Console, the following query run in SQL Management Studio against the SQL DB to can help to see if and where there’s any backlogs building up.
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
This will display jobs currently running for each runbook.
You can edit the query to get different data, i.e. jobs completed. Just change the WHERE clause.
0 = Pending
1 = Running
2 = Failed
3 = Cancelled
4 = Completed
Like most things in life that you want to do – some things can appear daunting until you’ve done them a few times.
This great YouTube video by Travis Wright takes you step by step through creating a CI in SCSM and demonstrates how easy it is.
Once you’ve created a class, you’ll need to populate it. I’ve been doing some great work with Orchestrator and the SQL IP to do just that in real time from a variety of sources. I haven’t done a blog on that yet, so drop me a line if you want some tips on populating CIs using Orchestrator.
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:
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)
SCORCH is a brilliant tool. If you have the right Integration Packs (IPs) installed you can connect virtually any two IT components together almost with ease which is not something to be said lightly.
In a recent project I have done just that – connecting BMC ProactiveNet to Microsoft SCSM using the Kelverion Integration Pack for BMC Event Manager and ProactiveNet and the out of the box Service Manager (SCSM) IP.
This allowed me create incidents from BMC events and create computer CIs in SCSM for each computer monitored in BMC.
Like any tool though, there are some gotchas and caveats that can catch the unaware. I hope that going forward Microsoft will iron out some of the things I’ve noted below, given that they only just bought Orchestrator and integrated it into the Microsoft family (SCORCH used to be Opalis).
Here’s some of the things to be aware of:
Monitors and Metrics 