AppSense: How to Use Roaming as a Node Trigger

AppSense’s Environment Manager has a trigger for almost every occasion. However, let’s say you have a series of actions that you only want to run when a person roams to a new location. You could just set these to run at reconnect/session unlocked, but that means those actions are going to run every single time you reconnect to a session, even if you’re doing it from the same machine you just locked moments earlier. In the case of mapping printers, it’s a ton of unnecessary work to do it if the printers aren’t going to change.

There is no “location change trigger” built into AppSense. However, by setting up some fairly simple logic, you can make one of your own. All it takes is a few environment variables and a condition check. Set these up correctly, and you’ll be able to enact a series of actions only when a user roams his or her virtual session from one machine to another. In the printer example, there is no need to un-map and re-map the same set of printers every time a user disconnects and reconnects from the same physical device. You can instead update their printers only when they move to another area that requires a new set.

Before I continue, I should preface this by saying that all of the below presupposes an endpoint naming scheme that reflects the physical location of the machines in question. If you don’t have one of these, you should really put the effort into establishing one. You will not be able to get the most out of AppSense until you do.

Essentially, we are going to need to set up two different environment variables, henceforth referred to as CurrentPC and PreviousPC.  The TL;DR version of this post can be summed up in saying that we will determine in AppSense which PC the user connected from last time, compare it against the machine they are connecting from this time, and then run our actions if they are not the same machine. Our “location change trigger” is less a trigger than a simple condition whose parameters we will determine ourselves.

Step #1:

To make the aforementioned comparison work at the very first login, you will need to establish the PreviousPC variable even when there technically wasn’t one. For this, you will need a node that runs under the Login trigger. Pick any of the ones you have already (if they exist), relocate a pre-existing node that currently runs elsewhere, or create a new one. The only important thing to remember is that these needs to run before anything else we establish below.

In this node, create an action that values the PreviousPC environment variable with NULL. Bear with me, it will make sense later if it doesn’t already.

Step #2:

Create a node called “Set CurrentPC variable.”  In this node, you will run either of two VBscripts, depending on your environment type.

If using VMware View, create a custom action containing this script (Slightly modified from the one found in this AppSense Bigot article):

‘ get Clientname

Const HKEY_CURRENT_USER = &H80000001

Set wmiLocator=CreateObject(“WbemScripting.SWbemLocator”)
Set wmiNameSpace = wmiLocator.ConnectServer(“.”, “rootdefault”)
Set objRegistry = wmiNameSpace.Get(“StdRegProv”)
sPath = “Volatile Environment”

lRC = objRegistry.GetStringValue(HKEY_CURRENT_USER, sPath, “ViewClient_Machine_Name”,sComputerName) ‘Query Registry for client name

‘set the environment variable

Set oShell = CreateObject(“WScript.Shell”)
Set oUserEnv = oshell.Environment(“USER”)
oUserEnv(“CurrentPC”) = sComputerName
wscript.quit(0)

If you are using Citrix XenDesktop, use this variation instead:

‘ get Clientname

Const HKEY_LOCAL_MACHINE = &H80000002

Set wmiLocator=CreateObject(“WbemScripting.SWbemLocator”)
Set wmiNameSpace = wmiLocator.ConnectServer(“.”, “rootdefault”)
Set objRegistry = wmiNameSpace.Get(“StdRegProv”)
sPath = “SOFTWARECitrixIcaSession”

lRC = objRegistry.GetStringValue(HKEY_LOCAL_MACHINE, sPath, “ClientName”,sComputerName) ‘Query Registry for client name

‘set the environment variable
‘msgbox(sComputerName)

Set oShell = CreateObject(“WScript.Shell”)
Set oUserEnv = oshell.Environment(“User”)
oUserEnv(“CurrentPC”) = sComputerName
wscript.quit(0)

These scripts will search in the appropriate place in the registry for the name of the physical endpoint and establish it as an environment variable within the session called CurrentPC. Set this node to run at User Login after whichever node runs the PreviousPC = NULL action we set up in Step #1. After that, set it to run at either Session Reconnected (if you’re using View) or Session Unlocked (if you’re using XenDesktop).

Step #3:

Create a second node called “Set PreviousPC variable” and add an action to value the PreviousPC environment variable with %CurrentPC%. Set this node to be run at either the Session Disconnected trigger (if using View) or Session Locked trigger (if using XenDesktop).

With these two nodes configured as above, it is simply a matter of setting any location-sensitive actions (for example, printer mapping) to run dependent upon the condition that CurrentPC is not equal to PreviousPC.

To add actions to our metaphorical “location change trigger,” establish the aforementioned condition in any node you want, and then set all relevant actions to run if the condition passes. Finally, set these nodes to run after each iteration of the Set CurrentPC Variable nodes you created earlier.

The Logic for AppSense

In case the reasoning is not clear from the instructions above, the logic is basically as follows:

    1. User opens a new session. PreviousPC is set to NULL.
    2. CurrentPC is then valued with the name of the physical endpoint.
    3. AppSense sees that the two are not equal, and runs any actions that rely on that condition.
    4. User disconnects their session, and PreviousPC is set to be identical to CurrentPC.
    5. User reconnects their session, and CurrentPC is revalued with the name of the machine from which they are connecting.
    6. If they are reconnecting from the same machine,
      CurrentPC is re-set with the same value it previously contained. Because PreviousPC was set to contain that very value at the last disconnect, the variables are equal. AppSense does not run any actions.If, however, they are reconnecting from a new location,
      CurrentPC will be set to a new value. Because PreviousPC still contains the previous value of CurrentPC, these two values are no longer equal. AppSense runs the actions.
    7. Ipso facto, the actions are being triggered by a physical change of location, and not simply at reconnect. Voila, a location change trigger.

If you have actions that impact performance, this protocol should speed up your reconnect times by only running those actions when they are really needed.

Let me know if I lost you, or how this worked for you.

One thought on “AppSense: How to Use Roaming as a Node Trigger

  1. Gonzo

    Dang, Vince your scary smart, now I know why you keep the ball cap down low. I’m never going to make you mad I’d hate to see what you could do to my bank account if you set your mind to it.
    Thank you for the “how to” and I’ll get back to you on my findings once I complete the steps you’ve outline here, Gonzo…

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *