Introduction to Service Management Automation

Service Management Automation (SMA) is a new component in System Center for process automation.

Before looking into the technical details, let’s have a look at what practical use cases there are for an automation product like SMA:

  • Automate maintenance tasks such as orchestrating patching of Windows Failover clusters, stop and start services as well as starting and stopping virtual machines in a defined order when doing maintenance work
  • Automate business processes such as creating, changing and removing user accounts, password resets and automating file transfers
  • Automating tasks in a service catalog and change management such as creating virtual machines and automatic configuration of backups
  • Dynamic resource allocation based on load or calendar. A practical example might be extending a web farm with additional instances before the Christmas holidays
  • Respond to alarms from operations tools such as System Center Operations Manager
  • Integrations across systems, such as automatically creating an incident in an incident management system based on an event from an operations system

SMA is not a separate component in the System Center suite on the same level as the other components such as Configuration Manager and Virtual Machine Manager; the installation files are included in the installation media for Orchestrator:

image001

As we can see based on the above screenshot, SMA has 3 components:

Web Service – Web API (RESTful OData) used for several tasks–communication with Windows Azure Pack, distribution of runbook jobs to Runbook Workers, as well as delegating permissions.
Runbook Worker – Executes runbook jobs. These might be scheduled or triggered manually.
PowerShell Module – Cmdlets for administering SMA.

In addition, a SQL database is needed to store data (needs to be specified during installation). From an architecture level there are similarities between System Center Orchestrator (SCO) and Service Management Automation (SMA). The main difference in the user experience is that SCO has a graphical interface with drag-and-drop support, while SMA is 100% based on Windows PowerShell Workflow.

PowerShell Workflow, introduced in PowerShell 3.0, is built upon Windows Workflow Foundation. PowerShell Workflow makes it possible to orchestrate long-running activities and automate complex tasks, such as deploying a service containing several servers. PowerShell Workflow is capable of executing activities in parallel, resuming execution after a failure (such as network outage) and surviving a restart of a managed node. Details and links to more information about PowerShell Workflow are available in the article «When Windows PowerShell Met Workflow» on the Windows PowerShell Team blog.

Portal

SMA itself does not have a built-in portal; the only way to define runbooks is by using the PowerShell cmdlets or the web service. Windows Azure Pack for Windows Server is a free component for hosting providers and enterprises which provides a user experience consistent with Windows Azure:

image002

One of the components of Windows Azure Pack is Automation, which is based on a connection to the SMA web service. This makes it possible to use the Automation component available in Windows Azure Pack as a web portal for SMA:

image003

The first item we see when entering the Automation portal is the Dashboard, which provides an overview of the defined runbooks.

Runbooks provides a view of all runbooks defined, with options for sorting based on status, tags or search query:

image004

Clicking on a runbook name brings you to a dedicated dashboard for the selected runbook, where statistics for the runbook jobs are available:

image005

Jobs provides history and output for each job instance, which has been executed for the runbook:

image006

Author shows the published version of the runbook:

image007

Draft provides the ability to edit and test the code defined in the runbook:

image008

When you authoring a runbook, the runbook has to start with the keyword workflow followed by the name of the runbook. Optionally a param block can be provided in order to define parameters for the runbook. The actual code is defined after the param block.

If parameters are defined, values for these may be provided when starting the runbook:

image009

These values can also be provided if the runbook is scheduled.
Schedules may be defined in the next menu item:

image010

image011

The last menu item for a runbook is Configure, giving options such as providing a description, tags and enabling debugging and logging:

image012

Debugging and logging will write a lot of data in the database, and should only be enabled during troubleshooting.

The last item we will have a look at in the Automation portal in Windows Azure Pack is Assets:

image013

An asset (also called a global resource) may be a PowerShell module or one of the following:

image014

Connections are connections to other systems, such as other System Center components like Data Protection Manager and Virtual Machine Manager. Credentials, variables, and certificates can be defined in order to avoid hardcoding them in runbooks. The last type of asset is a schedule, which we have already looked at. All assets are globally available and shared among all runbooks.

Architecture

When PowerShell Workflow is used outside of SMA, state («persistence») is stored on a file system on the machine executing the workflow. With SMA we get a highly available workflow, because persistence is stored in a SQL database.

This makes it possible to build a highly available automation platform, by configuring a highly available SQL service (using clustering or AlwaysOn) as well as 2 or more servers with the SMA Runbook Worker and web service installed:

image015

Source of illustration: System Center Orchestrator Engineering Team Blog

At the Build conference in April 2014 Microsoft also announced Microsoft Azure Automation preview, making it possible to leverage SMA without an on-premises automation platform.

Summary

Since SMA is based on PowerShell Workflow it’s possible to automate everything which can be accomplished from PowerShell. Unlike Orchestrator which can be extended by Integration Packs, SMA can be extended using PowerShell modules (they are called Integration Modules).

The first version of the product lacks some functionality available in Orchestrator, such as the ability to configure runbook permissions. This is a feature an enterprise using SMA would find useful in order to delegate access to runbooks based on, for example, Active Directory security groups.

There is no official statement regarding the strategy around co-existence of Orchestrator and SMA in the future, but it’s not unlikely that SMA will overtake Orchestrator’s role in the Microsoft ecosystem when more functionality comes in place.

Resources

Overview of Service Management Automation
Microsoft Azure Automation preview
Windows Azure Pack for Windows Server
Getting Started with Windows PowerShell Workflow
Intro to SMA
SMA Capabilities in Depth

About the author: Jan Egil Ring

Jan Egil works as a Lead Architect at Crayon, Norway. He mainly works with automation, and has a strong passion for PowerShell. He has been working with Microsoft infrastructure products such as Windows Server & System Center since the early 2000s. In the recent years the focus has been more and more related to cloud technologies in Microsoft Azure and hybrid environments. He is a multiple-year recipient of Microsoft Most Valuable Professional Award for his contributions in the Windows PowerShell and Cloud & Datacenter Management technical communities. He speaks regularly at user groups and conferences, such as Nordic Infrastructure Conference (NIC), PowerShell Conference Europe and PowerShell Summit. He is a co-organizer of Azure User Group Norway as well as the MTUG (Microsoft Technology User Group) Script Club which focuses mainly on PowerShell. You can follow him on Twitter @JanEgilRing.

Related Posts