Cloud Guidepost: Citrix Virtual Apps and Desktops Service on Azure (Part 2) – Considerations for the Resource Layer
Salesforce CEO and Chairman Marc Benioff once said “The cloud is for everyone. The cloud is a democracy.” While I am a strong believer that this quote is completely true, it is also true that sometimes it is difficult for us IT enthusiasts to expand our traditional on-premises way of thinking to embrace and learn cloud technologies.
As a way to aid you on your adoption journey to better understand the Citrix Apps and Desktops Service in combination with Microsoft Azure, in part 2 of this blog series, we will talk about some of the specific Azure components you will need to consider and plan for when implementing your own environment.
Before you keep going, I’d like to encourage you to read this post and this post, written by one of our Enterprise Architects, Kevin Nardone. They contain excellent tips and tricks to consider when deploying Citrix workloads in Microsoft Azure. Did you have a chance to read those already? If your answer is yes, then without further ado, let’s get right into our topic.
Planning the Azure Environment
1 — Azure Subscriptions
A subscription is an agreement with Microsoft to use one or more Microsoft cloud platforms or services, for which charges accrue based on either a per-user license fee or on cloud-based resource consumption. Azure subscriptions have limits that can become difficult to control, especially when deploying really big environments combining different workloads. This can result in a problem when deploying your Citrix workloads as you can end up having to contact Microsoft to increase your vCPU, VMs, or Storage limits. Whenever possible, you should consider utilizing a subscription that is dedicated to your Citrix workloads.
For more information on Azure subscription limits, make sure to check out this link.
2 — Azure Networks
Networks are a fundamental Azure component, as such, make sure to plan your network segregation properly to avoid issues like overlapping with on-premises networks, incorrect DNS configurations, incorrect security groups, etc.
In my experience helping customers deploying their environments in Azure, I’ve noticed a certain trend towards utilizing a single VNET segregated into several subnets with different DNS servers for each subnet. While this might look like an easy solution to your problems, this will cause issues when deploying your Citrix VDAs since, by design, MCS will use the DNS configuration defined at the VNET level. Thus, you will be required to modify DNS settings at the vNIC level for each of your VDAs. This becomes unmanageable when talking about machine catalogs with hundreds of machines, therefore, this approach is viable only for non-prod/very small deployments but should never be considered a leading practice.
If you want to separate your Citrix workloads into a different network space and manage their networking options separately, you might want to consider creating a dedicated Azure VNET and use Azure VNET Peering to connect it to your “Production” VNET. The official Microsoft definition for VNET peering is as follows: Virtual network peering enables you to seamlessly connect two Azure virtual networks. Once peered, the virtual networks appear as one, for connectivity purposes. The traffic between virtual machines in the peered virtual networks is routed through the Microsoft backbone infrastructure, much like traffic is routed between virtual machines in the same virtual network, through private IP addresses only. Check out this link if you want to learn more about Azure VNET peering.
Another very important caveat to consider is that VNets are Layer-3 overlays, and therefore do not support any Layer-2 semantics.
3 — Azure Resource Groups
A resource group is simply an identifier that Azure Resource Manager applies to resources to group them together. As a rule of thumb, you want to add resources that share a similar lifecycle into the same resource group. With this, you might want to consider creating a resource group holding your infrastructure components, another one for your networks, your Citrix infrastructure components, your VDAs, etc.
By design, and due to Azure limits, the Apps and Desktop service will place a maximum of 240 VMs on a single resource group, meaning that machine catalogs with more than 240 machines will be spread amongst several resource groups. Additionally, if you’re using Narrow Scope Service Principals (coming up next) and therefore need to pre-create your resource groups for Citrix VDAs, these need to be completely empty before they can be utilized as part of the Machine Catalog creation process.
If you want to expand on resource groups, Kevin Nardone did a fantastic job expanding into this topic in his blog post.
4 — Creating Host Connections from the Apps and Desktops Service to Azure
Machine Creation Services (MCS) is a critical component of the Apps and Desktops Service, allowing you to leverage a single master image to create hundreds (or thousands) of VMs. In order to utilize MCS and provision machines in Azure, Citrix Cloud must be granted access to your Azure subscription via an application service account (Azure Active Directory “App registration”) that has been assigned permissions to the relevant Azure resources within your Azure Tenant account. In order to configure this “App Registration,” you have 2 options:
- Let Citrix Cloud do it for you: Citrix Cloud / Studio supports the creation of the application service account. If the Citrix Studio user has an Azure Active Directory account with sufficient permissions, Studio will prompt for credentials to generate the service account in the Azure Tenant Azure Active Directory. The result will be an adoption of the “Citrix managed” model, where the service account is granted with “Contributor” permissions at the Azure subscription level, automatically granting the service principal with these permissions over all resources in Azure.
- Manually create it in Azure: In some cases, our customers might feel a little uncomfortable about providing Citrix Cloud with permissions at the subscription level so a “Narrow Scope Service Principal” may need to be utilized. When choosing this approach, you will need to manually create an application registration in the Azure portal, assign the necessary permissions to the specific Azure resource groups, networks, and storage accounts, and then manually create your host connection in Citrix Cloud. For a complete walkthrough on how to create a Narrow Scope Service Principal, check out this Citrix Support article.
5 — Azure Storage Accounts vs. Managed Disks
Azure managed disks eliminate all the complexities behind storage accounts, preventing you from worrying about IOPS limits, slow image copying, additional permission assignment, etc. Whenever you have an option, and if available in the Azure region where you are deploying your Citrix workloads, manage disks should be considered as your choice for deployment.
But instead of me getting deeper into this topic, make sure to check out this amazing blog post by one of our Senior Software Engineers, Karl Gibson.
6 — AD Domain Services
Active Directory is an essential component for Citrix environments to function, providing authentication to users to your environment, machine domain-join, and group policy application, amongst many (really, many) more things. As such, you want to make sure that you have at least a couple of domain controllers in your Azure environment so that Cloud Connectors, VDAs, Master Images and any other member server can be joined to an AD domain.
Additionally, if you are looking to extend your on-premises AD to Azure, a VPN or ExpressRoute needs to be implemented to connect your on-premises with your Azure environment. This way you can spin up domain controllers in Azure and join them to your on-premises AD environment.
Finally, if you’re wondering about Azure AD, unfortunately, it is not an option for Citrix environments at this point, due to very specific differences it has with a traditional AD environment. Nevertheless, you have the option to utilize Azure AD Domain Services, Azure’s domain controllers as a service option. For more information on how to utilize this, make sure to check Citrix Principal Architect Leo Singleton’s post here.
Final Takeaways
To finish our list of Citrix on Azure recommendations, keep in mind the following points:
- When creating a Machine Catalog, make sure the master image is on a Stopped/Deallocated state in Azure.
- The vast majority of issues we find when creating Azure machine catalogs in Studio are related to subscription limits, or incorrect permission assignment when utilizing Narrow Scope Service Principals, be on the lookout for these two.
- Azure VMs are provisioned through what is called “On-Demand” provisioning so you might notice that even after creating your machine catalog, the VMs do not exist in Azure. Do not panic, this is normal! Read this post in order to furtherly understand how this works.
- Azure physical to virtual vCPU ratio is 1:1, meaning there is no oversubscription utilized in the underlying hypervisors (except A0 instances); and VMs are NUMA aligned, which is especially important when sizing your multi-user server workloads.
- You cannot utilize Azure File Shares to store user profiles or redirected folders at the moment, consider utilizing Microsoft Storage Spaces Direct for high availability of your UPM profiles instead.
Marc Benioff also said, “The cloud services companies of all sizes.” So no matter where, how, or when- if you have the opportunity, I recommend you to embrace the cloud and embrace the Citrix Apps and Desktops Service! And if you need help in doing so, our Citrix Cloud Success team is here to help you! Stay tuned for my final blog in this Azure series that contains tips and tricks for deploying the environment.
JP Alfaro
Cloud Success Engineer
