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.