Here’s how it works:
ControlUp triggers, prior to this release, operated on a real-time basis, monitoring when the metrics reach the target state, triggers can be executed on that state change. This gave ControlUp serious power and flexibility becaused it can react in real time to changes in your environment.
Scheduled triggers are a little different. Scheduled triggers, since they evaluate states at a preset time (as opposed to at state change), do a full evaluation of the objects in their scope. This is incredible because it can level-set your environment!
Imagine using a cloud provider and wanting to maximize cost-savings.
You run a standard 9-to-5 business day and your biggest expense comes from running virtual machines in the cloud. You want to save money, so it’d be great if you could shut down machines when they’re not being used.
The easiest path here (the so-called “low-hanging fruit”) would be to monitor the number of user sessions. After 5 p.m., for example, if any machine had 0 user sessions, that machine could be shut down.
With the ControlUp trigger system, machines must transition into a zero-user session state for the trigger to fire. If a machine was already in a zero-user session state at 5 p.m., the trigger would not be evaluated and would not be shut down.
Scheduled triggers behave differently and will simply check each resource to see if its user session count is zero and if it is, ControlUp shuts down the machine. This level-sets the environment so the real-time trigger doesn’t encounter any zero-user session machines, enabling the real-time trigger to shut down any machines three seconds after a zero-user session state is found. This can maximize savings in a big way!
Other use cases include health-checks, level-setting for the morning user rush, reboot schedules and more. The sky’s the limit.
These are some of the powerful new capabilities that Scheduled Triggers offer:
The first release of ControlUp Scheduled Triggers offers two interval settings: One-time and Daily.
One-time scheduled triggers give you the ability to configure an action or alert to take place at a single time of your choosing.
This can be useful for change management planning or instances when you need to execute a one-time action. An example would be disabling an application from being available at the start of the change window, to another one-time trigger enabling the application at the end of the change window. Once the trigger is executed and completed, it remains in the “Trigger” settings pane in ControlUp in case you need to adjust the start time for the next change window.
Daily scheduled triggers give you the ability to repeat a trigger in intervals between 60 minutes and one day (1440 minutes).
By adjusting the minutes field, you adjust the frequency at which a trigger fires. When combined with the “Schedule” feature in ControlUp, detailed trigger-firing scenarios can be created.
Going back to the scenario of shutting down machines after work hours: imagine wanting to remind users to log off their sessions. The requirement would be that reminder messages only be sent between 5:00-8:00 p.m., but not happen on weekends. By combining these parameters with a Scheduled Trigger, these complex requirements can be easily defined.
In the Trigger Scheduler, as you navigate through the “Add New Trigger” wizard, you’ll come to the “Scope” screen.
Here, you can select the objects in ControlUp that you want to trigger against by selecting the logical folder. At the bottom of this screen is the schedule. This defines when the trigger is set to be active. To create a schedule, click on the drop-down menu and select “Add new schedule”.
You will be taken to the “Alert Event Schedule” dialog.
This dialog offers the ability to enable or disable based on an hourly time scale. To use this interface, you click the time slots you want enabled (or disabled). Once you have all your time slots selected for when you want the trigger to fire, click “Record incident”. This will enable the trigger at these times. To prevent the trigger from running, select the times you do not want it to run and click “Do not record incident”.
By combining the “Scheduled Trigger” and the “Schedule” complex times can be set up for when you want your alerts or automation to execute.
ControlUp’s trigger system allows you to target various resources or objects. The expansive list is as follows:
The most used triggers tend to target Machine and Session objects, but we can target a bunch of different objects! And ControlUp’s script actions allow for some incredible flexibility in how you execute your actions. Actions can be executed in a users session with their own rights, or at the SYSTEM level of a machine—or on a whole separate machine! Details about the targeted objects can be passed to the action giving it context and intelligence about what it’s supposed to do.
The ControlUp trigger system can simplify your script actions by doing the “filtering” for you! Going back to the example of messaging users to log off at the end of the day, I’m going to add additional complexity by narrowing the specific users to receive a message. I want to message active users who are actively using a specific application, who are connected from one of two specific locations, but only on odd-numbered servers.
Doing this in a powershell script is doable, but the script complexity goes up a lot. Simply doing something like getting the active application is hard enough to figure out in Powershell—adding additional logic like targeting users coming from a specific location becomes extremely challenging since you have to define those IP ranges in your script or some location the script can pull that information. To execute something like this using native Windows Task Scheduler and powershell, well… let’s just say it’s difficult.
With trigger filters, we can put all that logic into the trigger.
Now we can have our script action be as simple as:
The $args will be the session ID as defined in the script action.
There are already amazing scripts out there, like Citrix or VMware Horizon, that check for the health of EUC environments, but these are more generalized and work against the environment, not individual resources.
With scheduled triggers, you can create health-check scripts that operate on multiple different levels. Scheduled triggers can run scripts on each machine looking for machine-specific health characteristics. This ensures sufficient free space, that services have started correctly, applications have their correct configuration, and so on and so forth. Triggers can also operate on an “EUC” application level, alerting you to any apps that are disabled or in maintenance mode (or even setting them back automagically). Health-checks on datastores, hosts, and numerous other resources can be executed, either with ControlUp filtering on “failure” states and alerting you to resources in those states or with health-check scripts to go above and beyond and do more comprehensive monitoring.
Want to close handles on all open FSLogix profiles for users who are not online at midnight? Now possible!
Level setting is ensuring you don’t have any outliers. In ControlUp, it can be used in conjunction with the real-time triggers. The real-time triggers work by doing evaluations when state changes. But if resources are already in a target state then the real-time trigger won’t fire. An example of level-setting for the real-time triggers:
A cloud customer wants to shutdown unused machines after 5PM. In order to configure this with the real-time triggers we’d set a schedule to only active the trigger after 5PM and set a filter for the user sessions equals zero. The result of this configuration would be any machine that has the user session metric drop to zero after 5PM will shutdown. But what about machines that had zero user sessions as the clock ticked to 5PM? They would be left alone.
Enter Scheduled Triggers.
With Scheduled Triggers, you can create a trigger that shuts down any machine with 0 user sessions at exactly 5PM. This now level-sets the environment by removing any anomalies (machines with zero users at 5PM) allowing the real-time trigger to operate against all other machine resources with user sessions greater than zero.
One of the biggest challenges of scheduled tasks is managing them.
Microsoft really only offers Group Policy as a way to centrally manage scheduled tasks. And there have been challenges!
In 2014 there was a big change in using Group Policy to distribute scheduled tasks—credentials for scheduled tasks were stored in XML files in the SYSVOL share. Since credentials stored this way could be easily reversed, Microsoft has removed this capability altogether.
ControlUp stores credentials securely and communicates with the ControlUp Agents using secured communication channels. With this, Scheduled Triggers can use credentials stored in ControlUp to run the tasks under specific user accounts.
In addition to how ControlUp manages credentials, the triggers window will be where you manage your scheduled triggers. They appear with a little scheduled triggers icon for easy identification.
Enabling and disabling Scheduled Triggers is a snap! Just click the check box to enable or disable them! Easy as pie.
Scheduled triggers help complete the automation story ControlUp brings to the table. By executing on a schedule, filtering to specific resources, and against multiple levels of objects—ControlUp can take your environment to the next level! From generating health reports, level setting, or taking actions against objects, ControlUp really can do it all.
Try ControlUp for free for 21 days! Download it and see what it can do for you.