Runbook Execution in Service Management Automation

Updated: May 13, 2016

Applies To: Windows Azure Pack for Windows Server

Requests to start a runbook are performed by the Service Management Automation web service using either the Service Management Portal or the Start-SmaRunbook Windows PowerShell cmdlet. The web service writes this request to the Automation database where it is retrieved by one of the Automation Worker servers. You do not have control over which Worker server will service the request.

The Worker server will create a job that runs on the Worker server that services the request and remotely accesses any computers or other resources that it will work with. This requires the cmdlets in the runbook to be able to remotely access these resources. Alternatively, the runbook can include an InlineScript command in order to use PowerShell Remoting to run commands locally on a target computer. This concept is illustrated in the following diagram.

If a job is suspended or interrupted, it may be resumed on a different Worker server. Because of this, you should be careful about using local resources that are not accessible to all Worker servers such as a file on a local computer. You should leverage Global Assets such as Variables as much as possible for sharing information between Checkpoints.

In order for a runbook to perform its required actions, it must have permissions to access the resources that it works with. Runbooks in Service Management Automation always run in the context of the service account of the Automation Runbook Service. If this account does not have required permissions, then you can use either a Credentials or a Connection global resource in your runbook to run required commands using credentials with the required permissions. These credentials can either be used with a cmdlet that accepts credentials through a parameter or with InlineScript to run a block of code using alternate credentials.

Service Management Automation
Checkpoints