I shared this workflow a couple of years back, and it’s since become one of the most referenced articles on this blog. It’s something that has been a part of just about all of my AppSense deployments since its inception. However, as time passed, the configuration evolved to be much cleaner, and I thought it was time for an update. So, without further adieu, here’s how we can manipulate AppSense to act only when a session roams from one endpoint to another. As an added bonus, we’ll even look at how to run them only when that session roams to a new department, building, or area.
As you’re presumably aware if you’re reading this, AppSense (now rebranded Ivanti User Environment Manager) consists of triggers, nodes, conditions, and actions. The latter three are customizable ad infinitum, but your triggers are static everywhere. While we lack a “session roam” trigger by default, we do have login, session reconnect and disconnect. With some cleverness, these are actually all we need.
Run Actions Only When A Session Roams from Endpoint to Endpoint
Step 1 [Optional, but Recommended]:
This step as optional because it does not serve a purpose beyond making this easier to reference and understand. It will make more sense when we finish, but understand that I will assume you completed this step in those that follow.
When you connect to a virtual session, the name of your connecting endpoint is stored in an environment variable. Our first step is to make a new variable containing this value. So, at your Login Trigger, add an action to Set an Environment Variable to a new or existing node. The name of the variable should be CurrentClient, and the value will depend on your virtual platform.
If you’re using XenApp/XenDesktop, the value needs to be:
If you’re using VMware View, the value needs to be:
Now right-click the action you just created and copy it to your clipboard. We’ll use it again in Step 3.
Create a new node (or select an existing one) at your Session Disconnected trigger. Add a new Set an Environment Variable action, and configure the name to be LastClient. Set the value to be %CurrentClient%.
I will note at this time that, on occasion, I have seen this node fail to run properly in XenApp/XenDesktop. If you find that this variable is not establishing as expected, try moving its containing node to the Session Locked trigger. In that event, remember also to move any Session Reconnected nodes to the Session Unlocked trigger respectively.
Create a new node at your Session Reconnected trigger called “Roam-Only Actions.” If the action from Step 1 is still on your clipboard, you can paste it in here. Otherwise, make another Set an Environment Variable action to set a variable named CurrentClient to whichever value you used in Step 1.
Next, right-click your new action and create a new Environment Variable condition (such that this condition is nested beneath the action, and not vertically aligned with it). This condition needs to check that CurrentClient is not equal to LastClient. Leave the checkbox ticked for Stop If Fails to the right of the condition.
Beneath your Roam-Only Actions node, create (or relocate) any nodes that you want to run only when a roam occurs. That’s it–you’re done!
In case it wasn’t clear from the steps, this workflow functions by storing your connecting endpoint in the LastClient variable as you disconnect. When you reconnect, and CurrentClient updates, all we have to do is see if those two values are the same. If they are, you’re on the same machine you were on last time, so your old settings should still apply. Your reconnect “stop-if-fails” condition therefore prevents all nested nodes from running. If the two values are different, AppSense knows the session roamed, and those actions will run accordingly.
Run Actions Only When a Session Roams From Department to Department
But what if you just want actions to run when a user moves to a new department? The steps are nearly identical to those above, but with one added caveat. Unfortunately, AppSense has no way of knowing which endpoints are in which departments in your organization. Some level of manual labor is therefore required to establish that. Sure hope you’ve got a reliable name scheme for your endpoints!
Locate the action where you set your CurrentClient variable at the Login trigger, as what follows will need to nest beneath it. Let’s say, for the sake of this explanation, that you have some endpoints in the ER and some in the ICU. Maybe the machines in the ER are called something like ER-WIN-001 and those in the ICU are IC-WIN-001. For each delineated area, you will create a condition/action pair as follows:
If CurrentClient contains ICU- > Set CurrentDept environment variable to ICU
Once you have defined all the pertinent areas, head to your Session Disconnected trigger. This is where you should have set the LastClient environment variable in Step 2 up above. Right-click it and add a new action to set the LastDept variable to %CurrentDept%.
Repeat Steps 3 and 4 exactly as described above, but replace CurrentClient and LastClient with CurrentDept and LastDept respectively. The difference here is that AppSense will now differentiate between reconnections within a single department with those that span two. If a user roams from ER-WIN-001 to ER-WIN-002, none of these department-based actions will occur. However, if AppSense sees them move from ER-WIN-002 to ICU-WIN-001, it will know to act accordingly.