The unpleasant question
While deploying Service Management Automation out in the field over the last 2 years, I’m more and more confronted with an unpleasant question:
How can we choose the runbook worker, which is going to execute a particular runbook?
Why would you need that?
If you have a multi-forest environment without trusts and/or an environment with lots of DMZs and other sensitive network zones, you might not be allowed to connect from your regular runbook workers to any of the sensitive target systems. Orchestrator had (still has) the option to execute a particular runbook on a runbook worker of choice.
–> Well, the short answer is: You can’t do that with SMA without creating multiple SMA instances.
But wait, there’s more.
The long answer is: You can’t do it out of the box with the current version. However I wanted to know if there might be a “dirty” way to achieve that. As I did some reverse engineering on how SMA runbook jobs are fired, the SQL traces showed interesting results. There are mainly two stored procedures being executed, when SMA web service triggers a runbook start.
(creates a new job entry and a new job context entry)
(creates a new message to inform the worker about new job)
Therefore I created a little function which takes the required parameters to execute the two procedures via T-SQL. Along with other functions created under the former name “SMAHouseKeeping” I’ve put the runbook calling function into a module called cSMATools which can be downloaded from TechNet.
To have a SMA runbook job executed on a specific worker you simply have to provide the following parameters.
Invoke-cSMARunbook -RunbookName "My-Runbook" -WorkerName "MyWorker" -WebServiceEndpoint https://MySMAWebService
To call a runbook with input parameters, you have to provide them in XML string format.
Invoke-cSMARunbook -RunbookName a_masta -WorkerName smaw002 -RunbookParameters '<Parameters><Parameter name="message" value="Hello World" isValueNull="0"/></Parameters>' -WebServiceEndpoint https://sma01
Any other, “supported”, way?
Yes, there is one. If you’re using Azure Automation you might want to use the concept of “hybrid Workers”, which does basically mean, you’re authoring and calling your runbooks on your public Azure Automation account, but the runbook code itself is executed on a “on premises” worker. Using this architecture you can put one or more worker in a runbook server group. When calling a runbook, you’re able to specify the target runbook group. Having multiple groups enables you to differentiate where code is executed at rest. See here for more information about Hybrid Runbook Worker scenario with Azure Automation.
THE MODULE CODE AND ANY RELATED INFORMATION ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. BE AWARE THAT MANIPULATING THE SMA DATABASE DIRECTLY IS ABSOLUTELY UNSUPPORTED AND IS COMPLETELY ON YOUR OWN RISK.