- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
Once you’ve worked through with the business which processes to automate the actual steps in Orchestrator are easy and the user experience is almost identical to Opalis. You drag Activities from panes on the right into your workspace. These activities are either Standard Activities (known as Foundation Objects in Opalis) that are available out of the box or they come from Integration Packs (IPs) that you’ve installed.
You then configure each activity to accomplish what you want and link the activities together, taking into account branching for different outcomes. Activities can also take into account variables and counters that you’ve configured as well as perform manipulation of data; this is then passed onto the next activity on the shared data bus as Published Data.
Once you have created a runbook you’ll want to test it and the Runbook Tester provides the ability to debug, including setting breakpoints. Be aware that the Tester isn’t a simulated environment, the activities are actually executing on your live data. Another gotcha is that runbooks run under your account in the Runbook Designer but in the Tester they run under the Runbook Server service account.
The Runbook Tester lets you step through your runbooks activities and make sure it’s all working as expected. Remember, it’s a live environment, not a simulated test!
Standard Activities are available for system process and SNMP, scheduling, monitoring, file management, email and other notification options along with utilities for invoking web services or querying databases. For Linux integration Orchestrator comes with standard activities for Telnet and SSH workflows. The .Net script activity can run scripts in VB.Net, Jscript, C# and PowerShell.
The links between activities can be formatted with colors and widths as well as letting you control the data that flows between activities with Include and Exclude options (with the latter taking precedence over the former) to filter out data for the next activity. For branching logic you can control what happens for success, warning and failed conditions in activities. You can also use regular expressions to filter the output data as well as perform functions and calculations on numerical values. Activities can be looped with precise control over the exit condition.
Runbooks can be scheduled with control over when they’re allowed to execute (perhaps some should never execute during business hours), and each Runbook can be associated with a particular schedule. Within a runbook, you can use the Check Schedule activity to retrieve time data for individual activities. Monitors are a type of activity that waits for a particular event to happen to start the processing of a runbook and these runbooks “run” continuously, waiting for the event to happen.
In this part three of five we looked at the steps involved in creating runbooks, in part four we’ll cover permissions for runbooks as well as best practices for creating them.
