Automation–Service Management Automation–Getting Started with SMA Runbooks

Automation–Service Management Automation–Getting Started with SMA Runbooks

  • Comments 11
  • Likes

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 our TechNet 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!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • 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

  • 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.

  • 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