Deploying automation to speed up and error-proof routine or predictable data center tasks is a key factor in making the promise of cloud economics come true. Microsoft acquired a workflow automation technology from Opalis that became the Orchestrator component of System Center.

You use Orchestrator to automate tasks across operating systems and applications that would otherwise require human intervention or possibly complex scripting to accomplish. Figure A is the System Center 2012 Orchestrator Runbook Designer console, showing the relationship between runbooks, integration packs, and tasks.

Figure A

System Center 2012 Orchestrator Runbook Designer – Integration packs contain tasks used in runbooks.

In a Microsoft private cloud, Orchestrator will be front and center and can do a lot of heavy lifting when it comes to automating all aspects of cloud administration, for example, taking an action in SQL Server (like moving log files) when an operating system event (like low disk space) is detected.  Shortcomings of Orchestrator include its proprietary interface (little changed from Opalis days), a scaling limitation in large and multi-tenant environments, and a bare bones web console for remote launch of automation runbooks, seen in Figure B.

Figure B

System Center 2012 Orchestrator web-based console to launch runbooks.

Microsoft automation evolution: Beyond Orchestrator

System Center Orchestrator achieves interoperability by installing Integration Packs, and you make Orchestrator useful by authoring or importing Runbooks. Orchestrator Runbooks call ordered and timed activities such as “read this log” or “run that command”. Orchestrator is aware of these tasks because you imported the Integration Pack(s). However, by definition custom integration packs to intermediate between the orchestration engine and the IT workloads are an administrative burden that loses fidelity in the translation (that is, features exposed or available in an integration pack are usually a subset of those available in the native OS or application.)

To evolve beyond a dependency on integration packs as the definition vehicle for workflow tasks, to overcome scaling and multi-tenant limitations, and to provide for effective web-based remote Runbook administration, a new paradigm for achieving automation in a Microsoft network is emerging. The name of this new technology is Service Management Automation (SMA), which is fundamentally PowerShell behind Windows Azure Pack (WAP).  While System Center Orchestrator remains a preferred tool for much administrative automation inside the data center, SMA is clearly the new investment area for Microsoft.

Introducing automation for Windows Azure Pack

Prerequisites to use SMA are to install the Service Management Automation web service and to have an operational installation of Windows Azure Pack (WAP) for Windows Server. WAP is essentially the Windows Azure public cloud user portal, in a transportable format, running in a private cloud on-premise at an enterprise or in the data center of a hosting service provider—your own “mini-Azure.”

WAP is the definitive portal technology destination for most Microsoft servers and tools—strategically replacing the one-off web portals that accompanied each server and tool component, such as the Orchestrator web console. Figure C shows the WAP console, the “Service Management Portal” that is virtually identical to the Windows Azure customer portal, with the new Automation feature highlighted.

Figure C

The Automation space in the WAP portal is home for SMA Runbooks.

WAP integration modules replace Orchestrator Integration Packs

To expand the number of tasks that you can add to an SMA Runbook, you can import an integration module that contains additional activities. Modules are in the form of a compressed (zipped) file, not larger than 30 megabytes. An integration module is similar to a PowerShell module, with the following differences:

  • An integration module is packaged in a compressed (.ZIP) file that contains the PowerShell module folder.
  • The PowerShell module folder contains at least one file that has the same name as the PowerShell module folder, and has one of the following extensions:  .PSM1, .PSD1, or .DLL.
  • An integration module can contain a ModuleName-Automation.json file that contains the definition for a connection that is associated with the integration module.

Figure D shows the Assets section of the Automation feature with the Import Module button highlighted. Observe the names of modules that have been imported already, such as BranchCache and PrintManagement—that means activities from those modules are ready to be included in any Runbook.

Figure D

Import integration modules to SMA to add tasks and activities to runbooks.

Figure E illustrates how to access the New…Runbook command, creating an empty document for you to author your own custom automation.

Figure E

Manually create an empty runbook where you can author any PowerShell-based workflow.

SMA Runbooks in action

Once you have imported or authored one or more Runbooks, you run your automation routines from the SMA section of WAP as well. Each Runbook has a mini-dashboard panel in the WAP interface that includes an Author feature. In Author mode, you can manually type text in the Runbook document such as PowerShell scripts to be called to perform your work.  Figure F shows a sample activity Runbook that executes the Get-Date PowerShell commandlet—the line of the Runbook that calls that commandlet is highlighted.

Figure F

Edit the Draft copy of Runbook, and then publish it when validated.

After running an SMA job that has text output, you can view the results from the History section of the Runbook. Figure G shows the output of the “Get-Date” PowerShell commandlet that appears on line 8 of the Runbook seen in authoring view in Figure F.

Figure G

Runbook history includes the output of each job (if any).