ControlUp has had automation capabilities for years now. The platform is capable of responding to changes in your environment automatically based on the metrics ControlUp collects. There are three categories of automation ControlUp is well-positioned to assist with: remediation, troubleshooting augmentation, and optimization. Today we’d like to walk you through how we’ve improved on the capabilities of our automation platform!
ControlUp Automate is the name given to the combination of technologies ControlUp offers that makes automation happen. For ControlUp Real-Time DX, these specific technologies are the Triggers and Script Action features.
The trigger system is a feature that looks at metrics collected by ControlUp and executes a follow-up action based on the state of the metric. There are many triggers available to execute actions (see screenshot below) and each trigger type enables impressive automation capabilities. From executing an action when a specific process ends, to scheduling an action to run against specific resources that match some criteria, ControlUp covers a wide range of scenarios.
The ControlUp trigger system enables automation by executing actions in response to metrics. Traditionally, this has meant running scripts in response to whatever conditions you specify. This is great for loads of things, but our customers asked for webhooks, which are essentially REST API calls, so that’s just what we’ve given them! We’ve built a new follow-up action called ’Webhooks’ into ControlUp, which allows native integration with and the ability for services like Slack, Teams, ServiceNow, and others, to receive REST API calls. Below is a screenshot of the new Webhook follow-up action.
In ControlUp, you can define a template with the required parameters given to you by the service you want to use. , and with ControlUp, you can define thewhatever information you needwant. ControlUp has an extensive list of 62 variables that you can add to the REST API call to enrich the data you receive. Take a look at the template in the screenshot below for a view on how this works.
Integrating ControlUp with third-party systems has never been easier. With webhooks, your Slack or Teams instance could message you about issues in your environment without having to deal with email. The screenshot below shows an example of what this would look like. How exciting it is to take this step towards staying on top of critical notifications about the status of your IT!
Large organizations with development and test environments have long asked for the ability to move triggers to their production environment. ControlUp has answered the call and now you can export triggers from one environment to another. See the triggers window in the screenshot below, which now has two new buttons on the upper right side: Import and Export.
You can export a single trigger or multiple triggers into a single JSON file and these JSON files can now be easily imported into any other ControlUp environment (see the screenshot below).
ControlUp has many powerful features and one of them is the ability to organize your resources by a custom structure. If you have Citrix or VMware Horizon in your environment, you would create a “Citrix” folder with all the Citrix machines, and a “VMware Horizon” folder with VMware machines. Creating a single trigger to target both would mean nesting the folder and assigning the trigger to the root. However, you may have other folders grouped in there that you’d want to exclude from the trigger.
With the release of ControlUp Real-Time DX v8.6.5, you can now target multiple folders with triggers. All you need to do is simply “check” the folders you want the triggers to operate against. This reduces the number of triggers and allows for greater design flexibility in your logical folder structures!
Once you start building out your automations, you might find yourself with a large number of triggers. The Trigger Settings window now includes a search field to enter free-form text to quickly find specific triggers. Simply enter some text in the search field and the triggers list will be reduced to show only the triggers with that text. Here’s a demo (below) showing how that works!
With ControlUp v8.6.5 we’ve enriched the Script Action feature to be more powerful than ever. One of the highlights of this release is a feature currently in preview: the ability to execute script actions via integrated .net execution. Using this feature will execute PowerShell scripts without spawning an additional powershell.exe process. See a screenshot of this new feature below.
Execute script with .NET engine (Preview) must be checked
This feature leads to some cool things we can do with PowerShell scripts. One example is that ControlUp will create a PowerShell environment and make a new variable available that can be used in your scripts! This variable is $CUTriggerObject and it contains information from the trigger that was fired. You can now get properties, such as the column that had its threshold exceeded, what the value was before and after, and more! The properties of the $CUTriggerObject are the same as the template variables. To get the before and after values of the trigger that fired, you would add $CUTriggerObject.ValueBefore and $CUTriggerObject.ValueAfter to your script.
Additionally, this feature helps secure scripts by no longer exposing the command line arguments that ControlUp passes to the powershell.exe executable.
Previous versions of the ControlUp script engine executed script actions by using positional parameters. That is, arguments passed to the script were required to be in a certain order. If parameters were out of order or missing, you could get unexpected results. We worked around this by ensuring the parameter block would have mandatory parameters defined by their type or doing argument counting and the like. This is no longer required.
One of the challenges of “real-time” passing parameters on objects is that their properties change quickly. Let’s say you have a scenario where you need to execute a script to gather some user information on user logon. The script requires things like the Session ID, Session Name, and Client Name. These properties all exist when a user logs on and maintains a connected session.
But now, imagine a user that logs on, but then quickly disconnects. If you have a trigger that executes a script action on user logon, all of those parameters will exist at that moment in time. But if the user disconnects their session then some parameters will become missing because of the nature of remote connections. In this scenario, the Client Name parameter will no longer exist when the session becomes disconnected.
Depending on the timing of these events, it’s possible that the trigger will fire and tell the ControlUp Automation platform to execute the script action. The Script Action will query for the properties of the session object to pass to the script for execution. But in that brief window between the trigger being fired and the script action being built for execution, if the user disconnected, then not all parameters will be on the session object when the script action runs. This would cause ControlUp to pass blank or null parameters for those properties, which can cause the script action to fail because the positional parameters are incorrect.
To ensure a script action has all of its parameters, the new “named parameters” feature of the script engine has three built-in actions you can choose to take. The screenshot below shows how you can create your own named parameter.
ControlUp can pass an empty parameter to the named parameter (e.g., -ClientName “”), it can simply not pass the named parameter and argument, letting you handle it in script, or it can abort the script if not all parameters are available and log it as an error (see screenshot below).
One of the biggest consumers of this new feature will be the Analyze Logon Duration (ALD) script. Previously, it dealt with parameter counting and evaluating that all parameters were present, which added quite a bit of complexity. In preparation for this feature, I rejiggered the script to use named parameters by adding custom parameter captions within the script action to ensure that all parameters existed with appropriate values. This made ALD more reliable and the information far more accurate. The drawback to this approach is that ALD now requires a ClientName argument which doesn’t exist for disconnected sessions. Thus, ALD would fail against disconnected sessions as there was no way to dynamically remove arguments passed to the script. With this enhancement, we’ll be able to simply choose “Do not pass parameter” for the ClientName argument and ALD will do its best instead of just failing outright.
Upgrade to ControlUp v8.6.5 and take it out for a spin today to give our new features and enhancements a try. Not a ControlUp customer yet? Start a free trial TODAY—the first 21 days are on us! Let us know what you think!
If you haven’t already, read our Real-Time DX v8.6.5 announcement blog to learn more about what else is included in the release.
Also, register for the Real-Time DX v8.6.5 webinar airing on June 8, 2022 at 11:00 AM PST filled with plenty of live demos!