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.

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

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:

• Enable PowerShell Remoting to Enable Running Commands 
• Configure PowerShell Remoting and Use Remote Commands
• Enable-PSRemoting
• Enable and Use Remote Commands in Windows PowerShell 

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 .  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
   
3. Select RUNBOOKS from the list of options within Automation
   
4. Finally, select IMPORT and follow the wizard to import each Runbook that was provided in the download.
   
   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.
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.
   
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. 
   
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.
   
   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 – 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
   
4. Answer YES to the question confirming your Execution of the Runbook (verify you are firing off the correct Runbook before confirming – see below)
   
   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 .
   

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!  

1. With the Runbook in DRAFT, select TEST from the actions provided at the bottom of the screen.
   
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.
   
4. Review the OUTPUT PANE just below the Runbook you executed to see the details of the execution
   

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

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

Till next time, Happy Automating!