Another day, another call had come in.  I knew all too well what this was going to be about.  Our Citrix users were getting an error message when trying to launch their applications.  We encountered this sporadically, but often enough that the process to fix this was well known.

This fix was simple, but time consuming and annoying.  An App-V package had failed to load on one of our Citrix servers.  When the users were launching the application they were not presented with the application, but an error message.

Fortunately, I had ControlUp.  Remediating this problem was now a walk in the park.  Open up the console, select all the machines, run our “List All AppV packages” Script Action (SA).  

I then took corrective action on the troublesome machine.

Within 5 minutes I had it solved.

Looking back, it was great to have ControlUp so that this problem was solved quickly.

…  But what if ControlUp could have solved it *before* it happened …?

At the time, I entertained that thought.

If…  If ControlUp could be automated it could have found the AppV packages were not completely loaded and either restarted the package load process or set the affected server to offline.  If it could do that, I would not have gotten a call at all! The users would not have hit a blackhole server. Alas, at the time, this was not meant to be… at that time.

Now?

Now it’s possible.  Now more than I would have dreamed possible is possible.  ControlUp 7.4 has introduced a new feature that would have made sleeping in and not getting disturbed by calls a reality.  

Welcome to the future.  

Welcome to a world with ControlUp Automation.

ControlUp Automation

ControlUp Automation is the marriage of two of ControlUp’s most powerful features.  

The incident engine and Script Actions (nee Script-Based Actions).  

By combining these two features ControlUp can now execute scripts when thresholds, which you define, are hit.  And ControlUp has a lot of triggers. Almost anything in any view of the ControlUp console can be trigger. And on top of that, ControlUp can trigger on events, the same kind you find in the Window Event Viewer.

And with Script Actions (SA), you can execute PowerShell, Batch, and VisualBasic scripts (VBS).  But it’s more than that. Script Actions have always been a more than just executing a script… With the Script Actions engine you can pass any fields as parameters to the script.  This gives the script immediately relevant context allowing you to do so much!

Let’s take a high-level tour of these two features and then look at how they can play together.  

Script Actions

Script Actions are an incredible feature of ControlUp in their own right.  They allow you to extend the product in almost any way you want. The ControlUp script library contains hundreds of scripts written by community members that extend the product’s features in incredible ways.   

• Want to see all App-V packages?
  
• Want to reconfigure VM hardware?
• Want to get details on a users and their manager — pulled from Active Directory?
• Want to get the Citrix Provisioning Services (PVS) retries count?

These are all script actions that can be easily added.  

Incident Engine – Triggers

ControlUp offers an incident tracking mechanism called “triggers”.  You take a set of conditions and set thresholds. Once the threshold is met, an incident is triggered.  ControlUp has numerous conditions that you can use to set thresholds.

Stress Level, a Windows Event, a Computer Down ControlUp Event, a Process Started or Ended event, User Logged On or Off event, a Session State Change event and Advanced event configuration.  These are all the conditions that you can then set a filter.

Let’s walk through creating a script action that we can use as an Automated Action.

Creating the Script Action

One of the first things we need to figure out is what problem are we trying to solve.  I’ll pose a problem here:

Citrix just released a new version of the Citrix Receiver and Workspace App that fixes a severe security vulnerability.  We want our users to upgrade to the secured versions.

How would you do this in ControlUp – without Automated Actions?  

If you wanted to do this manually, we looked in the ControlUp console, sorted by Receiver version and then selected all users with an unsupported version > right-click Send Message.

In the past we wanted to ensure users got this message.  When this scenario happened, we would do this two times a day, every day to ensure it was received. Once at 10AM and once at 2PM which coincided with our peak user count.

This method has a big drawback though.  Are the users actually active so they’ll see the message?  Could we ensure they were active? For 20,000 users, trying to sort and track which users were not idle or disconnected and checking for an older version would have been too much work.

How can we solve this — with Automated Actions?

Let’s create an automated action that sends a message to a user if they are running an older version of Citrix Receiver telling them to upgrade.  In this scenario, our goal is for all users to be on a version of Citrix Workspace App from 2019.  We want to be able to send a message to active users who have just recently logged on.

In order to accomplish this, we need to figure out how to send a message.  Microsoft has a built in utility msg.exe that will work perfectly.

1. (Session) ID – used to send the message to the appropriate user
2. Citrix Receiver Version – this used to validate the version is old

Now that we have all the parameters necessary, I’ve written a powershell script to send our message:

Param (
    [Parameter(Position=0,mandatory=$true)]    [int] $SessionId,
    [Parameter(Position=1,mandatory=$true)][version] $CitrixClientVersion
)

#requires -version 3
$ErrorActionPreference = 'Stop'

<#
    .SYNOPSIS
    Sends a message to users with an older version of Citrix Receiver/Workspace app

    .DESCRIPTION
    Sends a message to users with an older version of Citrix Receiver/Workspace app.  The "minimum" version is hardcoded in this script.

    .PARAMETER SessionId
    The Session Id of the user.

    .PARAMETER CitrixClientVersion
    A string with the version in the format XX.xx

    .EXAMPLE
    Send-Message -SessionId 3 -CitrixClientVersion 14.4.0

    .NOTES
    The preferred version is hardcoded into this script.
    The message itself is hardcoded in this script.  
    To change the message or version level target, you will need to edit this script.
    
#>



[version]$minimumCitrixVersion = "19.0"
$message = @"
Hello, your Citrix Client is at version $CitrixClientVersion.

The minimum recommended version is $minimumCitrixVersion. 

Please upgrade your Citrix Client at: https://www.citrix.com/downloads/workspace-app/
"@

Start-Process msg.exe -ArgumentList ("$SessionId","/TIME:0",$message)

Now we create the Script Action as follows:

We can now test this Script Action by manually running it against some sessions.

Success!  

Now that we have a script, we need to configure the triggers.

Creating the Trigger

From all the trigger options, we are going to select Advanced.  

“This trigger is activated when a custom set of conditions applied to a row in ControlUp’s information grid.  Use this trigger type to capture a scenario which is not covered by any other trigger type.” This meets what we’re going to try and do, we are going to use some of the column properties to activate this trigger.  

With that, we want to message users whom have an older version of Receiver, whom are active.

Specifically, we want the following conditions:

• Old version of Citrix Receiver
• Session State is Active
• User is not idle
• User has been using the session for at least 3 minutes

Each of these conditions can be directly mapped to a filter within the trigger.  

With each of these conditions set, we now satisfy our criteria.  The last step is to select our script as the Run Action.

I’ve also specified to “Wait at least 24 hours before repeating”.  This will mean that the trigger will be reset after 24 hours for that specific session.

Lastly, what will this look like for the user?  Like this: