ControlUp Automation – Session Timeout Per Application

Server Silos

 When I was a Citrix administrator, I hated having server silos.  

I worked extremely hard to minimize the number of silos in our environment.  This made management of virtual machines easier, reduced configuration sprawl and made the environment more consistent.  This is a very big challenge, though. When you are able to break down silos you’re thankful for the reduced effort in managing your environment.

There was always one reason to silo that I could not work around.  Session timeouts.

Session Timeouts

A session, generally, has 3 states.  “Active”, “Active with Idle time” and Disconnected.  When a session is in the “Active” state the idle timeout is 0.  User activity like keyboard and mouse actions will reset the idle timeout to 0.  When a user has no activity than the idle timeout starts counting. In ControlUp we show the current duration of the timeout in the “Idle Time (Mins)” column.  Once the timeout hits it’s configured limit, the session is then disconnected. The disconnected state means the streaming of the image to the remote endpoint has stopped.  Another timeout is then started for how long a session is allowed to exist in this state. Once this timeout is exceeded the session is logged off.

The different timeouts can be configured here, either per user or per machine.

They apply to Remote Desktop Session Hosts, which includes Citrix Virtual Apps and Desktops (nee XenApp/XenDesktop), VMWare Horizon, and Windows for Virtual Desktop (WVD) servers.

Silos. Silos everywhere.

The challenge with the session timeouts is they are set without context.  You can configure a user timeout policy, but that user will get that timeout without regard to what application or work they are doing.  You may want to set differing timeouts for a user depending on whether they are accessing a sensitive application or a simple office app.  This would force you to either have the user accept more disruptions in the enforced disconnects or logoffs, or silo servers with different policies applied.  Depending on the nature of your environment you may have to include additional servers (if you’re doing N+1 high availability) and if your secure app has a smaller user base, you’ll size your servers to reduce resource consumption.  This leads to more servers and less consistency in your infrastructure.

If you work in environments with sensitive or privacy conscious applications, you may get requests for these application timeouts to be very low.  Low timeouts tend to be degrade the user experience because the user will get disconnected or logged off of the servers more often. This causes you to either relaunch your application or reconnect to your session which is actually a jarring experience.  However, it may be absolutely required due to the sensitivity put in these apps.

In other cases an administrator may want some applications to have long timeouts for a better user experience.  Things like your standard office productivity applications. With these opposite goals, we need two servers to set this up.  If a user has access to both applications than two user sessions must be created. In this configuration, more resources are consumed as each server and session have fixed costs of CPU and memory.  This puts an additional strain on the hardware underneath. All so two different stopwatches can operate.

Now imagine you have more applications and each have requested their own timeouts.  We would have to fragment our environment even more. Each fragment is more overhead in the fixed costs, more overhead of administration time and effort, and more consumption of precious shared resources.  And if you are in a cloud environment more cost in each spun up VM.

Breaking down silos

ControlUp can break down silos by moving the timeout tracking from the operating system to ControlUp Automation.  

The logical diagram for how this operates looks like so:

We can now remove all of server A’s silos and have multiple sessions reside on our single server.

Configure the triggers that runs the automation

We are looking to accomplish two sets of automated actions.  The first is to set the session into a disconnected state. The second is to logoff the session.  Each set should operate with different triggers properties.

Let’s look at the disconnect triggers first. We will be using the “Advanced” trigger with the record type as “Session”.

For our sensitive application, we are keying in on 3 different filter properties:

• the idle time in minutes needs to be equal or greater than 10
• an application contains the name “Hyperspace”
• and the state must be active

For our non-sensitive application we are looking at the same properties but different values

This trigger is keying in on 3 different properties.  

• the idle time in minutes needs to be equal or greater than 480 (8 hours)
• an application contains the name “*Word*”
• and the state must be active

Once these have triggers has met their threshold, we’ll run a script configured like so:

Now let’s look at the logoff trigger.  The logoff trigger will be a “Session State Changed” trigger.

It will start when the state has changed to “Disconnected”, otherwise all other values can be the same.  Although, if you wanted a different disconnect timeout, you could modify “Minimum duration in new state”.

Filter:

And for our non-sensitive application:

We will set the minimum duration in this state for 2 hours.  The filter will include looking for “*Word*”

Once this script has met its threshold, we’ll run this script:

And let’s see the automation in action:

Trentent Tye

Trentent Tye, a Tech Person of Interest, is based out of Canada and its many, many feet of snow. FUN FACT: Trentent came to ControlUp because, as a former customer, the product impacted his life in so many positive ways—from reducing stress, time to remediation, increased job satisfaction, and more—he had to be our evangelist. Now an integral part of ControlUp’s Product Marketing Team, he educates our customers, pours his heart and soul into the product, and generally makes ControlUp a better place. Trentent recently moved to be closer to family. He does not recommend moving during a pandemic.