Citrix App Layering went through a huge transformation process in 2022, with the developer doing a fantastic job rewriting a big part of the code. First, we moved from the legacy Microsoft Silverlight console to a new, modern UI. And with the 2211 release, we introduced a completely new type of connector for Azure — Azure Deployments.

This new connector introduces a lot of changes to how Citrix App Layering operates in Azure. To align with leading practices, the team rewrote the code to leverage on Azure Deployments using Azure Resource Manager (ARM) templates.

This means the configuration of the Azure Deployments connector is entirely different from what we had done before, and we needed to acquire and master some new concepts to make it work. This blog post provides a guide to configuring the new Azure Deployments connector and all the required objects in Azure.

The old Azure connector leveraged storage accounts to deploy virtual machines. If you tried it using premium storage account, you certainly know about its performance issues.

The new connector uses ARM deployments and managed disks directly. No more performance issues. All layer composition operations are fast (as they should be). And we did even more. Now we can use compute images to speed up layer management operations and Citrix Machine Creation Services deployments. The new connector is definitely a major improvement.

Before we dive in, though, I wanted to recognize Gavin and Wendy from the Citrix Technologist team in Dublin. I enjoyed working with them, digging into every small detail of the new App Layering version.

Configuring the Azure Deployments Connector

One big change that comes with the new Azure Deployments connector is the authentication method. The connector uses a managed identity associated with the enterprise layer manager (ELM) appliance.

A managed identity is an enterprise application within Azure AD that can be used by an Azure resource to authenticate to any service that supports Azure AD authentication. This eliminates the need to manage credentials at resource level. No more ClientId and secrets!

To simplify the deployment, it’s good practice to create a resource group dedicated to Citrix App Layering and configure all the needed resources inside it. Then you can assign the Contributor role to the ELM’s managed identity directly on the resource group.

There could be one exception. In production environments, the virtual networks are often configured in a dedicated resource group. In this case, you need to assign the same role — Contributor — directly to the virtual network you need.

Returning to the managed identity, you can use a system identity as well as a user identity, but the easiest way to start is by using a system identity. To enable it, open the EML virtual machine properties, select Identity, and under System assigned, set the Status to On.

Once the identity is configured, you can assign the Contributor role to the needed resource groups.

The next step is managing the Azure ARM templates. We provide four different JSON templates: Boot Image, Cache Disk, Machine, and Layered Machine. You can use the templates as is or customize them to meet your specific needs, and you can find them here.

To use the templates, you must import each one into Azure Template specs, which is essentially an online repository for ARM templates. The process is easy. First, copy the ARM template text using the copy button, as shown in the image below.

Then paste it in your text editor and save it as JSON file.

Repeat the process for the other three templates.

Now, go back to the Azure Portal and open “Template specs.” Click “Import Template” to upload your JSON files.

Follow the import wizard and set the template’s name and version. Select the correct Subscription and App Layering dedicated Resource Group.

Repeat the process for all the templates.

Understanding how each ARM template is used by the EML appliance during its operations might look a bit complicated. It’s not. Using the two required (mandatory) templates — Cache Disk and Machine — the ELM appliance deploys a virtual machine. It uses the Cache Disk template to create a boot image (a managed disk). With that, the ELM starts the composition engine to create a virtual machine.

If you add the boot image template, the process and its result does not change; it creates a virtual machine. The only difference is related to the boot image. Instead of being deleted at the end of the process, it is saved in the compute gallery to be reused. This shaves a couple of minutes off repetitive tasks such as updating multiple application layers.

If you also add the layered template, the result will be slightly different. Instead of a virtual machine you will end up having a new compute image as shown in the image below.

With compute images, you get some huge benefits over a standard virtual machine. Compute images are stored in a compute gallery. Images benefit from regional storage redundancy (zone redundant storage, or ZRS), possible replication in different Azure regions, and versioning support. Also, if you are using a compute image as the source image for your MCS deployment, the operations will be extremely fast.

Get more details on the Azure template specs and their utilization.

Next, add an Azure compute gallery to the App Layering’s resource group. Just open the Azure compute galleries service page on the Azure Portal and click Create. On the next screen select the correct subscription and resource group, then set the gallery name as shown in the image below.

The result will look something like this:

Your prep work is almost done now, and you need to return to the ARM templates for a few additional details. We designed the ARM templates to use parameters, as highlighted in the image below. They are passed to the ARM templates during deployment.

The idea behind this is to keep the templates as flexible as possible so they don’t need heavy customization.

The following table lists the parameters each ARM template uses (click the table to view larger or find it in our product documentation). It specifies which parameter applies to each template and whether the parameter is required or optional.

Where R = Required, O = Optional, – = Not used

The only required parameters are the gallery’s name and the subnetId. All the other parameters are optional. If not specified, ELM will use the default values.

Parameters must be specified using the JSON formatting. You can find a couple of examples at the beginning of the Starter Template page.

Here’s an example of custom data:

One thing to note about the diskAccessID is that, if not specified, the network connectivity to the managed disk created by ELM will be configured as a public endpoint (all networks). Many organizations will flag this as a security risk. We recommend configuring the disk access by following Microsoft documentation on how to restrict import/export access for managed disks using Azure Private Link.

Now you’re ready to configure your first Azure Deployments connector. But how do you find the values of all the above parameters?

It’s JSON to the rescue. On the main page of each Azure resource there is a JSON View link in the right top corner, as shown here:

Click it. Inside the new page you can find all the information you need. Use that to update the custom data file.

Finally, you can configure the new Azure Connector by logging into the ELM console and selecting Connectors, then clicking on Add Connector Configuration.

You can create two types of connectors: the Azure Deployments and the Azure Deployments for MCS. The second one is specific for creating MCS base images (Layered Images).

To start, choose Azure Deployments, as shown below, then click New.

Set the connector’s name. Then, at least for the Cache Disk and Machine deployments, configure their Template and Resource Group. Starting with the Machine deployment type, you need to specify the related ARM template and the resource group as shown below

On the Template, click Browse, expand the resource group(s) and select the correct template from the available ones.

Similarly, select the resource group.

Repeat the same process for the Cache Disk deployment type.

You can add the Layered Image and Boot Image deployments by clicking on the related button in the Optional Deployments section.

Now you can specify the custom data properties in the initial default section, as shown here:

When done, click Confirm and Complete at the end of the page. Then click Save.

Now you’re ready to test your new Azure connector. Just remember, it works in a very different way from the previous one. For example, if you publish a layered image, you will get a computer image in the resource gallery, as shown here:

You can use it as the image to create a new machine catalog. In the Machine Catalog wizard, when you need to select the image, browse the App Layering’s resource group. Inside the compute gallery, you will find your new image, as shown here:

The new Azure Deployments connector comes with a lot of new moving parts in Azure. Understanding the new configuration process requires some time and, like in my case, it requires some learning.

Final Notes

As I wrap up, I wanted to share a few important notes. First, because the new connector requires managed identities, you must deploy the ELM appliance in Azure. You cannot configure it on your existing on-prem appliances because you cannot assign them a managed identity.

Another common question is about the OS layer. We recommend creating a new OS layer starting from a clean Azure virtual machine to avoid issues with drivers and other additional components that Azure uses. Remember, app layers are strictly related to a specific OS version. You cannot add an app layer created on Windows Server 2019 to an OS layer based on Windows 10 multi-session.

Finally, you might be wondering about legacy Azure connectors. They are deprecated but are still available for a limited time. There’s no upgrade or migration path from any legacy Azure connectors to the new Azure Deployments connector.

I hope this blog post will help you in setting up the new Azure Deployments connector. By using it, you’ll get to enjoy all the benefits of this modern way to deploy Azure resources. All layer operations in Azure will be quicker than ever, and creating or updating a machine catalog can happen a matter of seconds.

Here are some additional resources as you start your journey and have some fun!