Integrating Azure Automation with System Center Orchestrator

Azure Automation is evolving fast, and the recent availability of the Hybrid-Worker enables a lot of new capabilities. This allows not only to run runbooks on-premises; it also allows the integration with System Center Orchestrator. This blog post will give you an overview how to trigger Orchestrator runbooks from Azure Automation.

Basically, this scenario follows the same construct how SMA can be integrated with Orchestrator, as Azure Automation works similar as SMA. In short, the scenario will be the following:
An Azure Automation runbook will trigger an Orchestrator runbook on-premises through a Hybrid-Worker – the output will then be returned back to Azure Automation.


Azure Automation Account
System Center Orchestrator

Configure Azure Automation:

At first we need an Azure Automation (AA) runbook that can handle the connection to Orchestrator and trigger Orchestrator runbooks. Happily, this is already available on TechNet Gallery and can be downloaded here -> Service Management Automation Runbook for Starting an Orchestrator Runbook. Actually, it is for SMA, but works for AA as well. The runbook has to be imported to AA – you will then see a runbook named “Start-ScoRunbook” in your AA Account. To make this runbook work, we will have to configure a Connection Asset in Azure Automation that comes with the imported runbook:

Create a new Connection Asset in your AA Account. Select the new connection type named “OrchestratorService” and fill in the details. I recommend naming the Connection “OrchestratorConnection”, as this is the name that is used in the “Start-ScoRunbook” (otherwise you will have to update this runbook to match your configuration).

You will need a service account that has permissions to connect to Orchestrator and execute runbooks. I created an own account for this purpose, which is member of the “Orchestrator users group”.

Now we need an Azure Automation runbook that invokes the “Start-ScoRunbook” and handles the returned values. I also added a parameter, which takes the computer name you want to query on-premises. Together with the runbook path for the Orchestrator runbook (the Orchestrator runbook you want to trigger), this is passed to the “Start-ScoRunbook” where the magic happens:

workflow Invoke-SCORunbook{
    [string] $ComputerName

   $params = @{"Computer" = $ComputerName}
   $paramsObject = New-Object PSObject -Property $params

   $result = Start-SCORunbook `
     -RunbookPath "\AzureAutomation\InvokeInstalledSecurityUpdates" `
     -InputParams $paramsObject


Now we are ready to proceed with the Hybrid-Worker.

Deploy Hybrid-Worker:

You can find a good installation guide for deploying AA Hybrid-Wokers on the Azure Documentation -> Azure Automation Hybrid Runbook Workers


As the last step we need an Orchestrator runbook that we can trigger from AA. You can create any runbook you want – I just used a simple one, which basically queries the installed hotfixes of an on-premises server and returns the results back to the Azure Automation runbook:

The “GetInstalledSecurityUpdates” runbook is actually doing the job, which takes a computer name as input, executes the powershell script and returns the output.

The “InvokeInstalledSecurityUpdates” runbook, is the runbook that is triggered by AA through the hybrid-worker, which then invokes the “GetInstalledSecurityUpdates” runbook. You can trigger the “GetInstalledSecurityUpdates” directly, but in my case I used the “InvokeInstalledSecurityUpdates” to define different credentials for the “GetInstalledSecurityUpdates” runbook, to provide permissions on other systems.

That’s everything you need. Go to the Azure Portal, start the “Invoke-ScoRunbook” runbook and wait… If everything works fine you may see something like this in the job-output:

Leave a Reply