Explore expert insights, tips, and best practices to optimize your IT operations
Tap into a wealth of knowledge from your peers, industry experts, and the ControlUp team, deepening your understanding of ControlUp products and solutions.
ControlUp helps IT teams address common digital workplace experience challenges, no matter their use cases or existing technologies.
ControlUp offers a rich set of capabilities to improve the digital experience for employees using any desktop, any application, anywhere.
Explore expert insights, tips, and best practices to optimize your IT operations
Tap into a wealth of knowledge from your peers, industry experts, and the ControlUp team, deepening your understanding of ControlUp products and solutions.
A global organization of technology professionals transforming the desktop monitoring marketplace.
Session optimization is a common challenge, whether you’re managing a Citrix, VMware Horizon, RDS, or WVD environment (or an environment composed of all three). We’ve been working on a approach to attacking the problem, creating scripts and adding triggers to make the result more comprehensive and powerful.
And we’ve done it! These new trigger/script action combos reduces process priority AND session memory consumption. We’re excited to announce that it’s has been added to our Community Triggers. Here’s more detail and best practice for leveraging it.
Session optimization comes in two forms. Performance-based or capacity-based. ControlUp can optimize for both. Performance-based has been demo’ed and shown with the User Input Delay changing process priority during times of contention. However, capacity based is a low hanging fruit, ripe for the picking.
ControlUp has enabled four community triggers, now available to customers on version 7.4+. To enable these triggers, simply click the Enabled checkbox for those triggers as shown in the screen shot immediately below.
This post will show you how ControlUp designed these triggers step-by-step.
These triggers have been designed to operate in pairs. There are two pairs, with each having one trigger for enabling resource optimization and one for restoration.
Session Active <–> Disconnected
| Trigger Name | State/Record | Filter | Scope | Follow-up Actions | Name/Description |
| AAS_Session State – Active |  |
 |
 |
 |
 |
| AAS_Session State – Disconnected |  |
 |
 |
 |
 |
Session Idle <–> Active
| Trigger Name | State/Record | Filter | Scope | Follow-up Actions | Name/Description |
| AAS_Session State – Idle to Active |  |
 |
 |
 |
 |
| AAS_Session State – Active to Idle |  |
 |
 |
 |
 |
About the Triggers:
State/Record and Filter
Green triggers are the restoration of services, Blue are the reduction of resource consumption. Realistically, there are 2 alternating states with which we are concerned.
Sessions that go from:
Active -> Disconnected & Disconnected -> Active
Active -> Idle & Idle -> Active
The triggers are designed around these 4 scenarios and the scripts have been written to understand these session changes. This is made possible by ControlUp passing the session state to the script.
Some key points/considerations.
For the primary states, the field “State” value changing to “Active” or “Disconnected” is a major change and we can key in on this singular field for the major state changes (active <-> disconnected).
However, Idle <-> Active Session State is determined by a mix of the field “State” and “Idle Time (Mins)”.
An Idle session has the field “State” as “Active”, but has some value (for instance, 15) in the field “Idle Time (Mins)”. When the session state field “Active” and field “Idle Time (Mins)” has changed to “0” after exceeding our “Idle” threshold, we consider the state restored to Active from Idle.
Due to the additional qualifier, an Advanced trigger is needed for dealing with the Active -> Idle and Idle -> Active triggers. A further qualification is needed when going from Idle to Active because we require the additional check that we are in an idle state before considering the state change back to Active.
Scope
It is EXTREMELY recommended that the scope of these triggers target the specific use cases for which they are designed. Multi-session servers like Citrix XenApp/Virtual Apps, VMWare Horizon View, Microsoft Remote Desktop Services (RDS) or Windows for Virtual Desktops (WVD). Having these triggers target against larger scopes may cause unwanted side effects as admin machines or servers may not have the timeouts nor want the resource reduction effects.
Follow-up Actions
There are two scripts that the triggers will use. Two scripts are activated when Resource Reduction triggers are fired. One script is activated when the restoration of services triggers are fired.
The description of each script action is sufficient to describe their purpose:
| Name | Description |
| VE – Trim Process Working Sets | Empty working sets or trim them down to a specific value for a given process or all processes in a specified session |
| VE – Adjust Process Priority based on Session State | Adjusts process priority for the session based on the session state. Session state can be idle, disconnected or active.
|
Script Action Settings
| VE Trim Process Working Sets |  |
 |
 |
 |
| VE Adjust Process Priority based from Session State |  |
 |
 |
 |
Resource Reduction triggers and script actions
When the resource reduction trigger(s) fire, ControlUp has identified two script actions that have a positive effect in reducing resource consumption. “VE – Adjust Process Priority based on Session State” and “VE – Trim Process Working Sets”.
Operation – “VE – Trim Process Working Sets”
The script action “VE – Trim Process Working Sets” takes the following parameters:
The two arguments worth modifying or having a user consider modifying is “Working Set Size (MB)” and “Exclude processes”.
“Working Set Size (MB)” – The size of the working set to trim down to. If 0 or negative then the entire working set will be emptied. The Working Set can grow above this as long as a hard limit is not in place.
“Exclude Processes” – A list of processes (without the .exe) separated by a forward slash (eg, “cmd/powershell/winlogon”). Memory trimming will be skipped for all processes in this list.
To change the list of Excluded Processes, you’ll need to modify the “Exclude Processes” list to add any additional processes.
This script only works in one direction → reduction of memory consumption of processes or processes within a session. There is no reverse of the purge of the working set.
Operation – “VE – Adjust Process Priority based on Session State”
The script action “VE – Adjust Process Priority based on Session State” takes the following parameters:
The two arguments worth modifying or having a user consider modifying is “Process Priority Floor” and “Excluded processes”.
“Process Priority Floor” – Specifies to what level that a process priority should be reduced.
“Excluded Processes” – A list of processes (without the .exe) separated by a forward slash (eg, “cmd/powershell/winlogon”). Process Priority will not be changed for processes within this list.
This script works in two directions. The reduction of process priority and the restoration of process priority. There is logic within the script to determine what to do with the processes based on the session state. If the state is active with an idle time that has a value of anything but zero the state is considered Idle. If the idle time is zero and the session state is active, the session is considered active. Lastly, if the session state is disconnected, then the session is considered disconnected.
When a session is considered disconnected or idle then process priority will be reduced to the value in the “Process Priority Floor” (excluding all processes in the “Excluded Processes” list). When a session is considered active, one of two things will occur. If a list of processes and their previous priority state is found, process priority is set to match the list. If a list is not found then process priority will be set to “Normal”.
