The Microsoft Cloud Adoption Framework (CAF) for Azure outlines a deployment approach and defined design principles for enterprise-scale landing zones. A landing zone is an Azure environment that accounts for scale, security, governance, networking, and identity for an organization. From a Citrix perspective, the Azure landing zone is the foundation for deployment.

In the first part of this blog series, we reviewed the design principles of an enterprise-scale landing zone. These design principles highlight a methodology to create a modular and scalable architecture. I highly recommend reading the first part in the series prior to enjoying this blog.

In this second part of the series, we will dive deeper into the critical design areas of an enterprise-scale landing zone.

What are the enterprise-scale landing zone critical design areas?

The critical design areas contain the core technical constructs of Azure that should be developed and aligned with business and technical requirements to create the conditions for successful Azure adoption. Having a concrete plan for each of these design areas is a critical path for successful expansion of Citrix on Azure.

The critical design areas are as follows:

Each of these areas could have enough information for their own blog individually. In these next three parts of the series, I will focus on key lessons learned in each critical design areas from previous customer projects, highlighting CAF recommendations and their implications on Citrix design. In Part 2 we will cover the first three critical design areas and follow up with the rest in Part 3 and Part 4.

Enterprise Enrollment and Azure AD Tenants

CAF recommendation: “Avoid creating a new Azure AD tenant unless there’s a strong identity and access management justification and processes are already in place.”

Similar to an Azure subscription, a Citrix Cloud tenant only supports a single Azure AD tenant for Workspace or Admin authentication. If development and production Azure AD tenant isolation is required for your operational processes, similar isolation should be established for your Citrix Cloud tenants.

What are the benefits of an isolated Citrix and Azure environment? This can be used to segment production and non-production costs and the resource consumption against Azure subscription limits and Citrix Cloud tenant limits. Additionally, with cloud technology the pace of innovation is accelerated. Tech previews or new services can be enabled and tested in isolation to help your technical teams better understand their implications and benefits on current production design or use cases prior to broader rollout.

Identity and Access Management

CAF recommendation: “There’s a difference between Azure AD, Azure AD DS, and AD DS running on Windows server. Evaluate your application needs and understand and document the authentication provider that each one will be using. Plan accordingly for all applications.”

A Directory Service such as Azure Active Directory Domain Service (Azure AD DS) or Active Directory Domain Services (AD) is required for critical Citrix Virtual Apps and Desktops functionality, such as Kerberos for VDA registration. The below table summarizes key Citrix functionality based on each Microsoft authentication provider.

Functionality Azure AD Azure AD DS Full AD in Azure
Delegated Admin in Citrix Cloud
Machine Creation Services

Citrix Virtual App and Desktop Standard for Azure only

LDAP/Kerberos X
GPOs X
Authentication to resources
Domain join X
Citrix Federated Authentication Service X X

The majority of enterprise customers today leverage full AD in Azure, typically deployed in an Identity Subscription. In this scenario, Azure AD can still be used as an identity provider directly with Citrix Workspace  to leverage capabilities such as Azure Multi-Factor Authentication and Conditional Access. Citrix Federated Authentication Service can be deployed for single sign-on to Windows workloads. With the release of Citrix Virtual Apps and Desktops Standard for Azure, Azure AD only environments are possible with support for non-domain joined workloads, opening up new desktops-as-a-service use cases. I recommend reviewing this Citrix blog post for more information.

If you are currently in the planning stages of your Azure deployment, review Microsoft’s comparison of each of these services with your identity team, and understand their cloud initiatives and timelines. Identity is a critical path prerequisite for Citrix deployment on Azure.

Management group and subscription organization

CAF recommendation: “Use subscriptions as scale units and scale out resources and subscriptions as required. Your workload can then use the required resources for scaling out, when needed, without hitting subscription limits in the Azure platform.”

CAF recommendation: “Create management groups under your root-level management group to represent the types of workloads (archetype) that you’ll host and ones based on their security, compliance, connectivity, and feature needs. This grouping structure allows you to have a set of Azure policies applied at the management group level for all workloads that require the same security, compliance, connectivity, and feature settings.”

An Azure subscription is a logical limit of scale by which resources can be allocated. These limits include thresholds for numerous resource types and throttling limits based on reads and writes made against Azure (e.g., 1200 writes per hour per subscription). Subscription requests, such as virtual machine power management, drive the recommended VDAs per Microsoft Azure subscription from a Citrix Machine Creation Services perspective. For this reason, we have been recommending for years using dedicated subscriptions for Citrix workloads.

When using subscriptions as a unit of scale, VDA count is the primary metric. The type of VDA used, single-session vs. multi-session, will directly impact the number of users an organization can support per subscription. As we think about enterprise-scale, segmenting workload subscriptions by VDA type is becoming more common, enabling varying use cases to scale independently while still managing them centrally using Citrix Cloud and the Azure Portal. This will prevent growth in one area of the business, for example a new requirement for call center VDIs, from impacting the scalability of other use cases, for example a set of servers virtualizing a key line of business app. When using multiple subscriptions, leverage a naming scheme for your machine catalogs that identifies the subscription (i.e. host connection) that it is associated with. An example would be something like MC-AZUSEast2Sub1-Win10VDI-HR and MC-AZUSEast2Sub2-Win10VDI-HR. These could then be aggregated into DG-AZUSEast-Win10VDI-HR.

You can track the number of VDAs per subscription through the following:

  • Azure Portal → Select desired workload subscription → Settings → Usage  quotas → Filter on Microsoft.Compute and Virtual Machines

  • Citrix Cloud→ Create an advanced search → Utilize “Machine Catalog” filter

Azure Management Groups are not necessary for every Citrix deployment in Azure. However, if a multi-subscription, multi-archetype approach is required, they should be considered as key tool in simplifying application of Azure governance requirements to the overall Citrix deployment. I have summarized a few key design questions that can help indicate if a multi-archetype approach to Citrix on Azure governance is right for you:

  • Use Cases: Are your use cases known? If so, are your target use cases predominately virtualized applications or multi-session desktops? Is VDI considered more niche (<5 percent to 10 percent of total user count)?
  • Operations: Do you have a clear line of demarcation between teams managing Server and Client Operating Systems? Do these teams also have separate cost centers internally?
  • Scale: What percentage of your organization will have workloads on Azure? Will long-term usage exceed 5,000 concurrent users?

One of the great benefits of cloud is flexibility, while a single dedicated subscription may be the right approach today it doesn’t mean you can’t adapt a multi-subscription, multi-archetype approach later. During the design process, ask your Azure governance team, “What would be the process if we require another subscription for our Citrix landing zone?” Establish flexible resource naming schemes and modular network design from the beginning. Remember, planning for growth is planning for success.

Next Up? More Critical Design Areas!

In this blog we explored the impact of Azure identity and subscription governance on Citrix architecture. In the next part of the Citrix on Azure – Enterprise-Scale Landing Zone series, we will look at business continuity and disaster recovery; security, governance, and compliance; and platform automation and DevOps and the associated Azure tools that help enhance your Citrix deployment.