...building hybrid clouds that can support any device from anywhere
Hello Readers! I’m excited to provide you all with some cool new stuff that was introduced recently with System Center 2012 R2. If you haven’t reviewed our Introduction post on SMA, go check it out here: Automation–An Introduction to Service Management Automation to get the “nickel tour” of all the rundown of Service Management Automation (SMA) and PowerShell Workflow.
Once you’ve fully digested that post, this information will make a bit more sense – at least you’ll have the terms fresh in your brain . Another great post to review is the Automation—Service Management Automation – Getting Started with SMA Runbooks where we go through the “6 Steps to Success with Getting Started with SMA” that include setup, configuration, testing and execution of SMA Runbooks in your environment.
For this post I’m going to introduce a collection of example SMA Runbooks that you can use to get acquainted with the platform. Along the way, we’ll dive a bit into some compare/contrast to show how it is done in Orchestrator and how we’re handling the same process in SMA. The Orchestrator content in this article: Automation–Orchestrator and the Exchange PowerShell Activity will be elaborated and this post will show you how to translate that solution into a set of SMA Runbooks. At the end of this post you will be able to see on how things translate from from Orchestrator to SMA.
This post will cover:
First things first, we need to get some pre-requisite stuff out of the way to ensure you have the best chance of success in getting up and running. We’ll be covering the specific configuration items needed to get this example up in running by leveraging the key steps outlined in the Automation—Service Management Automation – Getting Started with SMA Runbooks.
Make sure you have SMA installed. If you haven’t already, refer to our initial intro blog post for more information on that: Automation–An Introduction to Service Management Automation, then come back.
Next we need to get some specific settings done for Exchange and SMA to get this example executing successfully.
The sample Runbooks we are going to review in this post are all located on the TechNet Gallery location here: SMA Example - Build Exchange Distribution List (w/PowerShell v3 Workflow) . Go out and get them downloaded, extracted, and we’ll jump into the process of importing them below.
The user ID you are leveraging for creating the Exchange Distribution List needs to have the appropriate rights to do so. We also need to ensure you can connect to the Exchange environment using PowerShell Remoting.
A way to validate rights for the service account you have created / been given, is to make the same connection to your Exchange server in a PowerShell session as you do with the SMA Runbooks being leveraged. Execute a simple script within PowerShell ISE from the SMA Runbook Worker to validate you have the necessary rights (see below).
You should see something like the below output.
Note This will only validate you can make a connection and that you’ve setup PowerShell correctly for remote access – you need to ensure the account also has the rights it needs (delegated in Exchange) to perform the operations you are going after. I’ll be covering some of the code we used to create the Exchange DL in the overview section below, so you could certainly execute that in this session as validation of rights.
If you have any questions on this process, follow the details outlined here in Step 5: Automation—Service Management Automation – Getting Started with SMA Runbooks.
Once all the Runbooks are imported, you should see within the AUTOMATION section of Windows Azure Pack (WAP) console, a series of (5) Runbooks related to to this project. We’ll get into some best practices in a later post to show you how to organize these Runbooks, but for now you are ensuring you have the following Runbooks in your view (they may span across pages so you may have to click page 2, 3, etc. to see all Runbooks).
Final step is to test the solution in your environment within the WAP console. If you need a refresh on executing SMA Runbooks in WAP, all details on how this done can be referenced in the Automation—Service Management Automation – Getting Started with SMA Runbooks.
Let’s break down each Runbook and talk about how they are all related and key in on some new ideas and constructs to be aware of.
This is the top Process level Runbook that is used to execute the entire process.
Note One thing to keep in mind, the “Contoso Creds” above is an SMA credential variable. Variables (credential or otherwise) are located and created in the RESOURCES section within the AUTOMATION area of the portal. SMA credential variables enable you to create and store PowerShell credential objects as connections to resources in your environment. These can then be referenced by name (as we did above) and leveraged throughout your Runbook execution without hard coding or prompting. Pretty slick!
Process level Runbooks in SMA function the same as they do in Orchestrator. They are the top level Runbook that triggers all the subroutine Runbooks. They essentially control the flow of the Runbook execution. Take a look at this post where we covered Process level Runbooks as part of our best practice series: Automation–System Center 2012 – Orchestrator Best Practice Series–Naming Conventions. To compare / contrast, the above Runbook may look like the below in Orchestrator to accomplish the same task. The highlighted area above would represent variables that would be defined in the Global Settings section within Orchestrator. We’ll use these throughout the execution of the Runbooks, but define them at the top level Process Runbook (much in the same way we do in Orchestrator).
This subroutine Runbook gets an array of users from a text file. This one is pretty straightforward, but essentially we’re just gathering content from an input file.
Note This is where I’d recommend getting a bit fancier than I did . Making a connection to Active Directory and obtaining a list of users or from a CMDB, etc. Static files are rarely a good idea, but they work well for this example.
To compare / contrast, the above Runbook may look like the below in Orchestrator to accomplish the same task.
This subroutine Runbook creates an Exchange distribution list (validates that it doesn’t already exist before creating).
This subroutine Runbook is used to check for the existence of an Exchange distribution list
This subroutine Runbook adds the users gathered from the input file into the targeted Exchange distribution list
That’s it! I hope this post has provided you with a helpful overview of an end-to-end example solution in SMA and how it compares to what can also be accomplished in Orchestrator. Thanks for reading!
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!
Great and very interesting blog. I think it’s also an informative. Thanks for sharing.
I was wondering why you use the $pscomputername and $pscredential parameters of the inline script. In the inlinescript activity you use the $using scope modifier to access the variables exchangeserver and credentials.
Could you elaborate? thanks,
@New York Warehousing - thanks for the feedback. We'll get more examples out as time permits, and we appreciate your interest!
@Stijn -- my response became so big that I've decided to create a blog post on it. That will be coming in the next 24 hours hopefully :).
@Jim - thanks, will wait for the blog post.
After reading my own comment it reads kind of funny. So a small rephrase:
Why use remoting twice?
Once for executing the inlinescript on the exchange server and then creating a session to the same exchange server?
@Stijn C, this will also be detailed as part of the post that will come out tomorrow (I'll update the thread when it releases) but this is the short answer to your question:
Remote management of Microsoft Exchange required us to create a PSSession that had a configuration name of "Microsoft.Exchange". We found that the InlineScript does not allow for this type of PSSession, so we created a remote InlineScript connection to the Exchange server, and then leveraged a Microsoft.Exchange PSSession to execute the cmdlets within an Invoke-Command.
As always, there are many ways to get to the same conclusion. You may also have find an alternate approach to what we've done and you can share that as well here - I'd encourage in fact. The blog post tomorrow in the AM PST, will cover "$Using:Variable" as well as leveraging the credentials variables in SMA. Probably beyond your question but it sparked a good topic to share either way :).
@Stijn - the related blog post covering $Using:Variable and InlineScript has been posted here: blogs.technet.com/.../automation-service-management-automation-tip-trick-leveraging-inlinescript-and-using-variable-with-powershell-workflow.aspx
Thanks again for the feedback and questions. If nothing else, the above post will help drive home some concepts around workflow in a bit more detail.
Gorgeous post ,An amazing article once again I am wondering the code is well written you effort and blog both are admirable thanks dude give awareness by this post .Click here