I often write and speak about app management because I believe that managing applications in a more efficient way can free up valuable time and energy that we can use elsewhere in our desktop virtualization environments. As such, I try to check in with each of the vendors regularly, and I recently connected with Liquidware (they dropped the "Labs" right before Synergy) to get a look at their application management platform, FlexApp.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
From the highest vantage point, FlexApp works by attaching virtual disk images that contain applications (single or multiple apps) to your base image. This approach lands FlexApp in the "Application Layering" category of application management, alongside AppVolumes and Citrix App Layering. (FSLogix belongs in that conversation, too, but their approach is different enough at a lower level that it's hard to put them in either the App Virtualization or the App Layering categories, so we just label them as App Management.)
FlexApp was originally part of Liquidware's ProfileUnity, though it's also available as a standalone product, so don't go thinking that in order to use FlexApp you'll also have to switch profile management platforms. If you do consider ProfileUnity, though, you'll get additional hot-button features that include support for OST files, Windows Search, and the OneDrive cache in virtual desktops.
ProfileUnity is probably worth a look at another time, but for now let's focus on what's new with FlexApp.
The latest version of FlexApp, 6.7, is due to ship July 11 with two key new features: Click-to-Layer and Session Isolation. Click-to-Layer aims to address problems that arise when application layers are merged into the base image, while Session Isolation allows per-user applications to work well in RDSH/XenApp environments.
Prior to this version, the only two ways applications could be attached to a desktop were either at boot or at logon. (Attaching at boot actually means attaching when the FlexApp service starts, not actually at power-on.) The problem is that the act of merging in applications creates a ton of filesystem and registry operations, sometimes in the neighborhood of a hundred thousand registry keys. These extreme applications can take up to 30 seconds to merge, and, depending on the number of app layers you have and how many keys have to be merged, it could take even longer. As you might imagine, this can lead to slow boot or logon times.
Click-to-Layer is another deployment mechanism in addition to the boot and logon methods. It works by placing icons for applications to which a user is entitled on the desktop without actually merging the application layers into the OS. Boot and logon times are much faster, and the user still sees their application icons instead of waiting for them to trickle down.
When a user clicks on the application icon, which is actually just a shortcut that tells the FlexApp agent to merge in the layer, the merge happens and the application is launched. Even the fake icon is replaced with a shortcut to the real application for future uses until the machine is reset or reimaged. If an application goes unused, the user doesn't spend any time waiting for it to be merged into the OS.
This third approach to attaching layers, combined with Liquidware's preferred method of creating one layer per application, gives you a lot of flexibility when deploying applications. Certain applications that need to be available right away can be merged in at boot, while others can be there as soon as the user is logged in. Less-frequently used applications can then be configured as Click-to-Layer apps, which is just a checkbox in the management console.
Through another approach they call "Unmanaged Click to Layer," you can even publish Click-to-Layer applications in XenApp without having the application executable available on the XenApp server. To do it, you simply point your published app to the FlexApp executable along with some other command line parameters that tell FlexApp to start the specific application you're publishing. If the layer is already present on the XenApp server, the app just fires up, and if not, FlexApp merges in the layer before starting the app.
The other new feature, Session Isolation, is Liquidware's way of enabling multiple application layers to work more cleanly on RDSH/XenApp servers. In the past, when an application was delivered to an RDSH desktop, all the users were exposed to those applications whether they needed them or not. Session Isolation allows each user to see their own set of applications without clutter from other users' activities.
The Click-to-Layer functionality factors in here, too. If multiple users are assigned an application, each of them has the "fake" application icon on their desktop. When one of them runs the application and kicks off the merge, it happens for the entire OS. Since the application is already merged in, none of the other users have to wait for the merge operation.
Liquidware has come a long way with FlexApp, and they've gone to great lengths to address the shortcomings associated with the solutions from the large vendors. Separating out FlexApp from ProfileUnity allows companies that are already married to a different Workspace Environment Management platform to bring in application management without having to migrate WEM platforms (a savvy move that we've seen from other companies, too).
If you're one of the 50% of organizations out there that does nothing at all to manage applications, they're worth a look along with all the other vendors in the market.