...building hybrid clouds that can support any device from anywhere
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.
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.
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.
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:
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!
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.
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.
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.
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.
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!
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!
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.
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.