Application Layers and Elastic Layering – Citrix App Layering

This post describes the method’s involved in creating Application Layers and Elastic Layers in a Citrix App Layering environment running on Hyper-V with XenDesktop and Citrix PVS. This post assumes you have the App Layering Enterprise Layer Manager appliance installed, configured, and an OS Layer in place.

To install and configure the ELM on Hyper-V – http://www.jgspiers.com/citrix-app-layering/

To install and configure an OS Layer, including Platform Layer and Image Template – http://www.jgspiers.com/create-update-os-layer-citrix-app-layering/

As mentioned, this guide runs the App Layering appliance (ELM) on Hyper-V. To see how to layer applications in VMware, see Carl Stalhood’s guide App Layers, Image Templates, and Reporting.

Application Layers can contain any type of application from Google Chrome, to Microsoft Office or antivirus. It could even include just registry keys or files if there was a need. Applications with drivers, services or other system level objects are in most cases supported by Citrix and should be included in an Application Layer. One or more Application Layers are then merged together with an OS Layer to create VDI or Session Host desktops. The compiled image is handed off to PVS or MCS for distribution to targets. Another method of assigning Application Layer’s that is new to App Layering 4.x is Elastic Layers. Using this technology, layers are assigned to users on logon based on their Active Directory group membership. Note that not all applications are suitable for Elastic Layering, especially those that do have system drivers and services that need to load much earlier in the process. Such applications should be merged with the OS Layer during the publishing of an image.

Note: If you plan to use Elastic Layers and are already using Citrix Profile Management with Profile Streaming enabled, disable Profile Streaming as it is incompatible with Elastic Layers.

An Application Layer is made up of the file system and registry entries than an application install makes. When creating an Application Layer, you select which OS Layer you want to use as the base for creating an Application Layer. A Packaging Virtual machine is created with 2 volumes attached. The first volume is the boot volume which contains the OS Layer and any other pre-requisite Application Layer if selected. This volume is read-only so cannot be modified. The second volume is writable and is where the application will be installed. As you install an application, the App Layering filter driver directs these system changes to the writable layer for capturing.

Note: Application Layers have priorities to overcome conflicts at a file or registry level. Say for example you create two Application Layers named AppLayer1 and AppLayer2. Each layer created a program.exe file within C:\. When the layers are merged using the App Layering Composite File System which program.exe is used? The layer you created last (for example AppLayer2) wins. Also keep in mind that Application Layers have a higher priority over the OS Layer. Priorities can be overridden by the administrator.

Layer priorities (1 is lowest, 5 is highest priority):

  1. OS Layer
  2. AppLayer1
  3. AppLayer2
  4. User Layer (not yet generally available)
  5. Platform Layer

♣ Creating an Application Layer
♣ Publishing Elastic Layers

Creating an Application Layer

This guide assumes that you already have an OS Layer in place. If not, read the above posts. An Application Layer is tied to one OS Layer. That means, you can’t assign an Application Layer to both a Windows 10 OS Layer and Windows 7 OS Layer. The Application Layer remains tied to the OS Layer that was used during the packaging of that layer. This post shows how to package and deploy Adobe Reader DC as an Application Layer, and then later on in the post assigning Google Chrome as an Elastic Layer.

Note: There is one exception to the OS Layer and Application Layer marriage. In App Layering 4.6, you do now have the option using Elastic Layers to assign an Application Layer to an OS that the Application Layer was not created on. This requires testing and if it does not work, you have to use the Application Layer only with the OS Layer that was used to create it.

Note: You cannot install applications on any drive other than the system C:\ drive. This is the only supported method at this time.

Log on to the App Layering Management Console and navigate to Layers -> App Layers -> Create App Layer.

Specify a name, version, descriptions and layer size in GB. The layer will be thin provisioned. Make the layer size large enough to host the application. Also whilst this picture shows a 2GB layer size, do not use a value smaller than 10GB. You can increase the value, but do not decrease.

Choose the OS Layer you want to use to create this layer. This layer will then later become deployable only with this selected OS Layer (unless you use Elastic Layers in App Layering v4.6).

If your layer needs prerequisite layers, you would specify them here. Those layers would then be available to you on the Packaging Machine that is created for you later.

Choose a Hyper-V Connector. You will have to create one if you have not done so already. Prior to App Layering 4.6, you would have had to specify the ELM Share which then resulted in you having two separate disks which require manual attaching to a Packaging VM, which you also had to manually create. Now with a native Hyper-V connector, the Packaging Machine is automatically provisioned.

The Packaging VM is what you use to boot in to the Application Layer and install the necessary application(s). In previous versions this Packaging VM was called an Installation Machine.

For steps on creating a Hyper-V connector see https://jgspiers.com/citrix-app-layering/#HyperV-Connector

If you are installing the application on a different hypervisor than what was used to create the OS Layer, you would include a Packaging Platform Layer which includes the necessary hypervisor tools to support your application install. I do not need this, so will continue on.

Keep the default values and click the down arrow.

Upload an image icon that represents the application you are installing. To do so, click the Browse button.

Click Create Layer.

Expand the Application Layer creation task. After a few minutes you should be informed that the Packaging Machine has been created. At this stage connect to your SCVMM console or Hyper-V Manager.

Connect to the newly created virtual machine.

Install the application as you normally would do for a local install. Also make any necessary modifications to block automatic updates or other user prompts. The Internet is a good place to start for looking up such modifications.

Once the application install is complete run Shutdown For Finalize. If an NGEN operation or reboot is required you will be notified to complete such tasks before the machine can be finalized.

Note: I recommend running my App Layering Preparation Script which will clean out Event Logs, temporary files, force an NGEN recompile and more before shutting down the machine in preparation for finalisation. See https://jgspiers.com/citrix-app-layering-preparation-script/

Navigate back to the UMC and click on the Adobe Reader layer -> Finalize.

Here you have the option to specify a Script Path. Scripts are useful for applications that need post-install configuration tasks such as licensing the product. The script runs the first time a machine is started with this layer. Click the down arrow.

Click Finalize.

A new task appears in the Managment Console tasks area.

Now the layer has been created and is ready to use.

To publish an application out you need to add it to an Image Template. You can also elastically assign it to users or groups which I will show later. Edit your existing Image Template which contains the correct OS Layer, click on the Application Assignment tab and then check the Application Layer.

Click Save Template Changes.

Now click Publish Layered Image to publish the image to PVS for example.

Note: You can highlight and publish multiple Image Templates at once. App Layering will publish up to 4 images concurrently.

Once the image has been published, attach it to a Target Device and boot. Test that the application shows and performs as expected. The application appears in Add/Remove Programs.

It also appears in Program Files, looking just like a local install.

You can also add Application Layers to Image Templates by selecting an Application Layer and then clicking on Add Assignments.

Now select an available Image Template to attach this Application Layer to. Likewise you can use the Update Assignments and Remove Assignments buttons to perform update and removal tasks.

You are done. You have now successfully created and published an Application Layer.

Assigning layers elastically using Elastic Layering

As the name suggests, you can dynamically assign layers to groups of users/computers or individual computers/users right as they log on. You should already have an OS Layer published which is configured for Elastic Layering. Not all applications are suitable for Elastic Layering. Some applications require loading low-level drivers which makes them a bad candidate for Elastic Layering. You can to the best of Citrix’s knowledge analyze a layer to see if it would work elastically. Keep in mind that you do need to perform your own testing of the application, do not take Citrix’s word for it. Click on an Application Layer, in my example Google Chrome and click Analyze Layer.

Click the down arrow.

Click Analyze Layer Versions.

A new task completes once the analysis is done.

Select the application again and click Add Assignments.

Click on the Elastic Assignment tab. You can see that a message appears saying This layer should work when deployed elastically. Whilst you are here, this is the page you can use to assign a layer elastically to groups or individual users/computers. For this example, I am assigning Google Chrome as an Elastic Layer to the EL – Google Chrome group. Citrix recommend creating a group in Active Directory for each Elastic Layer.

Click Assign Layer.

At this stage the layer will be copied to the ELM Share.

Browse to the ELM Share and you will find two new .json files.

The ElasticLayerAssignments.json file shows the group assignment name EL – Google Chrome, the Chrome Security Groups SID and the layer ID 3866628.

The Layers.json file shows the same layer ID 3866628 and the name of the Application Layer Google Chrome.

Inside the Unidesk\Layers\ folder is a newly created App folder containing the Google Chrome layer disk. Notice it also has the layer ID mentioned in the file name.

As a user logs on to a desktop, the Citrix Layering Service looks within HKLM\SOFTWARE\Unidesk\ULayer to find the SMB share location that holds any potential Elastic Layer. Within the share resides the two Layers.json and ElasticLayerAssignments.json files. The assignments file is read first followed by Layers.json.

Logging on to the OS Layer as a user who is a member of the EL – Google Chrome group prompts the Citrix Elastic Layer service to layer in Google Chrome.

Event Viewer also shows an event showing the user who logged on and which layer was attached.

When I log on as a user not in the group, Event Viewer reports that no layer was attached.

Google Chrome does not show in Add/Remove programs, even though another user is using that layer on the same server.

Google Chrome folders do exist in C:\ however this is a known bug. All folders are actually empty so you won’t find any files in them.

Elastic Layering troubleshooting log file can be found in %ProgramData%\Unidesk\Logs\ulayersvc.txt

You can published Elastic Layer applications as a Published Application within Citrix Studio. Just point Studio to the executable location on the VDA which will mount your Elastic Layer.

If a user is a member of a Security Group that is elastically assigned to Version 1 of a Chrome layer and another Security Group that is elastically assigned to Version 2 of the same Chrome layer, the highest version (Version 2) is layered elastically into the users session.

If a user is assigned an Elastic Layer and the base image already has that same application with a newer version installed, the user receives the Elastic Layered version. This scenario should be avoided though.

If a XenApp RDSH host is used and User A logs on, he/she may receive Firefox elastically, and User B with the same Elastic Layer logs on, but Firefox is already available so does not need to be layered again. If User A and B both log off, the Elastic Layer is kept on the VDA until that VDA is restarted. This is to support any user or User A/B logging back on to the VDA again and preventing the need for the layer to be re-attached to the VDA. The support of XenApp and Session Hosts also means that some businesses may be able to reduce their persistent desktop farms saving on the extra compute needed to power persistent desktops. Many times a persistent desktop is required because users need a different set of applications and customisations than the rest of us. Now with Elastic Layering and Citrix Workspace Environment Management XenApp shared desktops have more room to grow in the datacentre because of the way we can configure sessions to be more unique than ever before based on the user logging on.


25 Comments

  • RICHARD

    May 4, 2017

    Hi, does Citrix layering support Windows installed on D:\ or another drive letter aside from C:\.
    Have imported a 2008R2 vhdx into a OSLayer but updating it with a platform layer seems to have issues seeing D:\
    great work by the way

    Reply
    • George Spiers

      May 4, 2017

      All documents reference C:\ but there is nothing to say it isn’t supported. You should post the question to http://discussions.citrix.com/forum/1672-app-layering-4x/

      Reply
      • RICHARD HUGHES-CHEN

        May 5, 2017

        Thanks. Have done.

        Reply
        • George Spiers

          May 8, 2017

          For anyone else wondering, it is not possible. You have to use the letter C:\.

          Reply
          • Richard Hughes-Chen

            May 2, 2018

            Yep this is true but have got round the app issue by presenting a symbolic link that fools the app into thinking their is a c:\ app folder for each user

  • JAS

    July 18, 2017

    Does anyone know , or know where any official docs exist that explain, the difference between application and user elastic layers in the drop down in the Image template? It seems this page changes verbiage in the last couple versions. My guess is that if you select Applications Only(vs Application and User Layers) it is designed for machine accounts and load during boot vs. during logon but am having trouble finding info specifying this specifically.

    Reply
    • George Spiers

      July 18, 2017

      If you choose Applications Only, only Application Layers are elastically added to a machine during user logon. If you select both Application and User Layers, both Application and User layers are attached to machines on user logon. User Layers are only supported for Desktop OS and are currently in labs. Applications Layers will only be elastically assigned to users whom you have granted with access.

      Reply
      • JAS

        July 18, 2017

        Interesting… we have lab features enabled but do not see “User” layers anywhere in the Layers tab. We successfully attach application layers to assigned user and/or machine objects… so what then is a User Layer and how is it different than an application layer?

        Reply
  • JAS

    July 18, 2017

    NM my last… I found the info I needed in the 4.3 release notes…

    Reply
  • Ray

    December 8, 2017

    Can’t seem to find any information on how to add a D drive with PVS cache ram with disk overflow and wem cache? Everyone talks about it, but I don’t really see anyone doing it. Would you know?

    On my image now without app layering. I just put the PVS vdisk in private mode, added a D drive, installed wem on d drive. Shut it down, cloned it, then covered the clone to a template. Then point the PVS machine creation to the template.
    Have no idea how to do this on app layer if it’s possible now? Seems like many people have e issues with this product?

    Reply
    • George Spiers

      December 8, 2017

      PVS XenDesktop Setup Wizard adds a drive for you which will act as the Write Cache/WEM Cache etc. App Layering doesn’t affect this process. When installing the WEM Agent in an Application Layer you don’t have to have the D:\ drive present.

      Reply
  • Jason Craft

    February 2, 2018

    Any reason why Citrix Receiver could not be elastically layered? Analyze says no. Has anyone tried?

    Reply
    • George Spiers

      February 2, 2018

      Analyzer can say no but it is up to yourself to perform testing. Citrix would recommend that Receiver be placed in the Platform Layer as it contains a Network Provider as part of its SSO component.
      Personally, I would try and get it working in an App Layer – does no harm to try.

      Reply
  • Jim

    April 1, 2018

    I have a XenDesktop VDI environment, already built primarily on PVS and some MCS.
    I am not looking for an OS layer with App Layering, I am perfectly happy with the current OS provisioning methods we have and our master image update and management solution.

    What I want to achieve is decommission PVD and replace with App Layering (Elastic), so I can continue with pooled PVS VDIs without PVD.

    -I understand a packaging machine is required in the OS layer – for running the setup and capturing the settings for the App.
    -What I cannot get my head around is how I can connect App Layers to my existing VDIs in PVS and MCS without the need to represent them as OS layers.
    -Are there tools/ agents/plugins to make this possible?

    Reply
    • George Spiers

      April 3, 2018

      Nope you can’t do it. You have to go full force with App Layering to make use of User Layers and Elastic Layers. PvD will eventually be replaced with User Layers. Hopefully one day we can use certain parts of App Layering technologies with our existing MCS/PVS built images.

      Reply
  • Nick Panaccio

    April 30, 2018

    Have you (or any of your readers) experienced slow logons with Elastic Layering in Windows 10? This applies to all current builds, from 1607 to 1709. Even with just a basic image (OS: W10 1703, Platform: PVS/VDA/UPM 7.17), simply enabling Elastic layering (Application only) in the image results in a full minute added to the logon time, consistently. Others on Citrix’s forums have experienced the same thing, but nobody seems to be able to figure out the cause. I’ve had this exact issue since W10 1607 and XD 7.15 LTSR, all through today’s W10 1703 and XD 7.17. It’s probably the biggest feature we were excited to use, but asking users to sit and wait for 1:30-2:00 while their session loads is never going to fly.

    Reply
    • George Spiers

      April 30, 2018

      What size of Elastic Layer?
      Have you tried just logging on with one Elastic Layer?
      How are your machines provisioned (MCS/PVS) have you assigned enough to the WriteCache, is the WC filling up?
      Is the ELM file share using SMB3 with a 10GB link to the XD desktops?
      Anything popping out from the ELM/Event logs?

      Reply
      • Nick Panaccio

        April 30, 2018

        I’m not even using any actual Elastic layers in this 100GB image template; the Elastic (Application) option is enabled, but I don’t even have any layers assigned elastically. We’re using PVS, and with cache set to Device RAM w/ overflow on disk (1GB) , with a WC drive that has 4GB of free space within the VDI session.

        Our ELM share is on a Windows server (which is a VM hosted in ESX 6.5) using SMB3 and on a 10GB link. As for the logs, I’ve posted them on Citrix’s forums, and the Citrix guys say that it looks totally normal, and that the delay actually happens after the Layering service hands off the tasks back to Windows.

        Reply
        • George Spiers

          April 30, 2018

          Have you tried it with just the Platform Layer and OS Layer (no App layers in the image). Ruling out AV, or any other product that may use filter drivers which conflict with the Elastic Layer filter driver.
          Also try running a ProcMon to see if that flags any access denied or other errors which may explain the behaviour.

          Reply
          • Nick Panaccio

            April 30, 2018

            Yep, that’s actually what I’m doing now – just the OS and Platform stuff. No A/V, apps, etc. I did try adding a ProcMon App Layer, but it consumed so much CPU that it made the logs entirely useless. I spent a while looking through them, but nothing really stood out.

  • Will

    May 1, 2018

    Thanks George,
    We use sccm for patching and installs since the sccm agent goes in the platform layer I can’t see how it will be in the packaging machine which I believe is a clone of the OS layer. how can it be made available in the app layer to do installs?

    Reply
    • George Spiers

      May 1, 2018

      Stick SCCM in the OS Layer if you need it on a Packaging Machine.
      I assume you will open the OS Layer once per month for example and push patches through the SCCM client?

      Reply
      • will

        May 2, 2018

        Thanks George, makes sense. That’s right periodic MS patches and app updates via SCCM.
        I will stick it in the OS layer so.

        Reply
  • Anonymous

    May 2, 2018

    Hi George,
    I cannot find precise details on why all standard applications cannot stay in the OS Layer.
    Will it break the OS layer and other pieces in the process if I just have 1 OS layer with all common apps and a few Elastic App Layers with uncommon apps?

    Reply
    • George Spiers

      May 3, 2018

      I don’t think it will break the OS Layer. We just recommend splitting up each application in to Application Layers. This providers greater portability of the OS Layer, allowing you to publish images with different combinations of applications such as an image with OS Layer + Office, and then another image with OS Layer + Web Apps + Java.

      Reply

Leave a Reply