As you approach Linux VDA deployments, you may tend to consider them like a slightly different kind of Windows VDA. In reality, they are quite different. They do the same job, but internally, there are some notable differences.

In the next few paragraphs, I will highlight some of the design differences and how they may impact your Linux deployment.

What type of scenarios do we support? One common misconception is that Linux VDA support follows the same rules that apply to Windows VDA. For example, the Windows VDA version should match the CVAD Site one. For example, if your Site is based on CVAD 2203, your Windows VDAs should match this version. Eventually, if the required OS is not supported by the CVAD version, you can install a compatible older but still supported version of Windows VDA. We support this combination until the OS is supported by Microsoft.

With Linux VDA, we are a bit more flexible. We do support using older versions of Linux VDA as per the Windows case; however, for Linux, we also support using newer versions of Linux VDA. In the last case, there is a small caveat; if a Linux VDA feature requires the same CVAD version to be enabled, then you need to upgrade your CVAD Site to that version.

For example, we support deploying Linux VDA 2402 machines on a 2203 CVAD Site, but if a 2402 feature requires a 2402 CVAD Site, then you need to upgrade your installation to use it.

If you are maintaining an LTSR installation, please be aware that using VDA versions different from the baseline version may affect LTSR compliance. Learn more about LTSR compliance.

On the other hand, we do support “OSes” in a slightly different way. In the Linux world, we are talking about Linux distributions and their versions.

A Linux distribution is a complete operating system that includes the Linux kernel, system libraries, utilities, application software, and a package management system. It is created by assembling various software components from different sources and packaging them together to provide a cohesive and user-friendly computing environment.

Of course, we do support all versions supported by their software maintainers, but we also provide limited support for End Of Life versions too. The limited support comes with a small caveat; the installed Linux VDA version must be a supported LTSR one, and we will support the distribution version until bugs/issues can be fixed without changes on distribution code.

Formally, this is expressed in this note:

When the support from your OS vendor expires, Citrix might be limited in its ability to remediate problems. For deprecated or removed platforms, see Deprecation.

Read more about End of Life support.

Just to give you an example, CentOS 7 reached its end of life (EOL) on June 30, 2024. After that date, you may keep using the Linux machines in your Citrix environment with the 2203 Linux VDA until 2027, when the Linux VDA will reach its EOL. This can end earlier than 2027 if we develop a fix/patch that requires a software update in the Linux distribution. When this happens, we will not be able to fix the issue, and we will declare CentOS 7 unsupported.

Please be very cautious and consider all security aspects of using an unsupported distribution version in a production environment. We are not suggesting nor recommending that unsupported software should be used.

What about Linux VDA’s scalability in Citrix DaaS? The current Citrix DaaS limits are published here.

If you look at the maximum number of VDAs you can configure in a single Resource Location, you get a generic hard limit of 10000 VDAs. Also, we recommend more restrictive provisioning limits for a single public provider subscription.

Are those limits valid for both Windows and Linux VDA deployments? The short answer is no, or at least not yet. Actually, the published numbers are based on scalability tests focused on Windows VDA. So, what about Linux VDA?

Let me try to explain what is hiding behind the scenes.

The Citrix VDA communication with Cloud Connector is currently based on WCF (Windows Communication Foundation). Linux VDAs use WCF connections differently than Windows VDAs. Sometimes this causes the Cloud Connectors to run out of resources when too many Linux VDAs are active in the Resource Location.

A Cloud Connector normally operates in online mode, but there may be situations where it cannot reach the DaaS services. In these cases, it goes into outage mode or LHC mode. Normally, in online mode, all the Cloud Connectors are used to handle VDAs registration, whereas during an outage, only the elected secondary broker will manage the VDAs re-registrations. The non-elected secondary brokers in the zone actively reject incoming connections and VDA registration requests.

Find more details about Local Host Cache and Local Host Cache HA.

Now you know that the 10000 VDAs per Resource Location limit represents the number of Windows VDAs that can register against a single Cloud Connector during an outage.

Recent Linux VDA versions (1912 CU9, 2402, 2203 CU5, and current CRs) undergo some code optimization, and nowadays each Cloud Connector in online mode supports up to 3000 Linux VDAs, while in outage mode (LHC) it supports 4000 of them. If you are using those versions, we suggest a conservative limit of 3000 Linux VDAs per Resource Location. 

On new Linux VDA versions (2402 CU1 and 2407) we increased the online limit to 6000. Which means we are now supporting up to 6000 Linux VDAs per Resource Location.

If you need to push that number higher, please contact your Citrix Services Partner, or indeed your Citrix representative to engage with our Professional Services and PM teams for a dedicated evaluation of your case.

Yes, you read correctly. This is an interesting fact; the Cloud Connectors do have higher capacity in outage mode than they do in Online mode.

The takeaway here is that if you need to maximize the number of Linux VDAs in a Resource Location, you need to use the latest versions. We are always working on improving these limits, so if you plan to deploy 1000s of Linux VDAs, have a chat with us for some updated recommendations.

What else could impact user sessions? Now, I am thinking of Active Directory joined Linux VDA machines. Except for the standard misconfigurations and common issues, there is one thing that surely impacts the user logon experience: the LDAP latency.

Let’s talk about what’s going on here.

During user logon, there are at least two phases where the LDAP queries run. The first one is at the beginning with the credential validation, but immediately after, there is the policies evaluation phase. The Linux VDA downloads all the Citrix policies locally, and then it processes all of them sequentially one by one. For the way that the Linux VDA operates, the LDAP queries weren’t very efficient.

There were some redundant checks that could be simplified. Optimized code is available for the 2407 version (Current Release) and for the 2203 CU5 and 2402 CU1 LTSR versions. That’s why latency can have huge impacts on the logon time. Sometimes, if the latency is too high and the policy evaluation takes more than 30 seconds, the session will be aborted and terminated. This is known as the infamous grey screen.

Another aspect you need to consider is Linux machines are not able to use the Active Directory’ Sites configuration to determine the closest Domain Controllers. By default, a Linux machine uses DNS to get their list and uses these randomly. Linux VDA instead ranks them using LDAP latency and saves the list of the 3 quicker servers into the ListOfLDAPServersForPolicy “registry” value. Latency information can be found in the jproxy log (/var/log/xdl/jproxy.log). There are environments where you need to use specific Domain Controllers; in this case, you can force them by configuring the ListOfLDAPServers “registry” value.

/opt/Citrix/VDA/bin/ctxreg create -k “HKLM\Software\Citrix\VirtualDesktopAgent” -t “REG_SZ” -v “ListOfLDAPServers” -d “ldap1.test.local:389 ldap2.test.local:389” –force

Important note: If all or some of the configured Domain Controllers are not reachable, the Linux VDA may not work properly. The workaround used to be to run the ctxreg command to remove unavailable LDAP servers from the list. From version 2402 onward, the ListOfLDAPServersForPolicy key is now replaced by the ListOfActiveLDAPServers key. Besides the name changes, it is amended to better align with the function.

The ListOfActiveLDAPServers is periodically updated every 15 minutes by the Linux VDA. In case all LDAP servers configured in the ListOfLDAPServers are not functional, the Linux VDA will automatically switch to the ones in the ListOfActiveLDAPServers list. This change will also be backported in the next LTSR versions’ CU (2203 CU5).

Connected to LDAP latency, another thing to cautiously consider is the ctxpolicyd service CPU utilization. As you can assume by its name, the service manages the Citrix policies applied to the Linux VDA. Firstly, it downloads all Citrix policies into GPF files and then parses all the information to apply the configured settings. This is a CPU-consuming operation.

As you can imagine, a situation could easily become critical if, during logon storms, you add the CPU load generated by ctxpolicyd on top of LDAP latency. If the hypervisor has limited CPU capacity, you may get a perfect storm resulting in Linux VDA registration flapping and grey screens at user logon.

On this precise topic, in addition to the LDAP optimizations available with version 2407, we are actively developing a better way to parse the policies that will further reduce parsing time. It will also be available in the next CUs of Linux VDA LTSR versions.

The takeaway here is to check LDAP latency and to not overprovision your hypervisor. Reserve some resources to support critical situations like an outage. On the bright side, we are developing some key improvements to ease all these situations, but never underestimate the impact of external conditions.

Linux Kerberos versus Active Directory: the encryption saga

If you are trying to integrate Linux machines with a complex Active Directory infrastructure, you may encounter some trouble, or at the very least, you will need to resolve the complexity somewhat. Encryption is certainly key here.

Linux distributions normally tend to be quicker at implementing new security protocols. Microsoft is doing the same, but it needs to maintain compatibility with old components (legacy OSes, for example). So, sometimes old things get dragged along for a while before they can be sorted.

Encryption types are very important when there are trusted Domains in your Active Directory infrastructure. For example, you may have a service Domain hosting all machines and a user Domain for user accounts.

On the Linux side, Samba Winbind and SSSD support RC4, AES-128, and AES-256 Kerberos encryption types. RC4 encryption has been deprecated and disabled by default as it is considered less secure than the other two encryption types. In contrast, Active Directory trusts between Domains support RC4 encryption by default. AES encryption types must be explicitly enabled. Enabling it requires a lot of checks to ensure service continuity. It is not as straightforward as decommissioning older versions of OSes.

So, what should you do in this case?

The best option is to enable AES encryption at the Active Directory level and ensure all trusts between Domains in your Active Directory forest support strong AES encryption types. If this is not doable, your only solution is to enable RC4 encryption. Additionally, you may need to add the following line to the krb5.conf file:

allow_weak_crypto = true

The process to enable RC4 is slightly different in each distribution. Please refer to your distribution’s documentation.

Machine Catalogs versus Automation

Using Citrix MCS to deploy Machine Catalogs gives you the certainty that all machines are homogeneous and respect all Citrix recommendations. There are use cases where automation is the chosen way to deploy machines. For example, one use case could be the deployment of assigned static machines. As a side note, we do recommend Citrix MCS as the best way to deploy pooled machines.

We do encourage customers to use automation, but there are some simple basic rules to respect. The primary rule is that a Machine Catalog must contain homogeneous machines using the same VDA version.

How does this translate in the Linux world? Using the same Linux VDA version is fundamental, but what about the distribution? Well, as always, the best option is using the same distribution for all machines, but in certain cases, like for static Machine Catalogs, we can be a bit more “elastic”. You can mix various distribution versions and even various distributions. The important thing is maintaining a certain grade of homogeneity. The issue is not if the Linux VDA will work or not, but whether all the complexities you introduce can be managed in a hybrid configuration.

The takeaway here is that Machine Catalogs are containers, but they should contain homogeneous machines only.

Linux VDA does not have profile management

This objection is questionable. For sure there are no profile solutions like Citrix Profile Management or Microsoft FSLogix available for Linux machines, but this does not mean that all user profiles are local.

In the Linux world, the concept of user profiles is translated into the home folder. As in any other OS, on a Linux machine, the user home folder (profile) is stored locally. To make it independent from the single machine, you can store them in an NFS network share. In this case, the home folder is mounted from an NFS share.

Scalability and reliability of this solution are directly connected to the scalability and reliability of the NFS share. We encourage you to verify this with your storage vendor and perform some in-house testing before using it in a production environment.

Final Notes

As you read through this article, there are some notable differences between Linux and Windows VDAs. We are working closely with customers to improve the Citrix Linux VDA. We are learning a lot from your experience and your feedback. Sometimes we need to improve our code, sometimes we need to provide a good workaround to resolve external conditions.

The Linux VDA roadmap is quite exciting. We are improving it at a pace never seen before. We really have exciting times ahead.

My intent with this article was to share my experience and some information about Linux VDA that is not commonly known. I hope you enjoyed the read and learned something useful. Now it is time for me to get back to my next project. Our brand new macOS VDA is in Tech Preview and we already have some customers actively using it. Check this blog soon for updates.

Disclaimer: This publication may include references to the planned testing, release and/or availability of Cloud Software Group, Inc. products and services. The information provided in this publication is for informational purposes only, its contents are subject to change without notice, and it should not be relied on in making a purchasing decision. The information is not a commitment, promise or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for products remains at the sole discretion of Cloud Software Group, Inc.