FlexApp and PVS: A Winning Combination

In my last blog, (please read this first as it goes into the actual architecture of FlexApp and how it’s different) I said I’d talk about a specific example of why you cannot simply say ‘all layering is the same’.  In that write up, I pointed out a number of differences architecturally, but I really want to bring this home and show how these differences matter.  My example is with Citrix Provisioning and how Citrix App Layering and FlexApp interact with it.

Citrix Provisioning is a very popular method of provisioning virtual machines especially in enterprise environments.  A couple of reasons why is that when deploying a new or updated image, you simply reboot the machines and when the machines are back up, they have the new image.  There are no linked clones to copy and push out.  In other words, it is extremely quick to push out new and updated images.  The second reason is that virtual machines deployed with Citrix Provisioning use less storage than other methods.  The reason for this is that Citrix Provisioning is streaming the image to the virtual machine at a block level.  The entire image is not pushed to the end point, only those blocks that are required to boot the image and run the applications.  There is a write-cache disk that is typically anywhere from 5gb to 15gb at the high end.  Client operating systems take less cache and server workloads, especially RDSH, require a higher cache.  The storage savings can be huge.  Let’s say you normally deploy a 40gb Windows 10 image and you want to deploy that to 100 virtual machines.  That would be about 4tb worth of storage but with Citrix Provisioning, you may only require 10gb per virtual machine and only require 400gb of storage.  Pretty big savings.

By its nature, virtual machines provisioned this way are non-persistent.  In the past, you would create pools of desktops or servers based on the applications being delivered.  This can create many images to manage and that can be very time consuming.  Layering can ease this problem by dynamically adding applications to a non-persistent desktop or server at boot or user login.  This would allow you to forego creating another image just to host a slightly different set of applications.  Less images, less management, more time to get real work done.

The Problem

Citrix App Layering has Elastic Layers as it’s dynamic method of delivering applications.  It does work with Citrix Provisioning, but it has a pretty big problem if you do.  It can require two or three or more times of storage for the cache disk.  Have you ever wondered why your PVS images with Elastic Layering turned on are larger than the same image without it turned on?  Here’s the answer:  I’m not going to dive into the details here, I’ll let you read it for yourself from the knowledge base here:  CTX227454.

To put this simply, if you are using Elastic Layering, you have enabled the App Layering filter driver.  The architecture of the product dictates a writable volume which, by default, is 20gb.  The filter driver redirects ALL WRITES, not just Elastic Layer writes.  Every write, whether it’s a new file or a modification, from the time the machine is powered on, forces the full copy of those files to the writable partition.  If the file is part of the image, then it’s a double whammy because now you must cache the entire file down to the write-cache and copy it into the writable partition which, again, goes to the write-cache.

Why isn’t PVS with FlexApp Affected?

FlexApp doesn’t require a separate writable partition and, more importantly, it simply doesn’t redirect the entire Windows file system in regard to writes, it allows Windows and the provisioning mechanism to do their thing.  You can look at it as a handoff.  The FlexApp filter driver looks to see where the write is coming from and determines who handles the write.  If it’s a call from an application in the FlexApp, the driver redirects it to a small cache (a VHD).  If it’s anything other than a FlexApp write, then it simply hands that off to the operating system.  In the case of PVS, it’s allowing PVS and/or operating system to make the decision on what happens to that call.

Get the Best of Both Worlds

Saying all this, Citrix and Liquidware do have joint customers that use Citrix App Layering for their image management and FlexApp for layering dynamic applications.  Simply do not turn on Elastic Layering for the image.  This plays to the strengths of each product.  Citrix App Layering is, first and foremost, an image management product and FlexApp is application delivery.  Combine them and you get the best of both worlds.

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.

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.

Continue reading

The Best Tool to Measure and Trend User Experience (UX)


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…


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


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