FlexApp Is Different Than Other Layering Products…Very Different

I was chatting with a customer the other day about FlexApp and they told me that “it’s a different kind of layering and I like it” – it’s not the first time I’ve heard that. This got me thinking ‘why are FlexApp customers having an all-around better experience when compared to other layering technologies. When I look at public forums like Twitter, user groups, forums, etc the overwhelming opinion appears to be that all layering products are essentially the same and if an application won’t work in one, it won’t work in any others. I feel your pain and I just want you to know “Not all layering products are the same.” While Citrix App Layering (CAL), VMware App Volumes and FlexApp share the “layering” moniker, FlexApp couldn’t be more different from the competition (see 9 things that FlexApp does that no one else can or does). It’s these differences that allow us to package applications that others cannot, deliver those FlexApps to the appropriate end point or user and do this in an extremely efficient manner very, very quickly.

Before we go any further, I want to point out a difference that, in my opinion, is huge for large to enterprise customers and really showcases that FlexApp is different than the others in a very meaningful way. FlexApps can be used with Citrix Provisioning with no detrimental effect on the size of the write cache. Let that sink in for a moment. This is not possible with Citrix App Layering. You can use elastic layers with Citrix Provisioning, yes, BUT you will need to expand your write caches by a factor of two or even three and possibly more depending on the current size of your write cache. One of the beauties of Citrix Provisioning is that it takes up so much less storage than other provisioning mechanisms.

I will explore the Citrix App Layering vs FlexApp on Citrix Provisioning in my next blog so stay tuned!


I’ve talked about the differences in architecture before in this blog. As you can see, architecturally, FlexApp is night and day different than Citrix App Layering and VMware App Volumes. FlexApp isn’t layering on TOP of the image, it is layering INTO the image and the image is sacrosanct. FlexApp will not overwrite anything in the image like the other layering technologies do. This is critical as the other techs could potentially “overwrite” critical files and cause issues when the layer is attached.

I love the analogy of puzzle pieces when trying to visualize how FlexApp works. The analogy is extraordinarily accurate. When a FlexApp is attached, it’s snapped into the image. There is no overlap of the FlexApp with the image. When it comes time to remove the application, it’s simply unsnapped from the image. There is no remnant left behind at all.

Another distinction between FlexApp and the rest, based on the layer on top vs into, is that mounting multiple FlexApps will be faster than mounting multiple layers from a system using the layer stacks. FlexApp will simultaneously mount the layers being delivered to the end user. The layer stack method requires each layer to finish before it can continue to the next. This is what layer priority is for and why FlexApp does not require a priority system.


Packaging an application in FlexApp is very simple and very powerful. Creating a FlexApp package is very similar to the traditional packaging paradigm. A clean operating system, preferably a virtual machine for ease of rollback, with common prerequisites installed (visual C++ runtimes, .NET runtimes, etc) and the FlexApp Packaging Console (FPC) is all that’s needed. The packaging machine can be part of the domain or not. In fact, it can be on the network or not.

The FPC gives you the flexibility to package an application almost anywhere. You can have your standard packaging machines in your own datacenter or you could package an application at 35,000 feet and import it into your environment later! The FPC is designed to be able to package an application with no connection to the ProfileUnity server. If you are a consultant, you could create a package (Let’s say Chrome) and deliver that ONE package to multiple diverse clients. That is how clean the packages are but how is that done?

The first thing you’ll see when using the FPC is that you must say “start capture” and “end capture”. This alone limits the amount of noise that is captured. But how can you tell how much noise was captured or even if the application was captured correctly? Traditionally, layering vendors don’t really give you any insight into that. You could mount the VHD and trawl through the filesystem manually and mount the registry files to see that as well but that isn’t particularly easy to do and could potentially corrupt the VHD.

The FPC has a package explorer which is essentially a file explorer/regedit view of everything that was captured. You can easily see everything that was captured in one view and add, modify or delete as necessary. What if you notice that you forgot to install something or make other changes that would be easier if you were still capturing? The FPC has that covered as well. You can ‘extend’ the current package and make those changes. There is no having to add versions to make those changes.

And last, but most definitely not least, did I mention how fast it is to package an application and get it deployed? Obviously depending on the application and needed configuration, it only takes a few minutes. It is on par with traditional packaging.

Cross OS

FlexApps are not limited to the OS or image they were created on as I’m sure you understood from the above. We do not break the laws of Windows which means no 16-bit applications on a 64-bit operating system, we don’t fix compatibility (Windows 7 application that only runs on Windows 7, we can’t make it run on Windows 10) amongst other things, as always, test test test!

FlexApp Mount: Machine, User, Click-to-Layer

This is where things start getting interesting. FlexApp currently has three ways of specifying when a FlexApp is mounted. Machine, User and Click-to-Layer.

The way FlexApp does machine based mount is unique to FlexApp as far as I can tell. Not only can you assign FlexApps to an endpoint but it also mounts the FlexApp during boot. Why is this important? There is a resource hit when mounting layers or anytime you are adding something dynamic to a machine or user environment. This hit can be alleviated for the end user by having the FlexApp mounted at boot instead of at user login. When a user logs in, the app is already there and waiting.

User based mounting, along with filtering talked about below, is the quintessential layering assignment. When a user logs in, the FlexApps are mounted delivering applications that the user requires but are not part of the image.

Click-to-Layer based mounting is definitely unique to FlexApp. This method delivers an icon on the desktop for the user but the FlexApp is not mounted yet. When the user clicks the icon to open the application THEN it is mounted. This is great for those applications that aren’t used very often but need to be there when they are required.

Click-to-Layer also allows for publishing a FlexApp whether it’s RDSH, XenApp or some other mechanism. There is an executable called JitCut.exe that is run with an argument for which application should be mounted. Very simple.

Assigning a FlexApp: Filtering

FlexApp filtering is second to none. It uses the ProfileUnity filter engine which allows you to create as simple or as complex of a filter as you need. Do you want to use Active Directory groups? Yup. Do you want to use AD groups plus restrict the FlexApps to virtual desktops and not RDSH? Yup. Do you want to use AD groups, restrict to virtual desktops and only allow the FlexApp when the user is coming in from your internal network? YES! Time of day? Day of week? Yes and Yes!

Extraordinarily powerful and flexible!


Cloud is becoming more and more pervasive and desktops are starting to move in that direction as well. What if you want to deliver FlexApps to cloud desktops OR what if you have a requirement to deliver applications to remote users that aren’t on necessarily on your network? FlexApp allows you to store and run applications from object-based storage from Azure, AWS and GCP. In other words, NO EXTRA INFRASTRUCTURE NEEDED! For example, SMB Shares which would require a server.

Because FlexApp uses object-based storage, Windows cannot mount the VHD’s from there, so a solution had to be found and that’s what happened. FlexApps, when run from the cloud, are being cached on the endpoint through block-based caching. This allows features, again, that no other layering vendor has. The FlexApps are running from the cache and there is no lock on the VHD like that required when mounting directly from an SMB share. Caching is required when running from cloud storage but it can also be turned on for on-premises FlexApps. In fact, you can have some applications cached and others not. It’s turned on at a FlexApp layer level.

Resiliency and Failover

Caching has given FlexApp resiliency and failover capabilities as well. Now if there is a network blip or outage, there is a good chance the user may never notice. Unless FlexApp needs to get a new block, the application will continue to run (the blocks are local) unlike other vendors that would crash the application or worse blue screen the machine.

FlexApp also introduces a failover mechanism that runs in the background. The administrator sets up two locations where the FlexApps are located, specifies those locations in Group Policy or registry setting and if a location goes down, FlexApp will automatically get blocks from the other location. This is completely invisible to the end user! As well, FlexApp is monitoring network latency is if the primary location suddenly has higher latency than the secondary, FlexApp will automatically move to the secondary and then back again when the latency dies down.

Oh, and I should mention that the locations for the FlexApps can be on-premises to on-premises, on-premises to cloud and cloud to cloud. It’s entirely up you!


Yes, FlexApps can be delivered to physical desktops. Again, a unique feature of FlexApp.


Whew, thank you for going through this blog! I hope you have been able to learn some things about what makes FlexApp a better technology especially in regards to application compatibility. If you have any questions or comments, you always reach me on twitter @JeffPitsch or email at jeff.pitsch@liquidware.com. If you’d like face to face time, I will be at a lot of shows this year, user groups or we can always do Webex’s, calls and other forms of communication.

An instant hit! The Liquidware partner training 2018 – Spring edition

After almost two months of planning and preparations, on February the 26th we opened our doors to the first ever Dutch Liquidware partner training, here in Amsterdam. Joseph Ahn, our internal trainer flew in from Austin, Texas to provide four days, with an optional fifth of intensive training and certification around ProfileUnity, FlexApp and Stratusphere UX.

Continue reading

FlexApp Notes from the Field – VMworld 2016 edition

As we approach VMworld 2016, there has been a tremendous amount of excitement building around the solutions from Liquidware Labs. We just released version 6.5.5 of ProfileUnity with FlexApp back in June, here are a few of the highlights:

Continue reading

VMware UEM and App Volumes Overview Comparison with Liquidware Labs ProfileUnity and FlexApp

Liquidware Labs is announcing the release of a new WP “VMware UEM and App Volumes Overview Comparison with Liquidware Labs ProfileUnity and FlexApp” White Paper. At its core the focus of this new whitepaper attempts to compare and contrast the two platforms. Additionally, the whitepaper provides real world customer based implementation guidance around when to use a Liquidware solution as opposed to the VMware solution stack. Continue reading

FlexApp Layering White paper updates

FlexApp Layering from Liquidware Labs is evolving at a rapid pace. With that in mind we have updated the content with the primary white paper. Here is link to the “FlexApp: Application Layering Technology White Paper”. Continue reading

Introducing the FlexApp FAQ Technical Whitepaper

2015 was an impressive year for product announcements and innovations. Liquidware Labs re-released the FlexApp Layering platform after a significant architecture shift. Customer adoption and validation for FlexApp has been extremely positive. Looking back, something seemed to be missing in the EUC space with respect to application lifecycle management. Application virtualization started off strong but has tapered off lately, primarily because of compatibility challenges. The timing for a platform like Application Layering was perfect as companies push further towards desktop integration with the “Cloud”. FlexApp Layering is poised to take its place as one of the pillars of the application layering space.

The FlexApp Layering Technical FAQ has been released by Liquidware Labs. As customers look to adopt and implement the FlexApp technology, they are bound to have questions. Questions within the FAQ are divided into various sections for faster reference:

  • FlexApp Layering Requirements
  • FlexApp Layering Installation and Configuration
  • FlexApp Storage
  • Creating FlexApp Layers
  • FlexApp Management
  • Updating FlexApp Layers
  • FlexApp Layering with remote Desktop Session Hosts / Citrix XenApp
  • Troubleshooting FlexApp Layers
  • Getting help with ProfileUnity

Continue reading

The new FlexApp Micro Isolation feature adds significant value to your enterprise application strategy

One of the potential challenges that application layering technology creates is around interlayer application conflicts with respect to the corresponding host operating system. In an effort to address these potential challenges, Liquidware Labs developers have created a feature called Micro-Isolation.

Continue reading