Service Management Automation is young enough to have a number of quirks that can be frustrating to get around. One surprising quirk has been with SMA Module Activity Data (i.e. functions) to not appear on all machines consistently.
This module is reworked from the version posted by Eamon O’Reily on the technet gallery.
Microsoft’s Web Platform installer provides the ability of installing web based components onto Windows Platforms. The technology is simple to use and works well when a machine has access to the internet. When the machine being installed don’t have access to the internet the installer becomes a problem.
When automated systems go wrong you may need to cancel a backlog of pending or running Orchestrator jobs directly with SQL.
For reference, the StatusId field from Orchestrator’s Job table provides the current status of the job. These numeric represent:
0 = Pending
1 = Running
2 = Failed
3 = Cancelled
4 = Completed
The script may be run directly with SQL Management Studio.
PowerShell’s Desired State Configuration allows for routines or classes to be run on remote machines by passing a text based “properties” object to the destination end-node. There are a growing number of Microsoft supplied “classes” and importantly, the framework allows for custom development of additional objects.
MOF Files define the inputs to the class that will be run remotely.
In a previous example, I gave an example of running a simple Service Management Automation runbook using REST. This blog demonstrates how to retrieve output from a called runbook by using platform independent REST calls against the SMA Server.
Four steps exist in obtaining the output from an SMA Runbook:
Jason Ginchereau is responsible for the creation of the Windows Deployment Toolkit which is incorporated into WIX. The toolkit provides extensions for PowerShell to access Windows Installer databases with managed code. Current releases can be downloaded from: http://wixtoolset.org/releases/
Service Management Automation Runbooks are PowerShell workflows. Workflows allow parameters to be passed in at the time of execution and are essential to any infrastructure automation.
This example uses PowerShell to call an Orchestrator runbook and display the results.
To demonstrate the scripting, I have created a simple runbook that will accept a string input. It’s titled “Input1”.
