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.

Special Guest Blog: A Journey with Stratusphere UX

I’m excited to share this contributed post as it’s a topic and message I believe is quite important. In this new edition, end-user computing expert Peter von Oven writes of the user onboarding process and taking a user-centric approach to the transformation journey.

I love the approach of Putting User Experience at the Center of the Workspace. It’s an approach that is near and dear to Liquidware; and a core tenant of how Stratusphere UX has been designed. Peter’s book is focused predominantly on practical and actionable methods to best manage the user lifecycle of VDI atop the VMware platform, but the overall message is relevant for all user transformations—physical, virtual or cloud-delivered.

Look for it now at Packt Publishing and very soon on Amazon. Congrats Peter. –Kevin

Special Guest Blog
Author: Peter von Oven

So now that I have completed my 11th book on virtual desktop infrastructure with VMware Horizon (shameless plug box ticked), I’ve had chance to reflect on the content. The idea of the book was not to be just another installation guide. After all, the technology piece is easy, but the why do it in the first place, and how to do it is far more of a challenge. Instead, the idea is to treat the whole project as a journey, starting with what initiated the project in the first place, building the business case, analysis, proof points, and then deploy some form of desktop delivery technology. Whether that be cloud-based, on premises VDI, or even physical desktops for that matter. This is where the Liquidware technology comes into its own and becomes your travel companion for the journey.

So, to put that into context. The journey undertaken in the book in this case consisted of three distinct parts. Planning the journey, so looking at what you have in place today, planning how to get there, and then looking at the destination; where do you want to end up at. One important point to highlight is that these parts are not to be taken in isolation and form the entire itinerary just to go back to the journey analogy.

Planning the End User Journey

How does that relate to the Liquidware Stratusphere UX solution? First off in the planning stages, and understanding what you have in place today, or finding your baseline. Afterall, there is no point looking at planning any journey if you don’t know where you are starting from. For example, in my role as an EUC consultant I often ask the customer the question of “how many apps do you have?” Quite often the answer starts with “erm…” or “about”. Those that do roughly know, typically I would end up having to apply the rule of ten. Whatever number the customer gives you, you simply multiply that by ten to get the real answer. Stratusphere UX can answer this question easily and precisely. It builds that baseline of your desktop estate, creating a comprehensive inventory, right down to the level of what resources are being consumed, and even a complete breakdown of the login process. Not only that, it can tell you which machines are ideal candidates for virtualizing, or can be migrated to a cloud-hosted workspace. Equally it will tell you those that would not be, complete with the reasons why.

Now armed with that baseline and a complete picture of your environment, the journey can continue, and you can start testing and deploying your chosen technology platform. But how do you know you are headed in the right direction? The answer is Stratusphere UX again, this time with its ability to take the baseline of your environment and comparing it to the solution you are testing. In this scenario Stratusphere UX helps fine-tune the environment before you deploy into production and onboard your end users. You can easily tune the environment to ensure the end user experience is at its optimum. This is the key advantage that Stratusphere UX offers. Although it can monitor the infrastructure, it concentrates on the end user experience. Perfect, as the end users and their experience is going to make or break the environment and so delivering them the best experience possible can only be a big plus point. It’s the difference between success and failure. You can deploy the fastest most up to date infrastructure, yet if a user logs on and receives a poor performance then its game over. In this scenario often infrastructure monitoring tools report that all is well, yet the user reports otherwise. Stratusphere UX turns this the other way round and starts with the end user.

Journey’s End. Or is it?

Now at this point organizations have assessed, tested, and deployed their desktop environment and so think they are done. Wrong. The onboarding may have been completed, however the end users’ real journey has just begun. What happens if their circumstances change?  Maybe they change roles and therefore app requirements change. Overtime apps and OS’s will update, meaning a potential change in resource requirements. It’s a strong possibility that the first time you’ll know about it is when they call into the help desk to report an issue with performance. This is where the ongoing monitoring Stratusphere UX delivers comes into its own. The ability to track usage and resources proactively is invaluable. As is the ability to check whether the issue is affecting one user or your whole user estate, before it becomes a bigger issue. But that’s just the start.


The biggest takeaway for me having Stratusphere UX along for the ride as the book moved through its journey along the different project phases – from project definition, design and testing, deployment, and ongoing management – is that it’s not just about assessment.  It’s not just about tuning, and it’s not just about management and troubleshooting. It’s all about end user lifecycle management. How to understand your current environment and plan the onboarding of the end user onto a new platform, whether VDI, cloud-based desktops, or even a hybrid approach. Then, once onboarded, to continue to manage that user for the lifetime of them consuming resources, ensuring they always receive the best experience possible.

Special Guest Blog: Windows Virtual Desktop (WVD) with Azure: User and Workspace Management from Liquidware Webinar – by Symon Perriman

SymonSpecial Guest Blog
Author: Symon Perriman
(Symon@SymonPerriman.com, Twitter @SymonPerriman)

Desktop virtualization (or “VDI”) has become commonplace for organizations which need to offload processing from their end user devices to managed desktops due to performance or security needs.  Over the past decade, millions of these temporary virtual machines (VMs) have been created and destroyed by enterprises for their remote site workers, task workers, power users, or those operating in regulated industries with strict compliance needs.

Continue reading

Microsoft WVD and Liquidware – Better Together – NEW Joint Solution Brief!

clarkquote(2 minute read) – Microsoft WVD (Windows Virtual Desktop) is coming and Liquidware is hearing from many customers that they plan to deploy a proof-of-concept or pilot to test the waters as soon as possible. Microsoft has a public preview program in the works and you can now register here to apply for access to the program. If you’ve been following Microsoft WVD you’ve seen that Liquidware has been named by Microsoft to the short list of focused partners that Microsoft is working closely with, as mentioned in this Microsoft blog.

Continue reading

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

Multi-Faceted End-to-End Visibility with Stratusphere UX

In previous posts I’ve written about real time visibility, and whether it’s a necessity or red herring. I’ve also written about quantifying the user experience and putting user metrics at the center of your workspace visibility effort. And regardless of whether you employ physical PCs, on-prem multi-session shared infrastructure or cloud-based solutions to deliver your end user workspaces, I hope you subscribe to the following core tenet… User-centric visibility is paramount in the monitoring and diagnostics of the end user workspace.

Continue reading