In the field, I came across a few useful tips and tricks regarding Citrix App Layering that I would like to share here. I would like to thanks our experts Dan Morgan, Rob Zylowski and Spencer Sun that helped me gather all of this great information here.

There are two great articles from my colleagues Sarah Steinhoff (Citrix App Layering FAQ) and Dan Morgan (Lessons Learned) that I definitely recommend as a background reading for this.


Updates and Upgrades

Forget PVS vDisk versioning or private mode to update applications or even apply Microsoft patches (NOTE: there are some scenarios where post-image creation steps need to be taken, for example, if an anti-virus agent needs to tag each file in the image to exempt them from on-demand scanning, but scenarios like these are the exception, not the rule). Any of these tasks should be done using layer versions through the ELM. A new app layer should be used for full version upgrades (ie. MS Office 2013 to MS Office 2016) as opposed to any updates, which would be best served as versions of the same app layer. That approach guarantee that you will always have a fresh install of the application.

Dependency on OS Layer

The dependency of an app or platform layer is not based on OS version (e.g. Windows 10); they are tied to the specific OS Layer with which they were created. This means that you should have only one OS layer per operating system you are planning on deploying, and avoid rebuilding them at all costs (which shouldn’t be an issue if you’ve followed our best practices).

New Build Process

Keep in mind that with Citrix App Layering, you will not only install new Citrix components to your environment, but you will also introduce a new OS build process, which can take time to adopt.

Number of ELMs

How many ELMs do I need to have? One! Can I, or should I have more? It depends! Since all application and platform layers are tied to a specific OS layer, if you have a ton of applications and/or want to shrink your failure domains/management domains, you could have a separate ELM for each OS you are going to support. But keep in mind that even if you create more than one, they will always be standalone appliances. In case one fails, the other will not have the same information or data.


ELM is an image build tool, should I design it for HA or even back it up? Definitely! You don’t want to lose all of your hard work creating layers if you run into an issue or a DR scenario. It is extremely necessary to have a full backup of this appliance to guarantee that you can recover all information from it. At this time, there aren’t any good alternatives. Import/export functionality was added in App Layering 4.3, but this wasn’t designed for failure recovery – while possible, this would require additional configuration/build effort in this type of scenario.


Elastic Layers aren’t just for user-based assignment! You can assign an elastic layer to a computer object (or a group containing computer objects). This will make the layer mount when the first user logs onto that machine. All users that connects to this machine will be able to see and use this elastic layer application.

A single path to rule them all? As a recommended practice, you should always evaluate the separation of Elastic Layers Repositories in different paths in case you have different datacenters, or want to limit the I/O overhead for each share. At the ELM console, you can only configure a single path. However, there are two registry values that can be modified at the target device layer to configure a new path for the repositories. These can easily be configured for different sets of VDAs using Microsoft Group Policy. These specific keys can be found bellow:

Assignments File:


Value: ULayer:AssignmentFile

Type: REG_SZ

Data: your path of assignment file

Repository Path:


Value: ULayer:RepositoryPath

Type: REG_SZ

Data: your path of Repository

I hope this can improve and help your Citrix App Layering experience.

Diego Stabile
Principal Consultant
Citrix Professional Services