...building hybrid clouds that can support any device from anywhere
Hello Readers and Viewers!
By now, especially if you are reading this, you likely have seen the following blog posts:
If not, I highly recommend you take some time and review the introductory content provided. The content in this blog post mini-series requires prior installation and/or knowledge of Service Management Automation (SMA), so those posts are pretty valuable, and actually should be considered pre-requisite materials.
This is Part 1 (of 2) in my mini-series for the SMA Runbook Spotlight on Virtual Machine Startup by Priority. Originally this was just going to be a single post with a simple example for “Virtual Machine Startup by Priority” leveraging PowerShell v3 Workflow and SMA. Then I discovered a slightly more complex (and elegant) way to accomplish the same task – So why not provide both examples as stepping stones from Orchestrator to SMA and PowerShell v3 Workflow?
That is right, like Jim, this blog post (as well as part 2) will not only contain new SMA/PSv3 Workflow examples but also the bridge from Orchestrator to SMA through the example itself.
Remember this post? Automation–Orchestrator Runbook Spotlight–Virtual Machine Startup by Priority
If not, check it out, because what comes next will take that example from Orchestrator to SMA…
First things first - as I stated above, we need to get some pre-requisite stuff out of the way. The following will cover 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.
Because access to VMM will be via PowerShell Remoting, there are some simple pre-requisite steps that need to be taken care of (as well as some example specific configurations for a VMM Cloud and VM Startup Delay):
The example Runbooks can be found here (TechNet Gallery contribution):
SMA Example - Virtual Machine Startup by Priority (w/PowerShell v3 Workflow) Download this ZIP and extract the PowerShell files to a location accessible by the Windows Azure Pack (WAP)/SMA console for import. The import process is outlined below.
The account used for the connection to VMM and the Startup of VMs needs to have the appropriate rights to do so. The connection from SMA to VMM using PowerShell Remoting also needs to be validated.
A simple way to validate rights and connectivity for the account being used, is to make a similar connection to VMM with a remote Invoke-Command. Execute a simple script within PowerShell ISE from the SMA Runbook Worker machine to validate the necessary rights (see example):
Note Because SMA leverages PowerShell v3 Workflow the Invoke-Command call will need to change to an InlineScript call.
Connection to and specific VMM Server information should be seen if the test was successful – see the following example [successful] output:
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 imported, a series of (3) Runbooks related to to this project should be visible within the AUTOMATION section of the WAP/SMA console. Validate the following Runbooks can be seen (they may span across pages so you may have to click page 2, 3, etc. to see all Runbooks).
The final step is to reconfigure the Runbook variables to match your environment and test the example solution within the WAP/SMA console. If you would like more information on executing SMA Runbooks in WAP/SMA, further detail can be found here in Step 6: Automation—Service Management Automation – Getting Started with SMA Runbooks post.
The following section will outline each of the Runbooks included in this example solution, and how they compare to their Orchestrator counterparts.
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.
Process level Runbooks in SMA function the same as they do in Orchestrator. They are still top level Runbooks that invoke all the subroutine Runbooks. They essentially control the flow of Runbook execution. Take a look at the following post where process level Runbooks are detailed as part of our best practice series: Automation–System Center 2012 – Orchestrator Best Practice Series–Naming Conventions.
The idea for this SMA Runbook originally came from the Automation–Orchestrator Runbook Spotlight–Virtual Machine Startup by Priority blog post and related Orchestrator example. As can be seen from that post, while the look is different, the functionality is the same. So you don’t have to jump back and forth between posts, here is a look at Orchestrator Runbook for this same process level portion (Start-VMs-by-Priority) of this SMA solution example:
Note The highlighted portion of the above SMA Runbook (PowerShell script) would represent variables that would be defined in the Global Settings section within Orchestrator.
Just like Orchestrator, these variables are used throughout the execution of the SMA Runbooks. Due to the nature of SMA (PowerShell v3 Workflow) these variables are simply defined here in the process level Runbook and passed as needed to the subroutine Runbooks. Also, much like Orchestrator, these variables can be stored like Global Settings, but for SMA they are stored in the RESOURCES section within the AUTOMATION area of the portal. This example simply leverages one SMA Credential Variable and no other SMA Variables – usage of the SMA Variables is up to you based on your solution requirements.
This subroutine Runbook gathers a list of VMs based on an identified VMM Cloud.
The highlighted portion of the below process level Orchestrator Runbook represents the scope of this subroutine level portion (Get-Cloud-VMs) of this SMA solution example:
This subroutine Runbook takes a list of VMs and starts them based on their specific VM configuration.
Thesubroutine level Orchestrator Runbook below represents the subroutine level portion (Start-VMs) of this SMA solution example:
While the following screen captures originally came from the Automation–Orchestrator Runbook Spotlight–Virtual Machine Startup by Priority blog post, they are directly related to the “Update the “Delay start up (seconds)” Values for each VM” pre-requisite item above, and thus are provided for convenience here:
VM - spftest03 (Priority 3):
VM - spftest02 (Priority 2)
VM - spftest01 (Priority 1)
That’s it! I hope this post has provided you with a helpful overview of another end-to-end example solution in SMA and how it compares to what could also be accomplished in Orchestrator. Thanks for taking a look!
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!
Not sure if I understand the example correctly. Even if I set up the "startup delay" as 0 seconds, it still needs 7-8 min for the vm to be ready to use right?
@Patrick - This example was simply leveraging "Startup Delay" as the mechanism to "force" startup in a particular order. The much better method starts VMs by priority, but only starts dependent machines based on if the primary machine has services started
(no arbitrary time dependency). See the following post for this alternate method: