At Citrix, we recently held ServTech, an internal technical conference attended by most internal customer-facing technical employees and many partners. I think it says a lot about Citrix that we are willing to spend the significant amount of money involved to host this conference. I know all of us technologists really appreciate that fact, as we have all worked previously at companies that would not invest that way in our success.
When I was planning on what session to develop, I wanted to come up with a something that would be technically sexy, so it would, for sure, be selected for the conference. I had recently worked on a project using Citrix Cloud and Azure and it seemed a no-brainer, with my background in App Layering, to go for combining Citrix Cloud, Azure and App Layering into a session. I enlisted help from a couple colleagues and we defined our goal for the session, which was to make it easy for anyone to start a project integrating Citrix Cloud, Azure and App Layering. Truthfully, it is sexy and it was accepted.
The sessions at ServTech went well, so I thought I would convert the presentation into a blog post, so that all Citrix customers could benefit from the work we did when creating the session. With that? Here we go…
If you are going to do a POC or deployment in Citrix Cloud, App Layering and Azure it’s important to understand the main terms/concepts for each technology. So, we will go over the most important ones quickly for those who are new to these technologies.
Resource Group – a container used in Azure to hold objects with defined permissions.
Availability Set – a collection of VMs managed to provide availability of at least one VM in the collection at all times. Virtual Machines in an Availability Set are spread across fault domains (racks and storage) and they are managed at separate times for automated updates.
App Registration/Service Principal – An Azure AD object that holds permissions for Azure resources for applications. For example, for Citrix Cloud Integration or the App Layering Azure Connector.
Storage Account – A container to provide name space and access to storage files and blobs
Resource Locations – Like Zones these designate where cloud connectors are located. For example, Azure East US.
Hosting Connection – Configuration information to connect to a resource location.
Machine Catalog – Container in Citrix Studio that defines all the Virtual Machines built with the same image.
Delivery Group – Container in Citrix Studio that allows administrators to assign virtual desktops, hosted desktops and published applications to users.
Enterprise Layer Manager (ELM) – A virtual appliance that provides all the functionality for and manages Citrix App Layering.
App Layering Management Console (ALMC) – Web based administrative interface for Citrix App Layering. Accessed from the ELM appliance.
Azure Connector – This is thecode within Citrix App layering that interfaces with Azure and performs SDK calls to create packaging machines and publish images.
Gold Image – Virtual Machine used to create the OS layer which is the basis for all layers within Citrix App Layering.
OS Layer – Layer for Operating System. For example, Windows 10 or Server 2016.
Platform Layer – Layer for the hypervisor and provisioning system in this case XenApp or XenDesktop VDA
App Layers – Containers for applications.
Layered Image – OS, Platform and App layers combined to make a master image used by MCS to create a Machine Catalog.
Elastic Layer – Dynamically attached application layer. Mounted from the “Elastic Layer Share” by the Windows VM at logon.
User Layer – User Writable Elastic Layer – All user writes go into this layer. This is currently still in labs (beta).
Office 365 Layer – User layer for outlook files in the profile.
Now that we have level set the terminology we can move on to why you might want to use App Layering in Azure.
Why Use App Layering on Azure
The first thing I think should be discussed is why would one use App Layering in Azure. The answer to this is that for the same reasons you would use it outside of Azure:
- If you have lots of use cases that require you to manage many MCS images or if you would limit your use cases because you can’t handle managing too many
- If you want to limit the reboot requirements for XenApp servers by using Elastic Layers to dynamically deliver applications and application updates when users logon
- If you want to obtain all the advantages of non-persistent shared desktops like high availability and redundancy, but still have need for the persistence that User Layers will provide when they are fully supported (user layers are currently in labs)
- Really, if you are just looking for an easier way to manage applications in a modular manner
So, if any or all of these reasons match your requirements it makes sense to check out running App Layering in Azure. Now, if you want to achieve these benefits and also simplify the number of products you have to manage as an organization, then it also makes sense to check out Citrix Cloud so you can outsource the Citrix Infrastructure required to deliver the Citrix solution to your users.
How to Install App Layering in Azure
Now I’m convinced I want to use App Laying in Azure, how do I set it up. Well the first step is to get the ELM appliance created in Azure. The following steps outline the steps involved.
- On your Jump Server or Cloud Connector
- Ensure > 40 GB Available space
- Logon to Citrix Cloud
- Download/Unzip the Appliance Download
- Unzip Appliance Zip itself (~25-30 Min)
- Open PowerShell ISE “As Admin”
- Install the AzureRm PowerShell CMDLETS
- Install-Module AzureRM –Force
- This takes a while
- In PowerShell Logon to Azure
- This will list your subscription ID and tenant ID
- Copy off Subscription ID and Tenant ID for later use
- Install the AzureRm PowerShell CMDLETS
- As part of the ELM download Citrix includes a PowerShell script to install the ELM appliance.
- Run AzureELMDeploymentV4.ps1
- This takes about ~45 min
- Hash OS Disk 13 min
- Detecting Empty Blocks 20 min
- Upload 5 min
- Create VM 5 min
- This takes about ~45 min
- Note: as of Citrix App Layering 4.13 you can use accelerated networking for your ELM appliance and Premium Storage for Packaging Machines and Layered Images
- Run AzureELMDeploymentV4.ps1
What about Permissions
Before you start the process, you need to figure out how to provide permission to the user installing the ELM, the Azure Connector and Citrix Cloud. Azure assigns permissions to applications based on the concept of a “Service Principal” which is also called an “App Registration”. The Service Principal is like a user account for applications. Permissions for the Service Principal can be assigned at the Azure subscription level or at a Resource Group level. Within Citrix Consulting we would recommend that for a production deployment you create a separate subscription for the Citrix infrastructure. Then you can apply permissions for both the Azure Connector and Citrix Cloud at the subscription level. The advantage of this is that there is no worry about these processes affecting your other Azure virtual machines and Azure imposes SDK rate limits on a subscription. By breaking up your infrastructure into separate subscriptions your layering activities will not conflict with other critical activities on your production subscription.
You can also pre-create a network and storage account within a defined Resource Group and assign permissions to both the App Layering Azure Connector and Citrix Cloud at a Resource Group level. For App Layering you will need just a single Resource Group. For Citrix Cloud you will need several Resource Groups:
- One for infrastructure components like Cloud Connectors, NetScaler Gateways and Storefront servers if you are using any of these based in Azure.
- One for every Machine Catalog and/or 240 desktops deployed into Azure
For permissions there are many articles out there that show the exact requirements but the easy thing to do is to provide the Azure Connector Service Principal and the Citrix Cloud Service Principle Contributor rights on either the subscription or all the Resource Groups you are using for them. In order to create a Service Principal, you will need to be the “Owner” of the Subscription of Resource Group. Also, whoever is installing the ELM will require Contributor and Owner on the Subscription or Resource Group used for App Layering.
Install the ELM Appliance
Now you should be ready to install the ELM appliance. The following video will show you how to download and install the ELM appliance. Note: that the install can fail due to bugs in the way Azure creates virtual machines. If the script fails, logout of Azure, close the PowerShell IDE and start over. Also a note on the videos I have created. Most of them have been cut up to remove time for long running steps and they have been sped up by 150% so that you can get through them quicker.
Well if you have gotten this far and you’re still with me you made some progress. You have the ELM installed and the password set. There are some to-do’s I didn’t go over in the video because it’s the same in Azure as any other platform. Now you will want to do the following:
- Set Up a Directory Junction to your AD
- Add an Elastic Layer Share. This will be discussed more later in the blog.
- Configure the “Settings and Configuration” tab
- Enable any desired labs features
Create an Azure Connector
The next major task is to create an Azure Connector. This requires the following preparation:
- Create a Storage Account for the Azure Connector to use
- Standard and Premium Storage (as of CAL 4.13)
- General Purpose V1
- Create an “App Registration” for the connector
- This is a Service principle for applications
- This allows permissions to be assigned to the connector
- Add a client key to the App Registration – An Authentication key (certificate-based password) for the application
- Assign Permissions to App Registration
- Resource Group>Azure AD>App Registration
- Find the Service Principal and make it a Contributor
Then you are ready to create the connector in the ALMC. Go to System>Connectors and create the connector. It will look like the following:
The following video will show all of these steps.
Create and Import an OS Layer
Now that we have an Azure connector, we can work on creating an OS layer. This is a little easier in Azure because you will start by deploying a virtual machine from the Marketplace that matches the OS you want to deploy in Azure. After deploying, you will want to spend some time to understand optimizing your image. That’s not in scope for this blog but luckily I have covered it before. Jump over to my blog on “Optimizing Windows and Citrix app Layering” to get an understanding of how to approach optimizations when using App Layering.
When you are happy with your image, install the App Layering OS Machine Tools and go ahead and import the Gold Image into App Layering to Create your OS layer. You do this in the ALMC under Layers>OS Layers>Create OS Layer.
Create a Platform layer
There is nothing special about creating a Platform layer in Azure. In fact, it’s fairly simple. Spin up the packaging machine, join the domain and install the VDA software. Reference the Optimizing Windows 10 and Citrix app Layering blog as some optimization steps should be performed in the Platform layer but it’s pretty straightforward. See the video in the next section for how to create the packaging machine when prompted to do so. But that is also easy.
Create App Layers
Now you can create some App Layers. This is also pretty straightforward.
- In the ELM go to Layer > Create a Layer
- Choose the Azure Connector
- The ELM will create the virtual machine disks then prompt for template information for the packaging machine
- It takes about 15 minutes to create a packaging machine
- Logon as local administrator using connect from the Azure portal
- Install an application or applications
- Configure to not auto update, run ngen if necessary, etc
- Reboot and “Shutdown for Finalize”
I did make a video of this process you can review it here:
Create and Publish a Layered Image
When you have your OS Layer, Platform Layer and some Application Layers, you are ready to try creating a Published Image. The first step in the process is to create an Image Template. The Image Template defines which layers make up a Published Image. The Image Template includes the following:
- Template name – defines the name used for image files when they are published
- OS, Platform and App Layers
- Connector (Azure)
- Disk name and Size
- Elastic Layering (Application Layering)
- User Layer
- Office 365
- Office 365 Session
- Full (Still Labs and not available for XenApp)
Once you create the Image Template, use the Action Menu or right-click and “publish” the image. The ELM will combine all the layers by copying in all the files and registry entries from each included layer by priority. Then it will copy the new image VHD from the appliance to the app layering storage group under containers>citrix-al-images. However, publishing the image does not quite make it ready to use in MCS yet. The Azure connector was originally developed for deploying RDSH servers in Azure. Because of this, the image is automatically “sysprepped” and it must be attached to a virtual machine and started in order to let the sysprep process finish before it can be used as a Master Image in Citrix Cloud/MCS. This can be done using an Azure template that the ELM creates but its kind of a pain to do it that way. I decided to instead create a script that will convert the disk image created by the ELM into a Master Image ready for MCS.
Update 11-12-2018 – As of version 4.15 there is a new Azure Connector for MCS. This connector will publish the image without first “syspreping” it. MCS can ingest the image without first mounting it in a VM and starting it up. This will save significant time over the older process defined in the video here. All you have to do now is publish the image which will put the disk file in the “citrix-al-images” folder under your storage account. Then when you deploy the image with MCS you choose the new disk file.
If you are not yet using 4.15 you can still do this the old way using the script.
The script automates the following:
- Prompts to choose the desired disk file
- Creates a VM using disk file name the ELM created
- Starts-up the VM and runs sysprep
- Shuts down and deallocates the VM
- Deletes the VM and Network Interface
This Publish Image video shows how to use the script.
If you would like a copy of the script it is available here:
To use it, download it, unblock it and save it on your jump server where you will be running PowerShell scripts for Azure. Then configure the settings at the top of the script.
At this point you should be ready to create a catalog in Citrix Cloud using your published image. I am skipping a few steps here. I have assumed that you have already signed up for Citrix Cloud, created at least two cloud connectors and an Azure Resource Location in Citrix Cloud by downloading and installing the Cloud Connector Agent. Now I will go over creating a Hosting Connection for the Resource Location in Azure and Creating a machine catalog to deploy your image.
Citrix Cloud Azure Host Connection
Creating a host connection for Azure in Citrix Cloud is easy as long as you know a few things beforehand. As stated before, you need to figure out where you will apply permissions for the Citrix Cloud Host Connection. This is easiest if applied as Contributor at the Azure Subscription level or on all the Azure Resource Groups Citrix Cloud will use. You will need to set up a Service Principal for Citrix Cloud just like you did for the App Layering Azure Connector, then you will use the service principal when setting up the Host Connection in Citrix Cloud. One tricky point here is that the Host Connection will ask for an Active Directory Id. This is the Tenant ID returned by the Login-AzureRM command in Azure PowerShell. The main Host Connection dialog should be filled out as follows:
Create a Machine Catalog using an App Layering Published Image in Citrix Cloud
Once you have your Azure Hosting Connection created and your Master Image Published you can create a Machine Catalog and some XenApp Servers or XenDesktop Desktops in Azure. To do this open studio in Citrix Cloud and click on Machine Catalog then Create Machine Catalog and run through the wizard. When prompted to select the Master Image navigate to the Resource Group, Storage Account and “citrix-al-images” container and choose the MCSReadyImage created by the publishing script. This should look similar to the following:
For a step by step run through see the following video:
After this step you should have VDAs created from your published image and ready to test. You can define access to the VDA using storefront servers deployed in Azure or just within Citrix Workspaces in your Citrix Cloud deployment. If using the later when you create your delivery group choose the option to specify users with Citrix Workspace Cloud. If you are using your own storefront deployed into Azure, then choose to specify users with Citrix Studio. It is also possible to use Workspaces with Site Aggregation bringing in your Azure based storefront servers into your Citrix Workspaces deployment.
The last topic I want to cover in this blog is Elastic Layering. Elastic Layers are layers stored on a network share which are mounted when the user logs on to a Desktop or XenApp server. Elastic Layers provide dynamic access to applications which offers many advantages. Especially allowing administrators to only include core applications that everyone needs in the Master Image, then layering on one off applications using Elastic Layers. If you are using Elastic Layering in Azure you need to determine how to create the Elastic layering file share. The most important requirement for this share is that it must always be available because if the share becomes unavailable, even for very short periods of time, all the connections to the layers will fail and the applications will become unavailable until the VDA is rebooted. The share also has to support NTFS file permissions for security which means that you cannot use Azure Files to deliver the share as they do not support NTFS permissions.
In Azure there are third party solutions that can be used for this or you might consider using Microsoft’s Scale Out File Server for Application Data. This will provide a continuously available file share that is designed to deliver large VHD files. In Azure I think this is normally built on top of Storage Spaces Direct. Microsoft has a similar use case described in the following link for user Profile Disks in RDS:
For more information on Elastic Layering see Understanding Elastic Layering.
That’s it for me today. I know this was pretty long, but I hope it has helped you jump start your experience with Citrix Cloud, Azure and Citrix App Layering.
Citrix TechBytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Want specific TechBytes? Let us know! firstname.lastname@example.org