Automation – Orchestrator Back to Basics – Use Cases Spotlight (3 of 5)

This is post #3 out of 5 in the “Orchestrator – Back to Basics – Use Cases” series, full series posts are located here:

• #1 : Alert Remediation, where automation is used to monitor specific situations, and react automatically. This is also the introduction post to the series.
• #2 : Maintenance tasks, where recurring tasks are being handled in a consistent and automated manner, triggered manually or when a specific condition is met
• #3 : Provisioning and Change Management Automation, where automation handles backend processing or user requests from a service catalog or any provisioning process worth automating in your context (this post!)
• #4 : Cross-technology integration . Here automation can be used to integrate otherwise silo’d technologies, or help in better together and migration scenarios (integrate a monitoring solution to a manager of manager, or into a ticketing solution)
• #5 : “Miscellaneous” scenarios, like dynamic resource allocation, and new user onboarding as examples

Use Case #3 : Provisioning and Change Management Automation

This post shows two scenarios where automation can be used to process provisioning requests from users. In the last part of this post, we will also focus on the different ways to trigger these Runbooks can be triggered, including service catalog integration, custom portals, or manual execution by IT administrators/operators.

Scenario #1 : Database as a Service

In this example, a simple form is being provided to an end user, so that they can choose the name and size of the database they would like to create, as well as a target environment (development, test, production) and an expected load for the new database (low, standard, high – subjective value). This form can be in an ITSM solution (System Center Service Manager is used in the example below, but it could be another one as well) or in a custom web page. See the “Bonus Track” section later in this blog post to understand how these different approaches could be used.

Based on the input parameters, the Runbook itself determines where and how to create the database:

In this example, a production database with a “High”expected load would be created on a shared server named “SQLFARM”, as the SQLPS script shows:

This is obviously a very basic example and, in reality, some subroutines might be called to determine the target location based on load and other previous requests. Going into that direction, if you want something more comprehensive to act as a foundation for your own “database as a service” offering, you can look at the SQL Server Self-Service Kit and the Oracle Self-Service Kit, also published on our blog.

Scenario #2 : How automation ties physical and virtual provisioning processes in a seamless way

In the example below, a virtual machine is created, and SQL Server is optionally deployed on it, if it was selected in the request form. You can see that SQL Server is being deployed from a Configuration Manager package. It could have been directly included in the image (Virtual Machine Manager has nice ways to do that), but this shows a scenario where an IT Organization might have standardized packages in Configuration Manager, and wants to reuse this package on any server being deployed, whether it’s a physical or a virtual one.

Let’s have a closer look at the main parts for this Runbook:

• The “Initialize Data”activity (1) requests standard input parameters for new virtual machines (Name, number of processors, amount of memory, lease duration, owner) and also includes an option to deploy SQL Server or not.

• Activities in group (2) create the Virtual Machine and set the corresponding properties (owner, lease). These are well known activities, that you can find leveraged and explained in many blog posts out there. A lesser known option includes setting a custom property in Virtual Machine Manager (VMM), so here is the script from the “Set Lease Expiration” activity:

• Activities in group (3) handle SQL Server deployment. This is done by adding the target server to a Configuration Manager collection to which SQL Server deployment is assigned :

“Bonus Track” : What can the trigger be for a provisionning Runbook? What front end could be used?

To better answer this, the first question you may want to answer is : Who is going to be the audience for this process?

For example, in the context of Scenario #2 (Server Provisioning), will end users be delegated this ability in a private cloud approach? Or are you just looking to provide an easy way for IT administrators to launch the process themselves, once they have handled classic communication and prerequisites with the end users?

In the case of the latter, you may not need a specific user interface, and could even start Runbooks from the automation engine interface, like the built-in Orchestration Console website:

You could also use command line tools (examples here and here) or PowerShell commands to do that (Note : The PowerShell module for Orchestrator is now part of the product as of System Center 2012 R2).

On the other hand, if your users are going to be leveraging the Runbook directly, the best user interface might be … the one they are used to! So it may mean:

• Integration in the “all up” service catalog you may already be using. Assuming you have a process where a new server needs to be approved before someone works on the actual deployment, you could have Orchestrator monitor service requests or change requests that have passed approvals, and are now sitting at the second “manual” step. By querying the ITSM request details, a Runbook could then be able to call the provisioning Runbook we described earlier, passing the required parameters:

The actual fields to query in the change request or service request will depend on how your ITSM processes are being designed. For example, the VM owner may not be requested at all in the initial ITSM frontend, as it could be detected from within the portal, and passed along by the solution.

Note : If the service catalog is Service Manager, there is native integration with Orchestrator, and you can graphically map data from Service Manager Service Requests to actual parameters in Orchestrator Runbooks. So Service Manager could effectively call the SQL Server provisioning Runbook detailed in this scenario, without the need for a monitor Runbook.

• A custom portal or web page, which could be logging requests in any way Orchestrator can monitor them (database, file, etc.). Using SharePoint is an easy way to achieve this, by monitoring list items. If you go through the custom web page route, storing data in a custom database would likely be preferred, but here is also an example relying on XML files. This Runbook would monitor and parse new XML files created with a specific naming pattern by a custom web page. Assuming the XML file contains all the field like CPU, memory, etc., the provisioning Runbook could then be called.

Note : Using PowerShell would simplify this Runbook, and would make it easier to port to Service Management Automatin (SMA). The actual PowerShell script depends on the structure of your XML file, but the screenshot below has an example, that you can download as part of the SQL Server Self-Service Kit:

As a summary, Orchestrator Runbooks can be triggered in the following ways:

• Triggered by an external condition (monitoring, event, …)
• Manually in the Runbook Designer
• Manually in the Orchestration Console (built-in web site)
• Via Command Line Tools or PowerShell
• From your ITSM portal and processes (including Service Manager)
• From a custom portal (based on SharePoint or not)
• From a partner of community portal, like https://eupsco.com/

• Previous post in the series : #2 : Maintenance tasks, where recurring tasks are being handled in a consistent and automated manner, triggered manually or when a specific condition is met
• Next post in the series : #4 : Cross-technology integration . Here automation can be used to integrate otherwise silo’d technologies, or help in better together and migration scenarios (integrate a monitoring solution to a manager of manager, or into a ticketing solution)