FlexApp One – Review

Hey everybody!

I’m back and I wanted to start by talking about a new feature Liquidware has added to FlexApp.  Now, most of you know I was employed by Liquidware and that was when I discovered, and fell in love with, FlexApp.  FlexApp, in my opinion, is what many wanted Unidesk to be:  a method to dynamically deliver applications to virtual desktops and session hosts.  No more sticking applications into an image which makes maintenance of the applications AND the images much simpler.  FlexApp is, in my opinion, the fullest feature product out there that can do this dynamic delivery.  Even Microsoft has jumped into this delivery method with MSIX AppAttach.

Now, I could easily jump into the rabbit hole of talking about all the features of FlexApp but that’s not why I’m writing today.  FlexApp can deliver from anywhere whether on-premises or from the cloud with the only caveat being endpoint had to have a network connection to where the FlexApp packages were being delivered from……. until now!  That brings us to the new feature:  FlexApp One

FlexApp One allows you to deliver FlexApp packages through traditional deployment methods like Microsoft Endpoint Manager, System Center Config Manager, Workspace ONE and many others.  Oh, and did I mention that the FlexApp packages can be run OFFLINE!  AND you get all the advantages of the dynamic delivery model such as no local installation of the application, ease of updates to applications simple/easy removal of the application without it leaving behind traces of itself and so much more.

The FlexApp Packaging Console gives you an easy to use GUI to review and edit what was captured

The best part of it all is that if you are already using FlexApp, not only will you get this feature BUT YOU WILL NOT HAVE TO DO ANYTHING TO YOUR EXISTING FLEXAPP PACKAGES!!!!  Currently, you download a zip file, extract and run a PowerShell script from that folder.  When you run the script, you simply specify the folder of the FlexApp and BOOM, it spits out a single executable and that is what gets delivered to the endpoints and runs to give the user their application.

How simple is it to take an existing FlexApp package and make it into a FlexApp One executable?

FlexApp package files before creating FlexApp One
PowerShell command to build FlexApp One executable
The executable is built and ready for deployment

That’s it. One simple command and a few seconds of time.

Your next question will be what is in this executable, what makes it so special.  Everything needed to run the application is in that single executable.  When run on the endpoint, the first thing it does is to check whether the FlexApp One service is already installed.  If it is not, it will attempt to install, and this requires elevated permissions (more on this in a bit).  If the service is already installed, it checks the version installed versus what is in the executable and upgrades accordingly.  Once the service is there, the service mounts the application, and the user now has access.

You may be saying to yourself, well, didn’t that install the application?  Not in the slightest. If you are unfamiliar with FlexApp packages, the applications are “installed”, or packaged, to a VHDX and the VHDX is mounted to the endpoint with a filter driver makes the file system and registry look like a single entity to the operating system.  The filter driver redirects calls to the proper locations for file and registry.  Normally, this is all done over the network where the VHDX’s would reside.  A user see’s a C: drive and that’s it.  This works the exact same way except the VHDX is part of the executable package and is mounted from within.  When the executable is run, there are many command line switches you can invoke to do things like add the application shortcut to the start menu, run at user log in, and more.

Let me distill what I’ve written above to make it simple:  FlexApp One takes your already existing FlexApp packages and bundles the key components into an executable that can be delivered through products like System Center Config Manager, they can be delivered by placing them on a content collaboration platform like OneDrive, you could even copy the executables to a thumb drive and the users can run the applications from there.

I have been playing with FlexApp One for a bit now and, I believe I can safely say, it simply works.  I was able to take existing FlexApp packages, quickly convert them and push them out through Microsoft Endpoint Manager, I ran them from OneDrive and ran them from a thumb/flash drive.  The beauty of it is that it requires no changes to your environment whether it’s the FlexApp packages themselves, the FlexApp console or anything.  The behavior of the applications is the exact same as if it was delivered through traditional FlexApp methods.  In fact, FlexApp One packages do not even need to check in with the ProfileUnity license service making these apps perfectly capable of running completely offline.  There is licensing but its all built into the executables.

The “downside” is that the same limitations exist for applications running as a FlexApp package meaning there are no low-level device drivers, it cannot run at boot, and most importantly, the same application cannot already be installed on the endpoint.  This last point is critical as the behavior of FlexApp is to defer to the endpoint/image/Operating System if there is a conflict between the package and what is installed onto the endpoint.  For example, your endpoints have Application4.x installed and you want to upgrade the application to Application5.x.  You would NOT be able to simply send a FlexApp package with Application5.x and have the application “upgraded”.  Since 4.x is installed on the endpoint, the FlexApp filter driver will “ignore” the FlexApp package (this is an oversimplification of what is happening behind the scenes).  The reality is you could seriously affect the performance of the endpoint by trying this.

Therefore, in the FlexApp One documentation you will see Liquidware recommends running a package on a “well managed endpoint”.  As an administrator, you know what’s on the endpoints and can make correct decisions on how to deliver or update applications.  Now saying that, being the good Geek that I am, I wanted to test this out on a couple of home machines I have.  One is an Alienware laptop that I use on a day-to-day basis for everything from playing games to creating videos to writing this blog.  The other is a dedicated gaming/VR rig that I custom built with one of my kids.  Keeping the caveat in mind of not trying to run an application that is already installed as a FlexApp package, I dove in headfirst and…. they packages ran perfectly.  Camtasia, VSDC, ExpressVPN worked great.  I could edit and record video, I could connect the VPN and browse around the world.  It was great and when I logged out or rebooted the applications were gone as expected.  I even disconnected from the network and the apps continued to run (even ExpressVPN but obviously I would not be able to connect out).

One last thing I want to bring up and make sure is understood is the service and filter driver that has to be installed before any of this can happen.  As I mentioned previously, they will automatically attempt to install from the executable package.  This install requires elevated privileges to do its thing.  If you are managing the endpoints that will use FlexApp One packages, you can install the requirements beforehand using whatever tool you use to deliver software.  It can be installed beforehand.  As well, if the users are administrators or can elevate permissions on their personal machines, this isn’t a problem the first time.  The issue would come into play if you put apps on a thumb/flash drive, stick it into a machine that you do not have admin rights and cannot elevate permissions.  The result would be no service install, no filter driver and no FlexApp One package being able to run.

I believe this is a great new feature for FlexApp and puts it clearly ahead of any other similar product in the industry out there.  Probably the biggest argument against true dynamic delivery of applications has been the network connection requirement.  Now you are no longer bound by network connectivity and can use one packaging method to deliver applications in any which way you want.  The ease of managing images and applications just got better as you can truly separate the two realizing the dream of less images to manage and being able to install, update and remove applications cleanly.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s