Using Azure and SMA to Automate Your Environment



In today’s corporate world, the word automation has become synonymous with efficiency — a buzzword that is thrown around amongst executives to help secure funding for projects in the coming quarter, often oversimplified in ways that set said project at a disadvantage before it even begins. The good news is that once you figure out the solution that works for your environment, it can easily be used to automate a variety of different tasks.

The Problem

Before understanding the solution, we need to understand the problem. For most Windows administrators, automation of specific tasks can easily be done using PowerShell. For example, you could use Task Scheduler to periodically clear temp files on your machine with the code below.

function Clear-TempFiles {
        Clears temp files located in the pre-configured paths. 
        This cmdlet deletes any and all files located in the pre-configured paths.
    $tempfolders = @(
    Remove-Item $tempfolders -force -recurse

The challenge is not in the development of the code itself; rather, it lies in the complexities introduced with enterprise-level tasks. You may need to work with systems such as Active Directory, various ticketing systems such as ServiceNow or BMC Remedy — maybe even your endpoint management system (such as SCCM). Sure, all of this can still be done with PowerShell. But how do you keep track of when your code executed successfully? How can you ensure that it is highly available? After all, you don’t want to go through all the effort of automating a task just to receive a call in the middle of the night because a server admin rebooted the box you had your code running on.

The Solution

This is where orchestration comes in. An orchestration suite is a set of tools used to arrange and coordinate automation in a way that results in a consolidated workflow. There are a variety of different solutions available that do this, most of which provide features that address the concerns of high availability and redundancy often found at the enterprise level. In the Windows stack, the easiest solutions to integrate with are:

  1. System Center Orchestrator
  2. Service Management Automation (SMA)

Which Should I Use?

Both of these tools are similar in that they look to solve the same problem. However, Orchestrator takes a graphical approach to solution development; SMA relies heavily on PowerShell. While there is simplicity in Orchestrator’s implementation (think of a Visio chart that actually does things), it limits itself in that for any given task in your workflow, you need to have an integration pack that enables it. This works out when you have to work with larger vendors who may already provide said integration packs for their product. But when you need to work with proprietary systems, your ability to automate becomes restricted. SMA, on the other hand, is a lot more robust.

Anything you can do in PowerShell can essentially be accomplished through the SMA platform. That being said, the best solution is the one that best fits your specific requirements. My preference will always be SMA, but if you prefer a graphical development process, Orchestrator is your answer.

What is a Runbook?

As you gain familiarity with SMA, you will hear the term runbook. An SMA runbook is a block of code that is used to automate a desired task. While often used as a generic term, there are actually two different types of SMA runbooks:

  1. PowerShell Runbook
  2. PowerShell Workflow Runbook
  3. Powershell Runbooks are essentially PowerShell scripts. You can use any existing scripts you’ve already developed and upload them to SMA as runbooks. While a little more complex, PowerShell Workflow runbooks provide additional functionality that may be desirable, depending on your requirements (specifically, the ability to perform multiple actions in parallel and use checkpoints to resume runbook execution in case of any errors that may occur). The one downside to PowerShell Workflow runbooks is that they take longer to start since the workflow needs to be compiled prior to execution.

    SMA Architecture

    So how does SMA work? There are three main components to the SMA Architecture:

    1. Web Service
    2. Runbook Worker
    3. PowerShell Module

    The Web Service is essentially the system manager. It is responsible for distributing runbook jobs to the various runbook workers that may be configured, and also enables administrators to control access via security groups. The runbook workers execute the assigned jobs under the context of the configured service account. Lastly, the PowerShell module enables management of the SMA system using PowerShell cmdlets. Optionally, SMA can also integrate directly with the Windows Azure Pack to author and manage your runbooks.

    source: https://docs.microsoft.com/en-us/system-center/sma/architecture-of-service-management-automation?view=sc-sma-1807

    What’s Next?

    Now that we understand the need for an orchestration solution such as SMA, how do we get started? The first step will always be requirements gathering. What kind of traffic are you expecting to see in your SMA implementation? Does it have to be highly available? Is disaster recovery a concern? All these questions will guide you in your design of an effective SMA environment. Your next step will be setting up a proof of concept. Part 2 of this post will cover just that, in addition to a few other key items:

    1. Setup and configuration of a POC environment
    2. Authoring/managing runbooks using both Windows Azure Stack and SMA PowerShell Modules
    3. Discussion of real world automated solutions that can be facilitated through SMA

Nicholas Almiron is an IT generalist whose background has a foundation in endpoint administration as well as development of automation solutions in an enterprise environment. He consistently strives to expand his knowledge and has a particular interest in solving problems with complex solutions.


Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *