In Citrix Consulting Services, most of our engagements involve Microsoft technologies. But Linux virtual desktops have proved to be an interesting use case for many of our customers.

It’s an ideal solution for developers, high-graphics users, and others. One interesting scenario I worked on recently involved a non-domain joined (NDJ) Linux VDA, which provides IT departments with the ability to deliver a Linux Desktop in a segregated, secure environment where Active Directory integration is not possible.

Before getting into the details of configuration, I wanted to note that NDJ deployments can be used to resolve complex customer needs. In this case, making NDJ work was just the first piece of the puzzle. Later, we decided to prevent SSO logons in the Linux machines and use a different authentication based on OpenLDAP. It was very exciting for our customer (and me!) to see it working after days of intense testing and adjustments. (But that’s another story.)

This blog post serves as a quick deployment guide (following the steps should take about 30 minutes) that will help you deliver an amazing user experience to your Linux users. There’s no need to join the Linux VDA to an Active Directory domain or for complex configurations. Just install the Linux VDA and go.

Authentication will be managed on the Citrix Workspace portal using your preferred method: Azure Active Directory, Okta, Google Identity, SAML, NetScaler Gateway, Adaptive Authentication, and of course Active Directory.

And if you want to use Rendezvous v2 Protocol, you can go connectorless, too!

The user experience will be one of a kind. The process will start with an ordinary logon in the Citrix Workspace portal. Double click the Linux desktop icon, and in a few seconds, you will be connected to your Linux machine. It’s just pure Linux NDJ “magic.”

Before we go any further, I wanted to give a huge thank you to Javier and Emmet from the Citrix Technologist team in Dublin. They spent a lot of time helping me with requirements, tests, troubleshooting, and getting the results we were looking for.

Requirements and Current Limitations

There are some important requirements and limitations you should know about before starting. Non-domain joined deployment is supported only in Citrix DaaS, and you must use NetScaler Gateway service. Finally, you must deploy the Linux Desktop using Citrix Machine Creation Services (MCS).

*As of September 2023, the latest version of Citrix StoreFront now supports NetScaler Gateway service! Users can use Citrix Workspace or Citrix StoreFront, through NetScaler Gateway service, to access published resources.

On the limitations side, other products and features not supported are Citrix Remote PC Access and lock/unlock sessions.

Check out our product documentation on Linux VDA requirements such as the supported Linux distribution, supported Xorg’s versions, and supported hypervisors. Later in this post, I’ll cover network communications and proxy requirements.

Get Started with Linux VDA

The guidance that follows is based on Debian 11 distribution and is applicable to Ubuntu installations, with a few exceptions. Configurations and other details are applicable to all supported Linux distributions. You can find distribution-specific instructions in our Linux VDA product documentation. Keep in mind the Citrix MCS requirements because you have to configure the base image with a single disk

Additionally, you must have at least one desktop installed. Linux VDA supports GNOME, GNOME Classic, MATE, and KDE.

Double check the installed Xorg version, because using the correct one will save you a lot of time and prevent a lot of issues. To check the installed version, run the following command:

sudo dpkg -l |grep xserver-xorg-core

Another core requirement is Microsoft .NET Runtime 6.0. (Get guidance and instructions from Microsoft.)

For Debian, use the following commands to prepare the environment:

sudo wget https://packages.microsoft.com/config/debian/11/packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
sudo apt-get update

Then install the .NET components:

sudo apt-get install dotnet-runtime-6.0

You can check the installation path and versions using the following commands:

which dotnet
dotnet –-list-runtimes

Now you need to download the desired Citrix Linux VDA version from the Citrix Virtual Apps and Desktops download page and install it using the following command:

sudo dpkg -i xendesktopvda_22.07.0.8-1.debian11_amd64.deb

Expect installation errors. To resolve missing dependencies and complete the installation, run the following command:

sudo apt --fix-broken install

Preparing the Linux VDA for a Non-Domain Joined Deployment

The Linux VDA machine will register directly to Citrix DaaS cloud service, bypassing the local Citrix Cloud Connectors. The machines must have access to the following range of addresses:

https://*.xendesktop.net on TCP 443

You can restrict communications to https://<<customer_ID>>.xendesktop.net, where customer_ID is the Citrix Cloud one. You can find it in the cloud portal by selecting the Identity and Access Management item in the left-side menu and opening the API Access page.

Frequently, corporate machines need to use a proxy to communicate with internet services. We support only HTTP proxies for the control traffic (VDA registration). Proxy authentication is not supported, nor is packet interception, decryption, or inspection. You may need to configure exceptions for the traffic between the VDA and the Citrix DaaS control plane. Failing to do so will prevent Linux VDA from registering.

The below image shows the network communication for an NDJ Linux VDA:

For Citrix Cloud Connector requirements, check out our product documentation.

Setting Up the Runtime Environment

MCS configuration files are stored in the /etc/xdl/mcs folder.

Linux VDA configuration is based on the mcs.conf file. Edit it with your preferred editor and manually configure the DNS server(s) to prevent errors during the base image configuration script.

For standard installations, you can leave other parameters set to their default values.

Please note, Linux VDA is configured by default as a multi-session machine. Set the VDI_MODE parameter to Y to configure it as a VDI workload. Now you can create a Citrix MCS base image by running the follow command:

sudo /opt/Citrix/VDA/sbin/deploymcs.sh

Shut down the template VM, then create a new snapshot of it.

Creating a Machine Catalog and Related Delivery Group

In Citrix Studio, create a new machine catalog, specifying the server or VDI deployment based on the VDI_MODE’s value, which we previously configured in the mcs.conf file.

Select Citrix Machine Creation Services (MCS) as the deployment method.

Select the snapshot of the Linux VDA base image.

Select Non-domain-joined as the identity type.

Complete the machine catalog wizard, adding any additional details. When the machine catalog has been created, create a new, dedicated delivery group as usual.

Please note that the Linux VDA does not support the publishing of desktops and apps from the same machine at the same time.

Now you can test your brand new Linux desktop. Remember, you can access it only through Citrix Workspace and NetScaler Gateway service.

After logging in with your credentials, Citrix Workspace presents you with your Linux desktop(s).

Once connected, you can check the user environment and some machine parameters as shown in the below picture.

As you can see, you are logged on to the Linux desktop using a local user (user1) that was automatically created during the HDX session preparation process. The username is based on the credentials used in the Citrix Workspace portal.

You can check the HDX session parameters by running the following command:

/opt/Citrix/VDA/sbin/ctxquery -f iP

In terms of network communications, there are two connections:

  • The Citrix DaaS, used for machine registration (*.xendesktop.net domain)
  • The Secure Gateway, used for HDX traffic proxied through the local Citrix Cloud Connector

Making Things Scale: Rendezvous v2 Protocol

The Rendezvous v2 Protocol allows HDX sessions to bypass the Citrix Cloud Connector by connecting the NetScaler Gateway service directly with the Linux VDA. If you are deploying the NDJ Linux machine in a public cloud infrastructure, you might not need to deploy any Citrix Cloud Connectors and go connectorless.

Citrix Cloud Connectors are still required if you are using Active Directory authentication in Citrix Workspace and/or if you are deploying the NDJ Linux VDA using on-premises hypervisors.

To use the Rendezvous V2 Protocol, you must meet the following requirements:

  • Access to the environment using Citrix Workspace and NetScaler Gateway service
  • Control plane: Citrix DaaS
  • LVDA version 2203+
  • Session Reliability must be enabled on the VDAs
  • The Rendezvous protocol must be enabled in the Citrix policy
  • The VDA machines must have access to:
    • https://*.xendesktop.net on TCP 443. Or access can be restrict to https://<customer_ID>.xendesktop.net, where customer_ID is the Citrix Cloud one.
    • https://*.*.nssvc.neton TCP 443 and UDP 443 for HDX sessions over TCP and EDT, respectively. If use of a wide range of subdomains is not allowed, use https://*.c.nssvc.net and https://*.g.nssvc.net. For more information, see this Knowledge Center article.

The below diagram depicts the network communication for a NDJ Linux VDA with Rendezvous v2 Protocol enabled:

To enable Rendezvous v2 Protocol, you can create a new Citrix policy with the following setting:

The policy can be applied to a specific Delivery Group or site wide. If the Linux VDA needs to use a proxy for accessing the internet, you need to add and configure the following setting also:

Gateway service communication supports various proxy types: transparent, HTTP, and SOCK5. Authentication (machine-level) is supported only using HTTP proxies. Packet interception, decryption, and inspection are not supported either. You need to configure an exception for the traffic between the VDA and the Citrix DaaS and Gateway service. Failing to do so will prevent Linux VDA from registering and/or hosting user sessions.

Enabling Rendezvous v2 Protocol for the non-domain joined Linux VDA requires you to add a few lines into the /etc/xdl/mcs/mcs_local_settings.reg configuration file:

Open the file with your preferred editor and add the following lines:

create -k "HKLM\Software\Citrix\VirtualDesktopAgent" -t "REG_DWORD" -v "GctRegistration" -d "0x00000001" --force

create -k "HKLM\Software\Citrix\VirtualDesktopAgent" -t "REG_DWORD" -v "KeyRegistration" -d "0x00000001" --force

Save the file and, if not already executed, run the following command to prepare the base image for the Citrix MCS deployment:

sudo /opt/Citrix/VDA/sbin/deploymcs.sh

At the end of execution, shut down the machine and proceed with the creation of a new machine catalog and related delivery group.

Now you can test your brand new Linux desktop and check if the Rendezvous v2 Protocol is working.

Once connected, you can use the ctxquery command to get information on the HDX session properties. If the Rendezvous protocol is used, the session will be shown as below:

In terms of network communications, there are two connections to the Citrix Cloud services:

  • The Citrix DaaS, used for machine registration (*.xendesktop.net domain)
  • The Gateway service, used for the HDX session (*.*.nssvc.net domain)

Conclusion

I hope this post has shed some light on Linux VDA and its non-domain joined configuration. Playing with Linux in a Windows world is not necessary for everyone. However, it isn’t that complicated and could even lead to some serious fun.

Installing and configuring Linux VDA is a quick process that takes about 30 minutes from the beginning to a working desktop. NDJ configuration allows for different scenarios to be enabled, from simple stateless machines to more complex environments, for example with scientific research. They all require a simple, reliable, and secure way to access desktops and applications. Citrix Linux VDA is now a viable solution for these scenarios.

Linux VDA is open for business and for new use cases. Complex scenarios and 3D graphics are welcome!