A long time ago I wrote a blog post around Microsoft RDS vs Citrix XenDesktop at the time where I looked at the overall functionality and end-user experience, which you can read about here https://msandbu.org/so-why-choose-citrix-over-microsoft-rds-2/ (and now fast forward to 2022 not much of that is that much relevant anymore.)
A Couple of weeks ago I saw this post from Citrix, and it made me a bit agitated (which you can read about here –> Citrix and Microsoft Azure: Create Your Ideal Virtual Desktop Experience – Citrix. For one I do not feel that it is representing all the facts, so therefore I wanted to use this blog post to go into more detail on what is the difference between the two options. Now I have been working with Citrix and Azure for over 10 years, so I know my way around both platforms.
As part of the work, I do as a Cloud advisor, I always want to provide the customers I work with the best solution depending on their use cases. Sometimes they need Citrix, sometimes AVD is good enough, and sometimes maybe something else entirely.
I have had this discussion soooooo many times with customers and other partners in the last years that I have lost count. So, I wanted to use the blog post to break it down into some different sections much as Citrix did in their post, and give my personal reflection on this, how does Citrix CVAD now compare to Microsoft AVD?
Now to be fair, I have not included all the Citrix stuff related to ZTNA and Secure Access, the focus here is to look closer at the functionality of providing virtual Windows Applications and Desktops and the difference between these two vendors on Microsoft Azure.
NOTE: If you do not want to read all the extra stuff want for the second part.
This section is meant just to provide some context around the overall architecture of both platforms and their services.
Much of the services that Citrix have been building over the last years have been around their managed cloud service called Citrix Cloud. This service provides much of the functionality needed to manage, provision, and provide connectivity to the infrastructure using a local component called Cloud Connector. The Cloud service itself is built on top of a combination of AWS and Microsoft Azure to run
Their management plane is delivered in 5 different regions (US, US-GOV, EU, JAPAN, Asia Pacific South) so when you create a management plane tenant you need to select one of these regions. This means that all APIs/changes/updates need to go to that region. Much of the Citrix Cloud services are running on Microsoft Azure, as can be seen as part of the FQDN documentation here –> System and Connectivity Requirements | Citrix Cloud
Regarding the data plane (handling user session connections to the actual VDI/VDA), this can either be done using on-premises Gateway appliances or their managed data plane service called Gateway-as-a-service.
This connection point supports a UDP-based connection using a protocol called EDT which is based upon DTLS (This requires the use of the Rendezvous protocol, more about that part a bit later)
This means that traffic coming from an end-user is going to one of the POPs (Point of presence) that Citrix has –> Citrix Gateway Service – Points-of-Presence (PoPs) then being redirected to the VDA. The service is behind a DNS load balancing capability which redirects the user to the closest PoP location.
The connection to the infrastructure is done via a virtual machine that hosts the cloud connector service, (Citrix Gateway Connector) which acts as the connectivity proxy for VDAs and Citrix Cloud. Also depending on which feature of the protocol is used –> Rendezvous protocol | Citrix DaaS the Cloud Connector also acts as a proxy if the Rendezvous protocol is not used for connectivity.
The Citrix Cloud connector should be configured for high availability to ensure connectivity to infrastructure if needed for Active directory and VDA registration. For Rendezvous v2, the Cloud Connector is unnecessary if using Azure AD Joined machines.
The users connect to the Citrix Cloud Workspace service which acts as a user interface and connection point when users want to start an application or desktop. The workspace can be configured to be integrated with different identity providers, either Azure AD, SAML, Active Directory, or on-premises Gateway.
In terms of integration with Microsoft Azure for provisioning virtual infrastructure, Citrix has built MCS integration (and now PVS). This means that we can provision virtual infrastructure based upon a base image in Microsoft Azure, but I’ll come back to image management.
Microsoft’s AVD service is a bit simpler since it only consists of the AVD core components (That can be both a good and bad thing) more about that later. AVD consists of the PaaS services running in Azure. These are:
- Connection Broker
- Web Interface
All these services are mostly globally available, and load-balanced using Azure Front door to provide redundancy and route users to the closest region. The service is configured from a customer tenant and managed within Microsoft Azure as a native Resource Manager Service.
From an administrator perspective, you have the AVD Workspace where you configure Host Pools and Application Groups which are the only part that you can configure and manage for the AVD service. Logs and metrics are collected from the AVD Workspace and host pool into Azure Log Analytics which provides data into the monitoring capabilities in Azure.
When users authenticate to the service you firstly have the Connection Broker which handles the session and authentication which uses Azure Active Directory-based authentication.
Then the RDagent on the backend machine will receive the session that was initiated the session which will then handle the authentication and data traffic.
With AVD we have the RDAgent installed on each machine that we want to deliver apps and desktops which is then associated with an AVD host pool that is unique for each tenant. That way the AVD service knows which AVD host pool to send traffic to once a user initiates a session.
Depending on what kind of protocol is used the RDAgent will either establish a session using a Reverse-TCP connection or use a Short Path Connection that uses UDP, which you can read about here –> Azure Virtual Desktop and ShortPath for Public Networks | Marius Sandbu (msandbu.org)
While the Citrix architecture shown here is a cloud-based service, Citrix also supports integration with on-premises infrastructure with different provisioning mechanisms available for different hypervisors. In addition, Citrix supports having the data plane going directly to the on-premises environment given you have on-premises NetScaler/Gateway appliances. However, the presence of Gateway PoPs Citrix has in their managed cloud service is severely lacking for many regions, such as here in the Nordics. As an example, if I were to host my Citrix VDAs in Microsoft Azure Norway (close to where my users are) and were to use the Citrix Gateway service my latency would be around 30 – 40 MS, if I were to use a Gateway appliance (formerly known as NetScaler or ADC) in Azure, it would reduce to 5 – 8 MS since then the connection would go directly to the Gateway instead. So, I have at least the flexibility to do my own hosting of the gateway service.
In addition, Citrix relies on Cloud Connectors to handle provisioning which adds more virtual infrastructure to the environment. However, they are moving more to native mechanisms in the VDA agent with the Rendezvous v2 protocol. Citrix also states that they will try to provide 99,9% availability on their service Service Level Agreement | Citrix Cloud
Microsoft has a more lightweight approach, given that you only configure the PaaS services in Azure and install the agents. This means that getting it up and running can be done quickly and given that Microsoft has their gateway service much wider availability means that users can quickly benefit from lower latency connections.
While Microsoft’s own solution is easy to configure and set up it provides little functionality in terms of configuration, and image management capabilities. Microsoft also does not provide any financially backed SLA for their service SLA for Azure Virtual Desktop | Microsoft Azure
Management of Citrix is done via Citrix Cloud, either using the Web UI or using REST API (or PowerShell Module). The UI provides mechanisms to provision machines using MCS (Machine Creation Services) and assigning access to users and groups, this can be integrated with any cloud or on-premises hypervisor.
While MCS is integrated into the Cloud-based management, other provisioning mechanisms with PVS are managed through traditional VM-based management consoles (and are also supported on most clouds)
Citrix also has monitoring integration with Citrix Director that provides an overview of connection services and sessions which will come back in the monitoring section.
In terms of management of the Cloud Connector, you also have an automatic maintenance window for updating your Cloud Connectors, this ensures the cloud connectors are automatically updated when new versions are available.
Management can be configured granularly so that administrators can have customized access to the management plane and monitoring plane.
Managed access can be given either using built-in identities from Citrix identity or external sources such as Azure Active Directory.
AVD Management is done using the Azure Management Plane (Azure Resource Manager). Administrators can either use the Azure Portal, Azure CLI, or IaC (ARM, BICEP, Terraform, or other options available)
In terms of Monitoring, data and events are being collected into Azure Log Analytics which are then visualized using Azure Monitor Workbooks.
Management in Azure is done granularly so access can be given to different resources and using just-in-time access with services like Azure Privileged Identity Management.
AVD also has the same flexibility in terms of agent updates, which allows us to define maintenance windows to when host pools should be updated.
Image Provisioning is not available directly in the AVD service therefore you need to have other mechanisms to handle image provisioning/management such as Azure Image Builder.
Citrix supports as earlier mentioned UI based Portal or APIs using REST (or PowerShell modules) to interact with their Cloud Service (as also seen as an example here –> Getting started with PowerShell automation for Citrix Cloud | Citrix Blogs) they also have some support for Citrix NetScaler/ADC with Terraform (as seen here –> Deploying Citrix NetScaler Configuration using Terraform | Marius Sandbu (msandbu.org). However, they lack proper support for IaC tools for their managed cloud services.
If organizations have adopted a DevOps-based approach to building Azure-based environments, they will need to use other means to build or Configure Citrix-based services, either running a PowerShell module in a CI/CD pipeline or doing it manually.
Citrix also has a feature called AutoScale that does power management for single and multi-session desktops. This allows Citrix to power down resources when they are no longer in use and thus allows you to save costs for cloud-based infrastructure. AutoScale can also power on resources when needed, such as if a machine has been put into drain mode (because it is no longer needed) AutoScale can start using the machine again automatically if it is needed or power on an existing machine.
This feature is disabled by default for all delivery groups.
It should be noted that Citrix has a good integrated feature set related to image management for Microsoft Azure using MCS. For instance, features like:
- On-demand provisioning, means that machines can be created on demand based upon on image instead of having machines just shut-off which reduces the cost related to storage
- Support for Azure ephemeral disks which allows ut use local NVMe based storage. This is only possible because of the image management engine.
Azure Virtual Desktop is a native Azure Resource Manager service, which allows us to use different CLI/SDK/API/IaC tools to provision and manage the Azure resources associated with the service. This also applies to an image management service Azure Image Builder which is also an Azure service that can also be managed via the same tools.
Given that image, management needs to be handled separately the best approach would be to manage the image building process using CI/CD pipeline mechanics which allows us to automate the process.
Microsoft has a feature called scaling plans which allows AVD to power on a machine based upon a predefined schedule, in addition, they also have another feature called Start on VM connect which allows AVD to power on a user based VDI when the users start their AVD client.
If you as an organization have already adopted DevOps / IaC against Microsoft Azure, you will be able to manage most of the AVD setup, image management and operations using the same set of ecosystems. There are also already many good examples on how you can use Terraform to configure and manage much of the AVD environments.
With the simplistic nature of AVD being just an agent it is easy to onboard when needed using IaC. This means that you can manage the entire platform using the same set of automation tools.
This is unfortunately not the same for Citrix, where you will need to use PowerShell or REST APIs to manage the same. There are of course some modules available for NetScaler, but not for the core Citrix management capabilities.
Citrix has Director that provides an overview of the status of the environment, which allows us to see the state of machines and currently connected users to a session. We can also view details on connect sessions and see trends among other stats.
We can also see in real-time ongoing sessions and go detailed into the individual session and dig into metrics of the actual session to see the overall latency and user experience.
Citrix also has application and desktop probes that can verify that resources are available externally.
Alert policies can be configured to trigger alerts and it supports Email notifications. Citrix also has administrative logging which will log all administrative activities but however does not support external pushing of data.
Citrix also has integration with Microsoft Sentinel, which allows for pushing of log data to Sentinel using a Logstash integration (which is currently in preview) Microsoft Sentinel integration | Citrix Analytics for Security but that requires that you have license for Citrix Analytics as well.
Much of the monitoring capabilities in Azure Virtual Desktop are based upon Log Analytics and workbooks. Where all diagnostics data is collected. Log Analytics has a certain delay when ingesting new data and before it is available for visualization, therefore it doesn’t display everything in realtime and it doesn’t show RCA for when core services are not responding that is something that you need to build on your own monitoring or rely on the Azure Service Status portal.
Secondly it feels like more of a reactive approach to monitoring, seeing that it does not provide an overview of the AVD core services as well to see if there are issues.
On the upside it means that all changes and activities related to Azure virtual Desktop is uploaded directly to Azure Sentinel if that is used.
To be honest, Microsoft had built monitoring capabilities of AVD based upon logs that are collected into Log Analytics from the AVD components and logs running on the virtual machines, which of course is not real-time based logging and might therefore not give the full spectrum.
However, if you have started to invest into the ecosystem of Azure including Azure Sentinel, it can provide a wide range of detection mechanisms against AVD hosts and the management plane.
Still, I would have loved for AVD to have some more proactive monitoring capabilities for their services, relying on just the status page and log collection is still not good enough.
In terms of monitoring (and with that I mean real-time) Citrix has a much broader range of realtime statistics including deep insight into the different streaming channels to give insight into (what is hogging up the resources or bandwidth?)
Summary so far
So far, we have just started with an overview of the architecture, management capabilities, automation, and monitoring. It shouldn’t be a surprise that Citrix has better management, monitoring, and image management capabilities given their history. However, I feel that with more organizations adopting the public cloud and adopting the new ways of working with automation and DevOps that many more organizations move to AVD instead.
Why? = Easier to Manage, lower cost? good enough performance?
Customers that want to move to the public cloud but do not have the in-house experience might rely on Citrix or some third-party management options such as Nerdio.
But there should be no denying that many will be in a hybrid setting for a long time, and Microsoft is still sticking to that AVD is only available for Azure Stack HCI for on-premises deployments (and therefore missing all those customers using HCI platforms like VMware and Nutanix) where Citrix has also existing integrations. This allows large organizations to use one platform to manage across all platforms.
In the second blog post, I will go further into Performance, High-Availability, User-Experience, Cost, and lastly my personal conclusion on it.