Citrix Elastic Layers versus FSLogix App Masking

I first started using Citrix App Layering in 2017, shortly after Citrix purchased Unidesk.  It greatly improved master image creation and maintenance.  It also introduced the ability to elastically layer applications to present to users, rather than including those applications within the master image.  This allows applications to be provisioned to users much faster, since it does not require a master image update and rollout to the Citrix VDI machine catalog.  

Once I started to use elastic layers, I very quickly realised that VDIs provisioned to users with elastic layers were not quite as responsive as those without.  In fact, the more elastic layers I had assigned to a user, the slower response times for applications seemed to get.  I frequently received complaints from users that Outlook, for instance,  was taking a very long time to load in the VDI. 

After a lengthy Citrix case, and working with an original Unidesk developer, I demonstrated that, with elastic layers enabled, we see increased file system and registry operation times.  The final response on the case was “we’re left with an unsatisfying ‘this is just how it’s going to work for you’, which means you have to weigh that in your overall calculus for whether the product is an appropriate fit for your requirements.”.   

The issue stems from the use of a mini filter driver. Mini filter drivers intercept file system and registry calls and direct the request to the appropriate elastic layer or base VDI disk (if the target of the call is not present in any of the elastic layers).  I was informed that various improvements were planned, one such improvement is to cache the result of the file system and registry operations, so that subsequent calls to the same location will go directly to the layer containing the file/registry item.  Rather than searching through each attached layer each time. 

This slowdown has always left me a bit disenchanted with the prospect of using elastic layers.  Whilst I love the concept of quickly provisioning apps to users and the lower impact on support teams to rollout application updates, I do not want this convenience at the expense of the user experience.  For me, the user experience is always paramount.   

After looking for alternative options, I found FSLogix.  Most people already know FSLogix for its excellent user profile container solution, but one of its other features is the ability to mask applications, such that selected applications can be hidden from users who should not see them in the VDI.  After experimenting with the product, I found that app masking did not introduce a significant delay to application response times when compared to elastic layers.  However, this was just my own gut feeling, I had not done a direct comparison or tested with the most recent version of app layering….Until now! 

I decided to create 2 identical VDIs running in Azure from Citrix Cloud DaaS. One VDI using applications delivered elastically, via app layering, and the other which uses FSLogix to unmask applications from the base VDI disk.  The end result is, regardless of which VDI the user is logging into, they have the applications they expect.  I would then time the Outlook launch, whilst also running procmon in the background to gather the file system and registry operation durations (whilst procmon itself uses CPU, it would be same for each test). 

For the test, 4 applications were elastically layered/unmasked for the user (7zip, Google Chrome, Notepad++ and WinSCP).  Prior to each test, Outlook was launched twice to ensure any potential app layer result caching would have been done.  Citrix app layers were stored in an Azure premium file shares storage account for the best performance in Azure. 

Here is the side-by-side video of the Outlook launch time.  There are three videos, FSLogix app masking, elastic layering with 4 layers assigned and elastic layering with no layers assigned.  The third video is intended to highlight the difference between no layers and multiple layers being assigned.

As you can see, the FSLogix app masking VDI opened Outlook in 16 seconds, the VDI with 4 elastic layers took 37 seconds, the VDI with no elastic layers took 22 seconds. If we showed our target users the video and asked them to choose which VDI they would want, I’m sure we all know which they would pick.  

So, what causes this difference?  We can investigate the Procmon traces, filtering the Outlook.exe process, to see the registry and file system operation durations. We can see that, for the image with 4 elastic layers assigned, most operations are slightly slower.  Here are a few examples: 

Whilst, for the 4 individual operations, the difference in time may seem small, if we consider that Outlook performs ~100k registry and file system operations during  startup, the net increase in time is significant.  Similarly, applications such as Excel make a large number of registry and file system operations, especially whilst macros are running, or a large spreadsheet is recalculated. 

I’ve included a spreadsheet showing a side-by-side comparison of all the operations by Outlook.exe for each test.  Whilst the lines do not exactly align, you can easily find the equivalent operation for each test.  I’ve also included the original procmon traces for anybody wishing to look for themselves. 

I think the results highlight 2 important points which should be considered when designing a VDI solution that requires certain applications to be made available to selected users:  

1. You need to clearly understand what you are trying to deliver with the solution and who it is targeted at.  Are you looking to provide users with the best possible user experience?  Are you looking to make support easier for the support teams?  Are you looking for a balance of the two?   
2. You should look to test different options within your target environment.  Each environment will have different networking and storage setups.  Elastic layering may not introduce the same level of delay within your own environment, or it could be worse.  Understanding the impact it has on response times within your own environment will most likely feed into decisions made for point 1.

I am by no means anti-elastic layering; I do see the benefits it can bring in the right circumstances and there are scenarios that elastic layering can successfully deliver that FSLogix App Masking cannot (such as provisioning different versions of an application to different users in the same VDI).  I should also add that I like Citrix App Layering in general and I would not want to go back to the days of maintaining multiple different master images.   

My opinion is that the user experience should come first.  Technology is there to enable the business to operate. If we can improve the customer experience, and performance of systems, by using alternative solutions, we should. As such, if there were no requirements preventing the use of FSLogix App Masking, then this would be my go-to option and I would leave elastic layering disabled. 

If you are creating a new Citrix environment or looking to improve an existing one, InfraTech Systems can help.  Get in touch and we can help you improve your user experience and maximise your investment in Citrix. 

I wanted to include a little more information about the test environment used.  Details for this are below: 

Citrix Cloud DaaS Standard for Azure

• 2 Azure based Citrix Cloud Connectors running in UK South (SKU Standard A1 v2 – 1 vcpu, 2 GB memory)
• 2 Machine catalogs.  One for the elastic layering image, and one for the FSLogix app masking image (SKU Standard D2s v3 – 2 vcpus, 8 GB memory)
• 2 Delivery Groups – One for the elastic layering image, and one for the FSLogix app masking image

Citrix App Layering Enterprise Layer Manager (ELM) 

• Version 2211, running in Azure (SKU Standard_D2ds_v4 – 2 vCPUs, 8GB RAM).
• Configured with the new Azure connector to resources in UK South (side note: this is a huge improvement)
• File share configured to use an Azure Files Premium Storage Account
• OS Layer imported for Windows Server 2022 Data Centre (Azure Marketplace image after running Citrix Optimiser and installing app layering machine tools)
• Platform Layer configured with Citrix VDA 2203CU2
• App Layers for:
  • Office 365
  • 7Zip (with an elastic layer assignment)
  • Google Chrome (with an elastic layer assignment)
  • Notepad++ (with an elastic layer assignment)
  • WinSCP (with an elastic layer assignment)
• Template images:
  • Template 1 – Elastic layering disabled, all layers added
  • Template 2 – Elastic layering enabled, OS, platform and Office 365 layers added

Azure components

• Hybrid AD, with domain controllers running in Azure with ADConnect installed locally
• Premium files shares configured for ZRS.  Domain joined.  Service endpoint enabled for the VDA VNET 

Other elements

• No user profile management.  Local profiles were used.
• Limited GPO applied, only the necessary GPO was configured to allow logons.

Download Links to comparison and raw procmon files

Side by Side procmon

ProcmonTraces