Share via

Automation–Service Management Automation–Getting Started with SMA Runbooks

  • Article

This blog post is going to cover the specifics around getting setup to use Service Management Automation (SMA) as well as how to import our future examples and fire them off in order to review the solutions in action!  This post should be considered another “staple” in your list of posts to consume as you get acquainted with SMA.   These steps are basic, but important and could prove useful on your journey.

SMA

Steps to Getting Started

The following step by step approach takes you all the way from download/configuration through testing.  The most important pieces are configuration and rights so definitely key in on those areas in the following sections. You can consider these the “6 Steps to Success with Getting Started with SMA”. Open-mouthed smile

Note The steps below reflect the current System Center 2012 R2 Preview experience. If anything changes for the GA release, we will be sure to update this post to reflect the updated experience.

Step 1: Go Download SMA

This step involves going out and getting your hands on SMA.  Refer to our initial intro blog post for more information: Automation–An Introduction to Service Management Automation .   Leverage that introduction post like a blueprint to get all the SMA bits together and installed. You’ll only need to do this once (or as many times as necessary in test/dev) but it is a crucial step.

Step 2: Configure your Environment

Prepare PowerShell within the environment

SMA leverages PowerShell v3 Workflow at its core. Configurations will vary according to your specific requirements and the solutions you are building.  We’ll highlight what we’ve done in future posts around this area for each solution we provide.   However, at minimum you will likely need to run Enable-PSRemoting (within an elevated PowerShell console) on your Runbook Worker(s) and any target endpoints for the solution.

As a guide, here are some useful links for PowerShell Remoting:

Prepare environment for configuration or content requirements

This is the “vary with solution” part of the implementation.  Basically, you’ll need to look at the solution you are downloading, or the solution you creating, and ensure you have placed input files here, and opened ports there, and that you don’t run into the “works on my box” scenario.  Best way to avoid problems is to document requirements or follow the documented requirements.  We’ll be sure to cover specifics for each of our example Runbooks in their respective blog posts - not to worry Smile.  And if we aren’t clear enough, you can also ask us questions – we love that!

Step 3: Download the Example SMA Runbooks

This may be an optional step (if you are creating your own) but I highly recommend you browse out to ourTechNet Gallery Contributions Page and get the example Runbooks we’ve created for SMA.  Again, we’ll point to them in each future blog post with a direct link.

Step 4: Ensure you have an ID with the “Juice”

Verifying Rights/Permissions is another absolutely important step.  This requirement is no different than the one found in our previous post, Automation–Orchestrator and the Exchange PowerShell Activity, that covered this topic for Orchestrator.  The user ID you are leveraging (e.g. creating an Exchange Distribution List, deploying a Virtual Machine, executing a Hyper-V Recovery scenario, etc.) needs to have the appropriate rights to do so.  We’ll cover some tricks on this as needed for each of the solutions we dive into.

Step 5: Import the Runbooks into SMA

This is a fairly straightforward process.  Once you’ve downloaded the example Runbooks, importing is as simple as navigating to your SMA Portal and bringing each Runbook in.

  1. Navigate to your SMA Portal [Example: https://sma01.contoso.com:30091/ ]
  2. Select AUTOMATION from the list of items on the left
    image_thumb5
  3. Select RUNBOOKS from the list of options within Automation
    image_thumb9
  4. Finally, select IMPORT and follow the wizard to import each Runbook that was provided in the download.
    image_thumb11
    Note At the writing of this post, bulk importing is not possible so you will need to import each Runbook one at a time until you are completely finished with the whole lot of them Smile.
  5. Within the AUTOMATION section you should something like the below showing the Runbooks you have imported.  Notice that they will come in with a status of New meaning they have just been imported and are not published.
    image
  6. You’ll next need to edit the Runbooks according to your environment configuration and check them in (they come in by default as DRAFT in the AUTHOR pane. 
    image
  7. Once you are satisfied with the edits and are ready to publish them, select PUBLISH from the actions at the bottom of the screen.
    image
    Note "Publish" does not mean "Start" like it did in Orchestrator. Instead, "Publish" simply means that the Runbook is ready to be Executed (instead of just Tested) and is out of "Draft" mode. Runbooks will need to be Published if they are to be called by other Runbooks.

Step 6: Execute and Test SMA Runbooks

Yeah, yeah, I’m making a huge assumption that you have done everything perfectly and this is just going to work Open-mouthed smile – well – give it a whirl (fingers crossed) and do this in the lab (against non-production targets) first! If it fails, make sure you re-check the process of configuring the PowerShell for Remoting and such (in Step 2 above) – as it is absolutely imperative it is completed correctly.

Executing the Process Runbook

  1. Navigate to the Automation tab (if not already there) and select Runbooks at the top
  2. Select the Process Runbook you wish to execute
  3. Click Start from the actions at the bottom of the console
    image_thumb[14]
  4. Answer YES to the question confirming your Execution of the Runbook (verify you are firing off the correct Runbook before confirming – see below)
    image_thumb[20]
    Note This Process Runbook does not contain Input Parameters (otherwise there would be a prompt for input like in the Test example below).
  5. Click View Job to get details on the status of your execution and review information within the job details screen and troubleshoot accordingly Smile.
    image_thumb[17]

Testing Each Runbook

The SMA console also allows you to execute each Runbook individually to test logic and functionality.  This is not a “test” but a true execution of the PowerShell so use caution – rebooting a server in test here reboots a server (or thousands) for real! Disappointed smile 

  1. With the Runbook in DRAFT, select TEST from the actions provided at the bottom of the screen.
    image
  2. Answer YES to the prompt to execute the Runbook test
  3. Those familiar with Orchestrator have seen something similar in the Orchestrator Silverlight console.  Input your variables for testing and click the check box to test.
    image
  4. Review the OUTPUT PANE just below the Runbook you executed to see the details of the execution
    image

 

That’s it!  In the next posts we’ll dive into examples leveraging the above framework as a step by step template.

Oh, and if you want more examples for SMA and PowerShell v3 Workflow, be sure to check out this list (to be updated as more examples are provided):

And for more information, tips/tricks, and example solutions for SMA, be sure to watch for future blog posts in the Automation Track!

Till next time, Happy Automating!

Comments

  • Anonymous
    January 01, 2003
    Thanks for the feedback Trevor - do you have an actual recommendation (improvement) and example that you are going for with the above example?  We'll be happy to consider it moving forward but the above workflow names fall inline with the samples also provided in the product.

  • Anonymous
    October 11, 2013
    Ouch. The-multiple-dashes-separating-the-adjectives-and-nouns-hurts-my-eyes. Dashes should only separate PowerShell commands like so, for good form: Verb-AdjectiveNoun

  • Anonymous
    October 12, 2013
    Hey Jim, It's really just the Workflow's name that I found hard to read. Most PowerShell commands, even lengthy ones, don't have dashes separating the adjectives and nouns. Of course, having extra dashes is valid syntax, but doesn't follow the general PowerShell practice of "Verb-Noun." A typical PowerShell command might look something like this: Add-ExchangeDistributionListMembers; I don't really know much about the SMA product, so if those names are embedded into that product's samples, maybe you could forward the command naming feedback on to the appropriate team. Cheers, Trevor Sullivan

  • Anonymous
    December 20, 2013
    Pingback from Windows Azure Pack Blog Post Overview on Building Clouds & TechNet - Building Clouds Blog - Site Home - TechNet Blogs

  • Anonymous
    January 06, 2014
    Pingback from Windows Azure Pack Blog Post Overview on Building Clouds & TechNet

  • Anonymous
    March 13, 2014
    Throughout this Success with Hybrid Cloud series, I’ve emphasized the importance of linking private and

  • Anonymous
    May 20, 2014
    Pingback from Success with Hybrid Cloud: Getting Deep – Windows Azure Pack | Dot Net RSS

  • Anonymous
    May 20, 2014
    Pingback from Success with Hybrid Cloud: Getting Deep – Windows Azure Pack | Dot Net RSS

  • Anonymous
    August 07, 2014
    本文是 Brad Anderson “ Windows Server 和 System Center 2012 R2 新增功能 ”精选系列文章的第九部分。这篇文章介绍了 Service

  • Anonymous
    August 14, 2014
    大家好！
    到目前为止，尤其是如果大家阅读本文，那么很可能已经阅读过以下几篇博客文章：

    自动化 – Service Management Automation 简介
    自动化

  • Anonymous
    August 14, 2014
    大家好！
    到目前为止，尤其是如果大家阅读本文，那么很可能已经阅读过以下几篇博客文章：

    自动化 – Service Management Automation 简介
    自动化

  • Anonymous
    August 27, 2014
    原文地址： http://blogs.technet.com/b/privatecloud/archive/2013/08/14/automation-service-management-automation

  • Anonymous
    October 17, 2014
    Thanks for the complementary of the Service Management Automation is a set of tools that is integrated as the Automation extension in Windows Azure Pack for Windows Server.