Playing with a non-domain joined (NDJ) Citrix Linux VDA

Welcome to our blog today on how to configure Linux VDA for Citrix workloads. We are seeing a huge uptake on Linux use cases within Citrix, and this led us to create a blog to demystify how to configure it.

This is a 30-minutes deployment guide for delivering an amazing user experience to all Linux users. No need to join the Linux VDA to an Active Directory domain or perform complex configurations, just install the Linux VDA and go.

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

If you will use Rendezvous v2 protocol, you may go connectorless too.

User experience will be one of a kind. The process will start with an ordinary logon in the Workspace portal. Followed by a double click on a Linux Desktop icon and in a few seconds, you will be connected to your Linux machine. Just pure Linux NDJ “magic”.

Huge thank you to Javier and Emmet from the Dublin Technologist team. They spent a lot of time helping me with requirements, tests, failures, and getting good results.

Requirements and current limitations

There are some important requirements and current limitations to be aware of before starting the journey. Non-domain joined deployments are supported only in Citrix DaaS and Gateway service must be used. Finally, Linux Desktop must be deployed using Citrix Machine Creation Services (MCS).

On the limitations side, it is important to note that StoreFront is not supported. Users must use Workspace and Gateway service to access published resources. Other elements not supported are Remote PC and lock/unlock sessions.

Other Linux VDA requirements such as the supported Linux distribution, supported Xorg’s versions, and supported hypervisors are well documented at this link:

https://docs.citrix.com/en-us/linux-virtual-delivery-agent/current-release/system-requirements.html

Network communications and proxy requirements will be discussed later in the article.

Get started with Linux VDA

The following instructions are based on Debian 11 distribution. They are also 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 starting from this page:

https://docs.citrix.com/en-us/linux-virtual-delivery-agent/current-release/installation-overview.html

Please remember the Citrix MCS requirements and configure the Base Image with a single disk. Additionally, at least one desktop must be installed. Linux VDA supports GNOME, GNOME Classic, MATE, and in most case KDE. 

Double check the installed Xorg version. Using the correct one will save time and prevent 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. Microsoft provides guidance and instructions at the following link:

https://learn.microsoft.com/en-us/dotnet/core/install/linux

In Debian case use 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 following commands

which dotnet
dotnet –-list-runtimes

Now you need to download from Citrix web site the desired Citrix Linux VDA version and then install it using the following command:

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

Installation errors are expected. 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 Cloud Connectors. The machines must have access to the following range of addresses:

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

It is possible to restrict communications to https://<customer_ID&gt;.xendesktop.net, where is customer_ID is the Citrix Cloud one. You can find it in Cloud Portal by selecting 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. Also packet interception, decryption, and inspection are not supported too. 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 to register.

The below diagram depicts the network communication for a NDJ Linux VDA:

For Citrix Cloud Connector requirements please refer to the following articles:

https://docs.citrix.com/en-us/citrix-cloud/overview/requirements/internet-connectivity-requirements.html

Set up the runtime environment

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

Linux VDA configuration will be based on 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

Note
By default, Linux VDA is configured as a multi-session machine. To configured it as
VDI one set the VDI_MODE parameter to Y.

Now you can create a Citrix MCS Base Image running the follow command:

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

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

Create a Machine Catalog and related Delivery Group

In Citrix Studio, create a new Machine Catalog specifying server or VDI deployment base on the VDI_MODE’s value previously configured in the mcs.conf file.

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

Select the snapshot of the Linux VDA Base Image.

Select Non-domain-joined as Identity type.

Complete the Machine Catalog wizard filling additional details. When Machine Catalog is 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.
https://docs.citrix.com/en-us/linux-virtual-delivery-agent/current-release/configure/session/publish-apps.html#publish-applications-using-citrix-studio

Now you can test your brand-new Linux Desktop. Remember that you can access it only through Workspace and Gateway services.

After logging in with your credentials, Workspace presents you 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 above, you are logged on the Linux Desktop using a local user (user1). It was automatically created during the HDX session preparation process. The username is based on the credentials used in the Workspace portal.

You can check HDX session parameters running 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 local Citrix Cloud Connector

GOING CONNECTORLESS: Rendezvous v2 protocol

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

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

To use Rendezvous V2 protocol the following requirements need to be met:

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

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 requires to use a proxy for accessing Internet, you need to add and configure the following setting too.

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 and exception for the traffic between the VDA and the Citrix DaaS and Gateway service. Failing to do so will prevent Linux VDA to register and/or to host user sessions.

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

Open the file with 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 following command to prepare the Base Image for the Citrix MCS deployment:

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

At the end of execution, shutdown 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 Rendezvous v2 protocol is working.

Once connected, you can use the ctxquery command to get information on the HDX session properties. If 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 HDX session (*.*.nssvc.net domain)

SUMMARY

Hopefully, this article has shed some light on Linux VDA and its non-domain joined configuration. Playing with Linux in a Windows world is not everyone’s cup of tea. We discovered during testing it is not as complicated as originally expected and we had some fun configuring.

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

Stay in touch

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.