AppSense PowerShell API for Configuring Environment Manager

I recently discovered the AppSense PowerShell API for creating Environment Manager configurations (There is also one for the Management Center, but I haven’t touched it yet). I don’t know for how long it’s been available, but I only came upon it because a customer pointed out a .pdf whose title, “AppSense Environment Manager Configuration API” referenced its existence. This customer also happened to have 350+ printers, and wanted a node for each one. Every node was to contain ostensibly the same set of conditions and actions, so it was a pretty fortuitous discovery and saved me a ridiculous amount of clicking, copying, and pasting.

The document explains in sufficient detail how to use the API and can be downloaded from (Requires login), but the commands themselves are fairly clean and easy to work with. For our needs, I wrote an AutoHotkey script which in turn generated a .PS1 PowerShell script (which ended up being roughly 3000 lines!). This was able to map out all of their printers while saving me a lifetime of arduous GUI navigation. That being said, it worked just as well as if I done exactly that. Actually, it destroyed the possibility of human error for individual nodes, so it probably worked even better.

The Appsense PowerShell API is only capable of generating new configs (and not modifying existing ones), but this is overcome simply by generating the nodes and subnodes you want and then copying and pasting them into your primary configuration. Here’s a piece of the script I generated (made generic to a point). Note: PasteBin link, opens in a new window.

It’s just a matter of designing an object with its respective parameters and then adding it as a child of a given parent (the parent can be a node, sub-node, action, or condition–your call). The above will add a node called Windows Printing, give it a sub-node called Printer 1, and populate that sub-node with a condition that checks the client’s computer group, an action that maps the appropriate printer, a condition to check a secondary AD group, and then an action to set it as default. Finally, it saves the config for your use.

The AppSense PowerShell API document will go into a fuller explanation of what each string and boolean defines, but hopefully this gives you something of a skeletal representation of a configuration-generating PowerShell script.

Top of Page
Go Back

4 thoughts on “AppSense PowerShell API for Configuring Environment Manager

  1. Meditech Printing Nightmares! How can Doctors be this dumb??? Vince clearly you can feel me on this one. I just went all with way down your blog to the point where I hit a fellow time travl)r iseClose, but no home run for my issue.

     Aka Imprivata SSO single Logon, Vmware thin print, VDI Win7 hosted by a Wyse D90D7 running WES7SP…Now If that makes any sense to you then your a sick man like me!! So Vince help me out how do we get the volatile environment variable in Netbios for Workstation Name that is pulled at initial application startup. However, if a user “suspends” a View session in one location and restarts in another, location of the hospital that variable is not rechecked. Now Doc’s printing subscriptions on the 30′ x 40′ plotter, ok I’m BS you a bit on that, but you get what my issues is, the same as all IT techs Printing!!!!!

    I need to develop a creative workarounds through scripting or integration with our SSO tools, at this point we just have simply trained users to log out of MEDITECH and log back in if they are changing ER PODS but that really weak I’m hoping we can do better than that… Can you point me in the right direction?

  2. If I am understanding you correctly, all you need to do is close the Meditech application / log users out when a user changes locations? There are a number of different ways that can be accomplished — what SSO tools are you using?

  3. Yes, if we close Meditech, it will re-detect the new TC along with the local printers and update with meditech with that new information…Nevertheless it would be sick if on badging in we could piggybackflag on the View session reconnect call… Then all we would need to do is script a simple close and reopen “meditech” session on any IP changes. Another way of saying this is how can we get View, to restart Meditech whenever it receives a request to connect and NEW client IP to an OLDer running desktop.

  4. I don’t know how you would handle this from the Meditech server side, but since you are using Imprivata, you can script this behavior with extension objects.

    Create a script (this will be Script 1) that sets an environment variable, say, “CurrentPC” and value it with the name of the endpoint from which they are connecting to View. Create another script (Script 2) and have it set an environment variable called “PreviousPC” to be valued with %CurrentPC% (That is, set it equal to the value of CurrentPC)

    Now, create an EXO in Imprivata that runs Script 1 at the “Session Reconnected” trigger and another EXO that runs Script 2 at the “Session Disconnected” trigger. Remember to enable these in the appropriate computer policy.

    Once you can see these variables getting updated accordingly, go back to Script 1 and add some logic that checks whether or not the CurrentPC value is equal to the PreviousPC value, and then closes and reopens Meditech if it finds that they are not equal. I actually have another post on this blog that breaks down how/why this works using AppSense; this is just a modification for your needs.

    Hope that helps!

Leave a Reply

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