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.

Layer-Stack.png

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:

MicroIsolationEntries

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 Best Tool to Measure and Trend User Experience (UX)

Preface

I want to start by discussing monitoring in general.  Monitoring products are in a funny place in the IT world.  Many companies consider them a luxury and not necessarily a requirement.  When they do start going down the monitoring road they almost always start by looking for a product that can do it all.  This will typically lead to the conclusion (correctly) that there is no singular product that can do it all.  One thing I learned while growing up with grandparents and my dad being produce farmers, you always pick the right tool for the job.  As they say, and I believe this applies to monitoring software as well, if all you have is a hammer, everything is a nail.

Continue reading

ProfileUnity – Defining User Experience

ProfileUnity has been around for a number of years in the Liquidware portfolio. It delivers user environment management, including user profiles, secure policies, and access to user authored data. Sounds simple right?  After all, there are other one-off tools in the market that handle these individual things.  What sets ProfileUnity apart?  Why use it when you may already have “free” single use case tools or a solution provided by another vendor?  Read on my friends…

Profiles

First off, the Liquidware portfolio (ProfileUnity, FlexApp, and Stratusphere UX) is completely agnostic by not favoring a particular desktop delivery platform.  Really, what we are managing is Windows. That’s it.  We have no requirements for a particular broker, hypervisor, cloud, anything. In fact, with all three products, you can manage Windows across physical, virtual and cloud.  Are your desktops completely physical today and you are looking at moving some or all of them to virtual or full cloud. Or are you even going back to physical desktops?  Liquidware has you covered the entire way.

Continue reading

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

Introduction

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

Hello EUC World, It’s Me, Jeff Pitsch

For those that don’t know me, I’ve been in the EUC space for 20+ years.  I cut my teeth on WinFrame in what feels like a lifetime ago (in technology time it actually was).  In that time, I was a founding member of the CTP program and a Microsoft MVP for a number of years in Terminal Services/RDSH.  I’ve worked with small companies and Multi-national corporations on their Citrix environments but six and a half years ago I took a job at a company called Unidesk.  They had this technology called layering and it offered a way of delivering applications that was unique.  Over those years layering companies have come and gone (including Unidesk) but layering has grown in popularity and has, in my opinion, really started to take off in enterprise application deployments.  Why has it taken so long?  Simple answer is every technology takes time to grow and when it reaches a certain point it either stays and grows or dies on the vine.  Basically, smaller companies work out the “new technology” kinks and enterprises pick it up from there.

Continue reading