In our final video from VMworld 2014 in San Francisco last month, I stopped by AppSense's booth to get a demo of their latest features. (You may recall that Gabe wrote the new 8.5 release last month, so this video is a demo of some of those features.)
The big thing for AppSense in 8.5 is that they're focusing on the little features that make AppSense more useable at scale. (I love that they continue to focus on physical desktops in addition to VDI and RDSH sessions.)
One new thing is they finally let you configure a location (either a fixed location on disk or a network share) for the AppSense rules files, so installing new rules can be done automatically and no longer requires an MSI. (In previous versions the MSI requirement means you had to re-roll your non-persistent master images to install the new MSI just to change some rules.)
In Environment Manager, they have broke the logon into three separate triggers: "pre-session," "pre-desktop," and "after desktop created." This means that things you want to happen at logon, but that do not actually have to be created before the user logs on, can now be done in the background once the desktop is up. (I'm looking at you printer and network share mapping!) These individual things don't actually happen any faster, rather, they give the user the perception of a faster logon since non-critical stuff can get set up once the desktop has been created.
Finally, they showed a new "offline" mode that allows users to call the helpdesk to receive an authorization code to temporarily elevate permissions or disable certain rules so they can do things. To use this the user literally goes into an app to request what rule they want, and the AppSense agent generates a hash code based on that which the user can read to the helpdesk over the phone. If the helpdesk approves it, they enter that hashcode into a system and their end and it prints an authorization code which they read to the user over the phone. The user types that in and the local AppSense client checks to see if the authorization code is what it expected it to be, and if so, the agent will unblock that rule for the time requested. (Again, this is two non-connected systems calculating hashes. It's meant for situations where users aren't connected or don't want to wait for a centrally-pushed rule update.)
Anyway, it's all cool stuff. Check out the demo below: