How FlexApp Handles Layer Conflicts

One of the things I love about FlexApp is that it has taken the layering paradigm and essentially turned it on its head.  We’ve all “grown up” thinking of layering as done in a particular way but FlexApp shows there are other ways of accomplishing the task of delivering applications dynamically.  One of the critical designs of layering is figuring out what happens when files, folders or registry entries conflict.  FlexApp uses a technology called Micro-Isolation to handle these types of conflicts.  The technology was developed because of how FlexApp builds the view of the operating system file system and registry.  It is a very different way of looking at how layers are laid down on the image and how conflicts are handled.

To understand Micro-Isolation, we have to understand how layering technologies address conflicting files and registry entries in the layers themselves.  Here we are focusing on the file system but the concepts apply to the registry as well.

Layering products all use a mini-filter or filter driver that creates a virtual file system from disparate disks that Windows see’s as a single hard drive, the C drive.  Traditionally the view of that file system is built on the fly.  If you open file explorer and go to a folder that hasn’t been viewed before, the driver will read through the layers to find the appropriate files and folders for that view.  It then caches those locations so it can access them directly next time.  Sounds simple and efficient but under the hood it is a bit more complicated.

To build that on the fly view of the file system, the driver reads through the various layers and returns a single view to the OS and user.  What happens if a file exists in two different layers in the same location?  How does it know which one to use or show?  This is where it gets interesting.  Other layering products use a system called layer priority.  Each layer is assigned a priority and this priority determines where, in the stack, the layer is located.  This priority is typically determined by layer creation date and time.  The newer layers have a higher priority than older layers.  The operating system is always the bottom layer (lowest priority) and the user layer, if one is there, is always at the top (highest priority).  When the driver wants to locate a file or folder for the first time, it starts from the top of the stack and reads down.  It either finds what it’s looking for or it doesn’t.  The key is that it stops looking when it finds the first instance of a file in the stack.  It has no knowledge that there may be other files with the same name and location in lower priority layers.


There are other concepts that go along with the layer stack concept like delete tokens and switching layer priorities to eliminate some conflicts.  I could go more in depth but the above gives a good understanding of layer stacks.  Now let’s discuss how FlexApp handles its virtual file system.

FlexApp uses a filter driver to give Windows a single view of the various disks in play just like other vendors, but how the view is generated though is fundamentally different though.  There is no concept of a layer stack.  It is more like puzzle pieces coming together.  It is a flat view versus a hierarchal view.  This changes how the layers interact with the existing file system and operating system.

FlexApp Puzzle

Because of the flat nature, certain concepts are very different than way layer stacks work.  One of the biggest concepts to understand is that FlexApps do not supersede files in the image.  If a file exists in the image and in the FlexApp, the image wins.  Another concept to understand is that when a FlexApp is attached it is using reparse points to redirect to the appropriate folders and files.  The filter driver does not need to need to build the file system view on the fly.  It already knows where the files and folders are and will redirect file system calls directly to the appropriate FlexApp.

We know that a FlexApp will not overwrite a file or folder that originates in the image but what about FlexApp to FlexApp conflicts?  This is the purpose of Micro-Isolation.  When a user logs in or, if they are computer assigned FlexApps, the machine boots up and the FlexApps are mounted, there is a process happening called FlexApp Replay.  Replay is doing a few things but most importantly it’s creating the reparse points, setting up the registry appropriately and finding the conflicts for the Micro-Isolation feature.

The way Micro-Isolation works is by redirecting the call to the file in conflict back to the same FlexApp. For example, let’s say FlexApp1 and FlexApp2 both have a file located in c:\test\Conflict.txt.  If FlexApp1 makes a call to that file, the call is redirected back to the FlexApp1 layer and pulls the Conflict.txt from there.  If FlexApp2 calls Conflict.txt, it gets it from the FlexApp2 layer.

Micro-Isolation Concept

The list of conflicting files is generated at user login or computer boot with one exception; when a FlexApp is flagged as Click-to-Layer.  The Click-to-Layer FlexApp’s conflicts are determined when it is opened.  At that time, the FlexApp Replay process generates a new Micro-Isolation list that takes the Click-to-Layer FlexApp into consideration.  For example, if a user has five FlexApps assigned to them and three are layered in at login and the other two applications are Click-to-Layer, the three applications mounted at login are queried to find conflicts for Micro-Isolation.  Later in that session, the user starts one of the Click-to-Layer applications, then the Replay process redoes the list and now those four applications are set for Micro-Isolation if needed.  It would be the same for the other Click-to-Layer application when it is started in that session.

Because the Micro-Isolation conflicts are determined dynamically every time, the entries are stored in memory and cannot be modified.  To see the conflicts that Micro-Isolation is monitoring, a user or administrator can invoke the following PowerShell command:

Invoke-RestMethod http://localhost:9072/api/microisolationentries | ConvertTo-Json | out-file $env:TEMP\microisolationentries.txt

The exported text file will look something like this:


Let’s be clear about what Micro-Isolation is and is not.  Micro-Isolation is designed to handle file and registry entry conflicts.  It is not application isolation like App-v or ThinApp.  FlexApps are treated and act as if they are installed locally to the operating system.  They have full access to the operating system and full access to other applications if applicable.  The operating system has no idea these applications are not actually installed on the C drive.  Isolation technologies like App-v and ThinApp are designed to put the entire installation of the application in an isolated bubble and then, if you want it to communicate to other applications, the administrator has to purposely edit the package and “poke holes” in the isolated bubble.  Micro-Isolation is designed the other way around.  It only isolates the files and registry entries that have conflicts.  If there are no conflicts between layers, then Micro-Isolation doesn’t do anything.

The next question that comes up a lot is, can we use Micro-Isolation to deploy applications that require different versions of Java or some other underlying supporting technology.  For example, could FlexApp1 have Java 6 in it and FlexApp2 have Java 8 in it.  Technically, you could but it would be a very bad idea.  Micro-Isolation, at such a large scale, would cause very high CPU usage.  It must work hard to redirect every single file call appropriately.  It has to determine what is needs to be redirected on a file by file basis.  This is one of the reasons Liquidware highly recommends putting supporting technologies like Java, Visual C++ runtimes, .NET, etc in the standard image.


The 9 Most Requested Layering Features Over The Years And FlexApp Has Them


This blog is really about what I thought I knew about layering products and how much I simply didn’t know.  I’ve been working with layering for about as long as anyone and I made the mistake of thinking that all layering products were essentially the same.  Sure they each did things a little differently but in the end the concepts were the same and their abilities were, for all intents and purposes, the same.  Boy was I wrong.

Continue reading

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

Kick-off – Het Liquidware Tech Insider Programma 2018

crowd-2045289_1920Begin 2018 is het zo ver, vanuit Liquidware Nederland starten we met het Liquidware Tech Insider Programma. Het programma zal zich volledig focussen op het delen van kennis en ontwikkelingen rondom het Liquidware portfolio, waarbij we de deelnemende IT/EUC-professional uiteraard niet met lege handen naar huis sturen. Wat wij hiervan verwachten? Een gezellige tijd met gelijkgestemden en oprechte feedback, dat is alles.

Continue reading

The future looks bright for User Environment and Workspace Management

ProfileUnity is hot, there’s no denying. Everywhere I go partners and (potentially new) customers keep asking for demos, and as soon as I show them a thing or two they are eager to get their hands dirty. In fact, the number of trial licenses I have been handing out throughout the last couple of weeks must be some kind of a new internal record (I’ll make sure to check). Seriously, the demand for a future stable, easy and straightforward to use User Environment and Workspace Manager product has been higher than ever before.

Continue reading

FlexApp version 6.7 release – Features overview

The release of FlexApp version 6.7 this week marks a tremendous set of milestone achievements for Liquidware. In a competitive industry, it is important for software platforms to constantly evolve or run the risk of being replaced. This release builds upon the leadership position that FlexApp has held for a while now.

Continue reading

Application Layering VS Operating System layering

Managing desktops is always one of the main struggles facing enterprises. Add in complex application management and the issues increase drastically. Software solutions are often geared towards relieving this pain. Over the last few years, the concept of converting the … Continue reading

FlexApp Layering = Enterprise Optimization Revolution

I was presenting to our sales teams at the Liquidware Sales kick off recently and was fascinated by the following response I received.

“Why wouldn’t you leverage FlexApp in your environment? At this point enterprises have virtualized infrastructure, desktops, networks, and storage but still continue to install applications natively.”

Continue reading

Enterprise Strategy for Healthcare EMR platforms

Many EMR (Electronic Medical Records) platforms used by the healthcare industry are often described as a Hub and Spoke model. Where patients and medical staff interact with countless smaller software packages and then feed data back into the centralized management platform. Patient management, Scheduling, Clinical oversight, are just some of the areas of focus within the main EMR platforms. From an IT perspective, this can become a daunting proposition, considering you must install and maintain each of the individual software packages including the centralized management platform.

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