Install the Linux VDA on Amazon Linux 2, RHEL, and Rocky Linux manually

Important:

For fresh installations, we recommend you use easy install for a quick installation. Easy install saves time and labor and is less error-prone than the manual installation detailed in this article.

Step 1: Prepare configuration information and the Linux machine

Step 1a: Verify the network configuration

Make sure that the network is connected and configured correctly. For example, you must configure the DNS server on the Linux VDA.

Step 1b: Set the host name

To make sure that the host name of the machine is reported correctly, change the /etc/hostname file to contain only the host name of the machine.

hostname

Step 1c: Assign a loopback address to the host name

To make sure that the DNS domain name and Fully Qualified Domain Name (FQDN) of the machine are reported back correctly, change the following line of the /etc/hosts file to include the FQDN and host name as the first two entries:

127.0.0.1 hostname-fqdn hostname localhost localhost.localdomain localhost4 localhost4.localdomain4

For example:

127.0.0.1 vda01.example.com vda01 localhost localhost.localdomain localhost4 localhost4.localdomain4

Remove any other references to hostname-fqdn or hostname from other entries in the file.

Note:

The Linux VDA currently does not support NetBIOS name truncation. The host name must not exceed 15 characters.

Tip:

Use a–z, A–Z, 0–9, and hyphen (-) characters only. Avoid underscores (_), spaces, and other symbols. Do not start a host name with a number and do not end with a hyphen. This rule also applies to Delivery Controller host names.

Step 1d: Check the host name

Verify that the host name is set correctly:

hostname
<!--NeedCopy-->

This command returns only the machine’s host name and not its fully qualified domain name (FQDN).

Verify that the FQDN is set correctly:

hostname -f
<!--NeedCopy-->

This command returns the FQDN of the machine.

Step 1e: Check name resolution and service reachability

Verify that you can resolve the FQDN and ping the domain controller and Delivery Controller:

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

ping delivery-controller-fqdn
<!--NeedCopy-->

If you cannot resolve the FQDN or ping either of these machines, review the steps before proceeding.

Step 1f: Configure clock synchronization

Maintaining accurate clock synchronization between the VDAs, Delivery Controllers, and domain controllers is crucial. Hosting the Linux VDA as a virtual machine (VM) can cause clock skew problems. For this reason, synchronizing time with a remote time service is preferred.

An RHEL default environment uses the Chrony daemon (chronyd) for clock synchronization.

Configure the Chrony service

As a root user, edit /etc/chrony.conf and add a server entry for each remote time server:

server peer1-fqdn-or-ip-address iburst

server peer2-fqdn-or-ip-address iburst
<!--NeedCopy-->

In a typical deployment, synchronize time from the local domain controllers and not directly from public NTP pool servers. Add a server entry for each Active Directory domain controller in the domain.

Remove any other server entries listed including loopback IP address, localhost, and public server *.pool.ntp.org entries.

Save changes and restart the Chrony daemon:

sudo systemctl restart chronyd
<!--NeedCopy-->

Step 1g: Install OpenJDK 11

The Linux VDA requires the presence of OpenJDK 11.

• If you are using RHEL, OpenJDK 11 is automatically installed as a dependency when you install the Linux VDA.

• If you are using Amazon Linux 2 or Rocky Linux, run the following command to enable and install OpenJDK 11:

   amazon-linux-extras install java-openjdk11
   <!--NeedCopy-->
  

Confirm the correct version:

sudo yum info java-11-openjdk
<!--NeedCopy-->

The prepackaged OpenJDK might be an earlier version. Update to OpenJDK 11:

sudo yum -y update java-11-openjdk
<!--NeedCopy-->

Step 1h: Install and specify a database to use

Note:

• We recommend you use SQLite for VDI mode only and use PostgreSQL for a hosted shared desktops delivery model.

• For easy install and MCS, you can specify SQLite or PostgreSQL to use without having to install them manually. Unless otherwise specified through /etc/xdl/db.conf, the Linux VDA uses PostgreSQL by default.

• For manual installations, you must install SQLite, PostgreSQL, or both manually. If you install both SQLite and PostgreSQL, you can specify one of them to use by editing /etc/xdl/db.conf after installing the Linux VDA package.

This section describes how to install PostgreSQL and SQLite and how to specify either of them to use.

Install PostgreSQL

The Linux VDA requires PostgreSQL:

• PostgreSQL 9 for Amazon Linux 2
• PostgreSQL 10 for RHEL 8.x and Rocky Linux 8.x
• PostgreSQL 13 for RHEL 9.4/9.3/9.2 and Rocky Linux 9.4/9.3/9.2

Run the following commands to install PostgreSQL:

sudo yum -y install postgresql-server

sudo yum -y install postgresql-jdbc
<!--NeedCopy-->

For RHEL 8.x and RHEL 9.4/9.3/9.2, run the following command to install libpq for PostgreSQL:

sudo yum -y install libpq
<!--NeedCopy-->

Run the following command to initialize the database. This action creates database files under /var/lib/pgsql/data.

sudo postgresql-setup initdb
<!--NeedCopy-->

Run the following commands to start PostgreSQL upon machine startup or immediately, respectively:

sudo systemctl enable postgresql

sudo systemctl start postgresql
<!--NeedCopy-->

Check the version of PostgreSQL by using:

psql --version
<!--NeedCopy-->

(For Amazon Linux 2 only) Verify that the data directory is set by using the psql command-line utility:

sudo -u postgres psql -c 'show data_directory'
<!--NeedCopy-->

Install SQLite

Run the following command to install SQLite:

sudo yum -y install sqlite
<!--NeedCopy-->

Specify a database to use

If you install both SQLite and PostgreSQL, you can specify one of them to use by editing /etc/xdl/db.conf after installing the Linux VDA package.

1. Run /opt/Citrix/VDA/sbin/ctxcleanup.sh. Omit this step if it is a fresh installation.
2. Edit /etc/xdl/db.conf to specify a database to use.
3. Run ctxsetup.sh.

Note:

You can also use /etc/xdl/db.conf to configure the port number for PostgreSQL.

Step 2: Prepare the hypervisor

Some changes are required when running the Linux VDA as a VM on a supported hypervisor. Make the following changes based on the hypervisor platform in use. No changes are required if you are running the Linux machine on bare metal hardware.

Fix time synchronization on XenServer (formerly Citrix Hypervisor)

When the XenServer Time Sync feature is enabled, within each paravirtualized Linux VM you experience issues with NTP and XenServer. Both try to manage the system clock. To avoid the clock becoming out of sync with other servers, ensure that the system clock within each Linux guest is synchronized with the NTP. This case requires disabling host time synchronization. No changes are required in HVM mode.

If you are running a paravirtualized Linux kernel with XenServer VM Tools installed, you can check whether the XenServer Time Sync feature is present and enabled from within the Linux VM:

su -

cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

This command returns 0 or 1:

• 0 - The time sync feature is enabled, and must be disabled.
• 1 - The time sync feature is disabled, and no further action is required.

If the /proc/sys/xen/independent_wallclock file is not present, the following steps are not required.

If enabled, disable the time sync feature by writing 1 to the file:

sudo echo 1 > /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

To make this change permanent and persistent after restart, edit the /etc/sysctl.conf file and add the line:

xen.independent_wallclock = 1

To verify these changes, restart the system:

su -

cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

This command returns the value 1.

Fix time synchronization on Microsoft Hyper-V

The Linux VMs with Hyper-V Linux Integration Services installed can apply the Hyper-V time synchronization feature to use the time of the host operating system. To ensure that the system clock remains accurate, you must enable this feature alongside the NTP services.

From the management operating system:

1. Open the Hyper-V Manager console.
2. For the settings of a Linux VM, select Integration Services.
3. Make sure that Time synchronization is selected.

Note:

This approach is different from VMware and XenServer (formerly Citrix Hypervisor), where host time synchronization is disabled to avoid conflicts with NTP. Hyper-V time synchronization can coexist and supplement NTP time synchronization.

Fix time synchronization on ESX and ESXi

When the VMware Time Synchronization feature is enabled, within each paravirtualized Linux VM you experience issues with the NTP and the hypervisor. Both try to synchronize the system clock. To avoid the clock becoming out of sync with other servers, ensure that the system clock within each Linux guest is synchronized with the NTP. This case requires disabling host time synchronization.

If you are running a paravirtualized Linux kernel with VMware Tools installed:

1. Open the vSphere Client.
2. Edit settings for the Linux VM.
3. In the Virtual Machine Properties dialog, open the Options tab.
4. Select VMware Tools.
5. In the Advanced box, clear Synchronize guest time with host.

Step 3: Add the Linux VM to the Windows domain

The following methods are available for adding Linux machines to the Active Directory (AD) domain:

• Samba Winbind
• Quest Authentication Services
• Centrify DirectControl
• SSSD
• PBIS

Follow instructions based on your chosen method.

Note:

Session launches might fail when the same user name is used for the local account in the Linux VDA and the account in AD.

Samba Winbind

For RHEL 9.4/9.3/9.2 and Rocky Linux 9.4/9.3/9.2, run the following command to prevent pam_winbind from changing the ownership of the root directory:

usermod -d /nonexistent nobody
<!--NeedCopy-->

Install or update the required packages:

For RHEL 9.4/9.3/9.2/8.x and Rocky Linux 9.4/9.3/9.2/8.x:

sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation oddjob-mkhomedir realmd authselect
<!--NeedCopy-->

For Amazon Linux 2:

sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation oddjob-mkhomedir realmd authconfig
<!--NeedCopy-->

Enable Winbind daemon to start upon machine startup

The Winbind daemon must be configured to start upon machine startup:

sudo /sbin/chkconfig winbind on
<!--NeedCopy-->

Configure Winbind Authentication

Configure the machine for Kerberos authentication by using Winbind:

1. Run the following command.

   For RHEL 9.4/9.3/9.2/8.x and Rocky Linux 9.4/9.3/9.2/8.x:

   sudo authselect select winbind with-mkhomedir --force
   <!--NeedCopy-->
   

   For Amazon Linux 2:

   sudo authconfig --disablecache --disablesssd --disablesssdauth --enablewinbind --enablewinbindauth --disablewinbindoffline --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --winbindtemplateshell=/bin/bash --enablemkhomedir --updateall
   <!--NeedCopy-->
   

   Where REALM is the Kerberos realm name in uppercase and domain is the NetBIOS name of the domain.

   If DNS-based lookup of the KDC server and realm name is required, add the following two options to the previous command:

   --enablekrb5kdcdns --enablekrb5realmdns

   Ignore any errors returned from the authconfig command about the winbind service failing to start. The errors can occur when authconfig tries to start the winbind service without the machine yet being joined to the domain.

2. Open /etc/samba/smb.conf and add the following entries under the [Global] section, but after the section generated by the authconfig tool:

   kerberos method = secrets and keytab
winbind refresh tickets = true
winbind offline logon = no

3. (For RHEL 9.4/9.3/9.2/8.x and Rocky Linux 9.4/9.3/9.2/8.x only) Open /etc/krb5.conf and add entries under the [libdefaults], [realms], and [domain_realm] sections:

   Under the [libdefaults] section:

   default_ccache_name = FILE:/tmp/krb5cc_%{uid}
default_realm = REALM
dns_lookup_kdc = true

   Under the [realms] section:

   REALM = {
kdc = fqdn-of-domain-controller
}

   Under the [domain_realm] section:

   realm = REALM
.realm = REALM

The Linux VDA requires the system keytab file /etc/krb5.keytab to authenticate and register with the Delivery Controller. The previous kerberos method setting forces Winbind to create the system keytab file when the machine is first joined to the domain.

Join Windows domain

Your domain controller must be reachable and you must have an Active Directory user account with permissions to add computers to the domain.

To add a Linux VM to the Windows domain, run the following command:

sudo realm join -U user --client-software=winbind REALM
<!--NeedCopy-->

Tip:

For the Linux VMs running on Amazon Linux 2, you can also use the following command to add them to the Windows domain:

sudo net ads join REALM -U user
<!--NeedCopy-->

REALM is the Kerberos realm name in uppercase, and user is a domain user who has permissions to add computers to the domain.

Configure PAM for Winbind

By default, the configuration for the Winbind PAM module (pam_winbind) does not enable Kerberos ticket caching and home directory creation. Open /etc/security/pam_winbind.conf and add or change the following entries under the [Global] section:

krb5_auth = yes
krb5_ccache_type = FILE
mkhomedir = yes

Make sure that any leading semicolons from each setting are removed. These changes require restarting the Winbind daemon:

sudo systemctl restart winbind
<!--NeedCopy-->

Tip:

The winbind daemon stays running only if the machine is joined to a domain.

Open /etc/krb5.conf and change the following setting under the [libdefaults] section from KEYRING to FILE type:

default_ccache_name = FILE:/tmp/krb5cc_%{uid}

For RHEL 9.4/9.3/9.2 and Rocky Linux 9.4/9.3/9.2, run the following commands to resolve the SELinux issue with Winbind:

ausearch -c 'winbindd' --raw | audit2allow -M my-winbindd -p /etc/selinux/targeted/policy/policy.*

semodule -X 300 -i my-winbindd.pp
<!--NeedCopy-->

Verify domain membership

The Delivery Controller requires that all VDA machines (Windows and Linux VDAs) have a computer object in Active Directory.

Run the net ads command of Samba to verify that the machine is joined to a domain:

sudo net ads testjoin
<!--NeedCopy-->

Run the following command to verify extra domain and computer object information:

sudo net ads info
<!--NeedCopy-->

Verify Kerberos configuration

To make sure that Kerberos is configured correctly for use with the Linux VDA, verify that the system keytab file has been created and contains valid keys:

sudo klist -ke
<!--NeedCopy-->

This command displays the list of keys available for the various combinations of principal names and cipher suites. Run the Kerberos kinit command to authenticate the machine with the domain controller using these keys:

sudo kinit -k MACHINE\$@REALM
<!--NeedCopy-->

The machine and realm names must be specified in uppercase. The dollar sign ($) must be escaped with a backslash (\) to prevent shell substitution. In some environments, the DNS domain name is different from the Kerberos realm name. Ensure that the realm name is used. If this command is successful, no output is displayed.

Verify that the TGT ticket for the machine account has been cached using:

sudo klist
<!--NeedCopy-->

Examine the account details of the machine using:

sudo net ads status
<!--NeedCopy-->

Verify user authentication

Use the wbinfo tool to verify that domain users can authenticate with the domain:

wbinfo --krb5auth=domain\\username%password
<!--NeedCopy-->

The domain specified here is the AD domain name, not the Kerberos realm name. For the bash shell, the backslash (\) character must be escaped with another backslash. This command returns a message indicating success or failure.

To verify that the Winbind PAM module is configured correctly, log on to the Linux VDA using a domain user account that has not been used before.

ssh localhost -l domain\\username
id -u
<!--NeedCopy-->

Verify that the tickets in the Kerberos credential cache are valid and not expired:

klist
<!--NeedCopy-->

Exit the session.

exit
<!--NeedCopy-->

A similar test can be performed by logging on to the Gnome or KDE console directly. Proceed to Step 6: Install the Linux VDA after the domain-joining verification.

Quest Authentication Services

Configure Quest on domain controller

Assume that you have installed and configured the Quest software on the Active Directory domain controllers, and have been granted administrative privileges to create computer objects in Active Directory.

Enable domain users to log on to Linux VDA machines

To enable domain users to establish HDX sessions on a Linux VDA machine:

1. In the Active Directory Users and Computers management console, open Active Directory user properties for that user account.
2. Select the Unix Account tab.
3. Check Unix-enabled.
4. Set the Primary GID Number to the group ID of an actual domain user group.

Note:

These instructions are equivalent for setting up domain users for logon using the console, RDP, SSH, or any other remoting protocol.

Configure Quest on Linux VDA

Work around SELinux policy enforcement

The default RHEL environment has SELinux fully enforced. This enforcement interferes with the Unix domain socket IPC mechanisms used by Quest, and prevents domain users from logging on.

The convenient way to work around this issue is to disable SELinux. As a root user, edit /etc/selinux/config and change the SELinux setting:

SELINUX=permissive

This change requires a machine restart:

reboot
<!--NeedCopy-->

Important:

Use this setting carefully. Reenabling SELinux policy enforcement after disabling can cause a complete lockout, even for the root user and other local users.

Configure VAS daemon

Autorenewal of Kerberos tickets must be enabled and disconnected. Authentication (offline logon) must be disabled.

sudo /opt/quest/bin/vastool configure vas vasd auto-ticket-renew-interval 32400

sudo /opt/quest/bin/vastool configure vas vas_auth allow-disconnected-auth false
<!--NeedCopy-->

This command sets the renewal interval to nine hours (32,400 seconds) which is one hour less than the default 10-hour ticket lifetime. Set this parameter to a lower value on systems with a shorter ticket lifetime.

Configure PAM and NSS

To enable domain user logon through HDX and other services such as su, ssh, and RDP, run the following commands to configure PAM and NSS manually:

sudo /opt/quest/bin/vastool configure pam

sudo /opt/quest/bin/vastool configure nss
<!--NeedCopy-->

Join Windows domain

Join the Linux machine to the Active Directory domain using the Quest vastool command:

sudo /opt/quest/bin/vastool -u user join domain-name
<!--NeedCopy-->

The user is any domain user who has permissions to join computers to the Active Directory domain. The domain-name is the DNS name of the domain, for example, example.com.

Restart the Linux machine after domain joining.

Verify domain membership

The Delivery Controller requires that all VDA machines (Windows and Linux VDAs) have a computer object in Active Directory. To verify that a Quest-joined Linux machine is on the domain:

sudo /opt/quest/bin/vastool info domain
<!--NeedCopy-->

If the machine is joined to a domain, this command returns the domain name. If the machine is not joined to any domain, the following error appears:

ERROR: No domain could be found.
ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm
default_realm not configured in vas.conf. Computer may not be joined to domain

Verify user authentication

To verify that Quest can authenticate domain users through PAM, log on to the Linux VDA using a domain user account that has not been used before.

ssh localhost -l domain\\username
id -u
<!--NeedCopy-->

Verify that a corresponding Kerberos credential cache file was created for the UID returned by the id -u command:

ls /tmp/krb5cc_uid
<!--NeedCopy-->

Verify that the tickets in the Kerberos credential cache are valid and not expired:

/opt/quest/bin/vastool klist
<!--NeedCopy-->

Exit the session.

exit
<!--NeedCopy-->

A similar test can be performed by logging on to the Gnome or KDE console directly. Proceed to Step 6: Install the Linux VDA after the domain-joining verification.

Centrify DirectControl

Join a Windows domain

With the Centrify DirectControl Agent installed, join the Linux machine to the Active Directory domain using the Centrify adjoin command:

su –
adjoin -w -V -u user domain-name
<!--NeedCopy-->

The user parameter is any Active Directory domain user who has permissions to join computers to the Active Directory domain. The domain-name is the name of the domain to join the Linux machine to.

Verify domain membership

The Delivery Controller requires that all VDA machines (Windows and Linux VDAs) have a computer object in Active Directory. To verify that a Centrify-joined Linux machine is on the domain:

su –
adinfo
<!--NeedCopy-->

Verify that the Joined to domain value is valid and the CentrifyDC mode returns connected. If the mode remains stuck in the starting state, then the Centrify client is experiencing server connection or authentication problems.

More comprehensive system and diagnostic information is available using:

adinfo --sysinfo all
adinfo –diag
<!--NeedCopy-->

Test connectivity to the various Active Directory and Kerberos services.

adinfo --test
<!--NeedCopy-->

Proceed to Step 6: Install the Linux VDA after the domain-joining verification.

SSSD

If you are using SSSD, follow the instructions in this section. This section includes instructions for joining a Linux VDA machine to a Windows domain and provides guidance for configuring Kerberos authentication.

To set up SSSD on RHEL, do the following:

1. Join the domain and create a host keytab
2. Set up SSSD
3. Enable SSSD
4. Verify the Kerberos configuration
5. Verify user authentication

Join the domain and create a host keytab

SSSD does not provide Active Directory client functions for joining the domain and managing the system keytab file. You can use adcli, realmd, or Samba instead.

This section describes the Samba approach for Amazon Linux 2 and the adcli approach for RHEL 8.x/9.x and Rocky Linux 8.x/9.x. For realmd, see the RHEL documentation. These steps must be followed before configuring SSSD.

• Samba (Amazon Linux 2):

  Install or update the required packages:

   sudo yum -y install krb5-workstation authconfig oddjob-mkhomedir samba-common-tools
   <!--NeedCopy-->
  

  On the Linux client with properly configured files:

  • /etc/krb5.conf
  • /etc/samba/smb.conf:

  Configure the machine for Samba and Kerberos authentication:

   sudo authconfig --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --update
   <!--NeedCopy-->
  

  Where REALM is the Kerberos realm name in uppercase and domain is the short NetBIOS name of the Active Directory domain.

  Note:

  Settings in this article are meant for the single-domain, single-forest model. Configure Kerberos based on your AD infrastructure.

  If DNS-based lookup of the KDC server and realm name is required, add the following two options to the preceding command:

  --enablekrb5kdcdns --enablekrb5realmdns

  Open /etc/samba/smb.conf and add the following entries under the [Global] section, but after the section generated by the authconfig tool:

  kerberos method = secrets and keytab
winbind offline logon = no

  Join the Windows domain. Ensure that your domain controller is reachable and you have an Active Directory user account with permissions to add computers to the domain:

   sudo net ads join REALM -U user
   <!--NeedCopy-->
  

  REALM is the Kerberos realm name in uppercase and user is a domain user who has permissions to add computers to the domain.

• Adcli (RHEL 9.4/9.3/9.2/8.x and Rocky Linux 9.4/9.3/9.2/8.x):

  Install or update the required packages:

   sudo yum -y install samba-common samba-common-tools krb5-workstation authconfig oddjob-mkhomedir realmd oddjob authselect
   <!--NeedCopy-->
  

  Configure the machine for Samba and Kerberos authentication:

   sudo authselect select sssd with-mkhomedir --force
   <!--NeedCopy-->
  

  Open /etc/krb5.conf and add the entries under the [realms] and [domain_realm] sections.

  Under the [realms] section:

  REALM = {
kdc = fqdn-of-domain-controller
}

  Under the [domain_realm] section:

  realm = REALM .realm = REALM

  Join the Windows domain. Ensure that your domain controller is reachable and you have an Active Directory user account with permissions to add computers to the domain:

   sudo realm join REALM -U user
   <!--NeedCopy-->
  

  REALM is the Kerberos realm name in uppercase and user is a domain user who has permissions to add computers to the domain.

Set up SSSD

Setting up SSSD consists of the following steps:

• Install the sssd-ad package on the Linux VDA by running the sudo yum -y install sssd command.
• Make configuration changes to various files (for example, sssd.conf).
• Start the sssd service.

(RHEL 9.4/9.3/9.2/8.x and Rocky Linux 9.4/9.3/9.2/8.x only) Open /etc/sssd/sssd.conf and add the following entries under the [domain/ad.example.com] section:

ad_gpo_access_control = permissive
full_name_format = %2$s\%1$s
fallback_homedir = /home/%d/%u
# Kerberos settings
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U

Replace ad.example.com, server.ad.example.com with the corresponding values. For more details, see sssd-ad(5) - Linux man page.

Set the file ownership and permissions on sssd.conf:

chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
restorecon /etc/sssd/sssd.conf

Enable SSSD

For RHEL 9.4/9.3/9.2/8.x and Rocky Linux 9.4/9.3/9.2/8.x:

Run the following commands to enable SSSD:

sudo systemctl restart sssd
sudo systemctl enable sssd.service
sudo chkconfig sssd on
<!--NeedCopy-->

For Amazon Linux 2:

Use authconfig to enable SSSD. Install oddjob-mkhomedir to ensure that the home directory creation is compatible with SELinux:

authconfig --enablesssd --enablesssdauth --enablemkhomedir --update

sudo systemctl start sssd

sudo chkconfig sssd on
<!--NeedCopy-->

Verify Kerberos configuration

Verify that the system keytab file has been created and contains valid keys:

sudo klist -ke
<!--NeedCopy-->

This command displays the list of keys available for the various combinations of principal names and cipher suites. Run the Kerberos kinit command to authenticate the machine with the domain controller using these keys:

sudo kinit –k MACHINE\$@REALM
<!--NeedCopy-->

The machine and realm names must be specified in uppercase. The dollar sign ($) must be escaped with a backslash (\) to prevent shell substitution. In some environments, the DNS domain name is different from the Kerberos realm name. Ensure that the realm name is used. If this command is successful, no output is displayed.

Verify that the TGT ticket for the machine account has been cached using:

sudo klist
<!--NeedCopy-->

Verify user authentication

Use the getent command to verify that the logon format is supported and the NSS works:

sudo getent passwd DOMAIN\\username
<!--NeedCopy-->

The DOMAIN parameter indicates the short version domain name. If another logon format is needed, verify by using the getent command first.

The supported logon formats are:

• Down-level logon name: DOMAIN\username
• UPN: username@domain.com
• NetBIOS Suffix format: username@DOMAIN

To verify that the SSSD PAM module is configured correctly, log on to the Linux VDA using a domain user account that has not been used before.

sudo ssh localhost –l DOMAIN\\username

id -u
<!--NeedCopy-->

Verify that a corresponding Kerberos credential cache file was created for the uid returned by the command:

ls /tmp/krb5cc_{uid}
<!--NeedCopy-->

Verify that the tickets in the user’s Kerberos credential cache are valid and not expired.

klist
<!--NeedCopy-->

Proceed to Step 6: Install the Linux VDA after the domain-joining verification.

PBIS

Download the required PBIS package

wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->

Make the PBIS installation script executable

chmod +x pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->

Run the PBIS installation script

sh pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->

Join Windows domain

Your domain controller must be reachable and you must have an Active Directory user account with permissions to add computers to the domain:

/opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->

The user is a domain user who has permissions to add computers to the Active Directory domain. The domain-name is the DNS name of the domain, for example, example.com.

Note: To set Bash as the default shell, run the /opt/pbis/bin/config LoginShellTemplate/bin/bash command.

Verify domain membership

The Delivery Controller requires that all VDA machines (Windows and Linux VDAs) have a computer object in Active Directory. To verify that a PBIS-joined Linux machine is on the domain:

/opt/pbis/bin/domainjoin-cli query
<!--NeedCopy-->

If the machine is joined to a domain, this command returns the information about the currently joined AD domain and OU. Otherwise, only the host name appears.

Verify user authentication

To verify that PBIS can authenticate domain users through PAM, log on to the Linux VDA using a domain user account that has not been used before.

ssh localhost -l domain\\user

id -u
<!--NeedCopy-->

Verify that a corresponding Kerberos credential cache file was created for the UID returned by the id -u command:

ls /tmp/krb5cc_uid
<!--NeedCopy-->

Exit the session.

exit
<!--NeedCopy-->

Proceed to Step 6: Install the Linux VDA after the domain-joining verification.

Step 4: Install .NET

In addition to the .NET Runtime, you must install .ASP.NET Core Runtime on all supported Linux distributions before you install or upgrade the Linux VDA. Version 6 is required for Amazon Linux 2. Version 8 is required for other distributions.

If your Linux distribution contains the .NET version that you require, install it from the built-in feed. Otherwise, install .NET from the Microsoft package feed. For more information, see https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.

After installing .NET, run the which dotnet command to find your runtime path.

Based on the command output, set the .NET runtime binary path. For example, if the command output is /aa/bb/dotnet, use /aa/bb as the .NET binary path.

Step 5: Download the Linux VDA package

1. Go to the Citrix Virtual Apps and Desktops download page.
2. Expand the appropriate version of Citrix Virtual Apps and Desktops.

3. Expand Components to find the Linux VDA. For example:

   

4. Click the Linux VDA link to access the Linux VDA downloads.

   

5. Download the Linux VDA package that matches your Linux distribution.

6. Download the GPG public key that you can use to verify the integrity of the Linux VDA package. For example:

   

   To verify the integrity of the Linux VDA package, run the following commands to import the public key into the RPM database and to check the package integrity:

   rpmkeys --import <path to the public key>
   rpm --checksig --verbose <path to the Linux VDA package>
   <!--NeedCopy-->
   

Step 6: Install the Linux VDA

You can do a fresh installation or upgrade an existing installation. The Linux VDA supports upgrades from the most recent version. For example, you can upgrade the Linux VDA from 2308 to 2311 and from 1912 LTSR to 2203 LTSR.

Step 6a: Do a fresh installation

1. (Optional) Uninstall the old version

   If you installed an earlier version other than the previous two and an LTSR release, uninstall it before installing the new version.

   1. Stop the Linux VDA services:

      sudo systemctl stop ctxvda
      
      sudo systemctl stop ctxhdx
      <!--NeedCopy-->
      

      Note:

      Before you stop the ctxvda and ctxhdx services, run the systemctl stop ctxmonitord command to stop the monitor service daemon. Otherwise, the monitor service daemon restarts the services you stopped.

   2. Uninstall the package:

      sudo rpm -e XenDesktopVDA
      <!--NeedCopy-->
      

   Note:

   To run a command, the full path is needed; alternately, you can add /opt/Citrix/VDA/sbin and /opt/Citrix/VDA/bin to the system path.

2. Download the Linux VDA package

   Go to the Citrix Virtual Apps and Desktops download page. Expand the appropriate version of Citrix Virtual Apps and Desktops and click Components to download the Linux VDA package that matches your Linux distribution.

3. Install the Linux VDA

   Note:

   • For RHEL and Rocky Linux, install the EPEL repository before you can install the Linux VDA successfully. For information on how to install EPEL, see the instructions at https://docs.fedoraproject.org/en-US/epel/.

   • Before installing the Linux VDA on RHEL 9.4/9.3/9.2 and Rocky Linux 9.4/9.3/9.2, update the libsepol package to version 3.4 or later.

   • Install the Linux VDA software using Yum:

     For Amazon Linux 2:

      sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm
      <!--NeedCopy-->
     

     For RHEL 9.4/9.3/9.2 and Rocky Linux 9.4/9.3/9.2:

      sudo yum install -y XenDesktopVDA-<version>.el9_x.x86_64.rpm
      <!--NeedCopy-->
     

     For RHEL 8.x and Rocky Linux 8.x:

      sudo yum install -y XenDesktopVDA-<version>.el8_x.x86_64.rpm
      <!--NeedCopy-->
     

   • Install the Linux VDA software using the RPM package manager. Before doing so, you must resolve the following dependencies:

     For Amazon Linux 2:

      sudo rpm -i XenDesktopVDA-<version>.amzn2.x86_64.rpm
      <!--NeedCopy-->
     

     RHEL 9.4/9.3/9.2 and Rocky Linux 9.4/9.3/9.2:

      sudo rpm -i XenDesktopVDA-<version>.el9_x.x86_64.rpm
      <!--NeedCopy-->
     

     For RHEL 8.x and Rocky Linux 8.x:

      sudo rpm -i XenDesktopVDA-<version>.el8_x.x86_64.rpm
      <!--NeedCopy-->
     

     RPM dependency list for RHEL 9.4/9.3/9.2 and Rocky Linux 9.4/9.3/9.2:

      gtk2 >= 2.24.33
     
      java-11-openjdk >= 11
     
      tzdata-java >= 2022
     
      ImageMagick >= 6.9
     
      firewalld >= 0.6.3
     
      policycoreutils-python-utils >= 2.8
     
      python3-policycoreutils >= 2.8
     
      dbus >= 1.12.8
     
      dbus-common >= 1.12.8
     
      dbus-daemon >= 1.12.8
     
      dbus-tools >= 1.12.8
     
      dbus-x11 >= 1.12.8
     
      xorg-x11-server-utils >= 7.7
     
      xorg-x11-xinit >= 1.3.4
     
      libXpm >= 3.5.12
     
      libXrandr >= 1.5.1
     
      libXtst >= 1.2.3
     
      pam >= 1.3.1
     
      util-linux >= 2.32.1
     
      util-linux-user >= 2.32.1
     
      xorg-x11-utils >= 7.5
     
      bash >= 4.3
     
      findutils >= 4.6
     
      gawk >= 4.2
     
      sed >= 4.5
     
      cups >= 1.6.0
     
      cups-filters >= 1.20.0
     
      ghostscript >= 9.25
     
      libxml2 >= 2.9
     
      libmspack >= 0.7
     
      ibus >= 1.5
     
      nss-tools >= 3.44.0
     
      chkconfig >= 1.20
     
      cyrus-sasl-gssapi >= 2.1
     
      python3 >= 3.6~
     
      qt5-qtbase >= 5.5~
     
      qt5-qtbase-gui >= 5.5~
     
      qrencode-libs >= 3.4.4
     
      imlib2 >= 1.4.9
     
      fuse-libs >= 2.9
     
      pulseaudio-utils >= 15.0
      <!--NeedCopy-->
     

     RPM dependency list for RHEL 8.x and Rocky Linux 8.x:

      java-11-openjdk >= 11
     
      icoutils >= 0.32
     
      firewalld >= 0.6.3
     
      policycoreutils-python >= 2.8.9
     
      policycoreutils-python-utils >= 2.8
     
      python3-policycoreutils >= 2.8
     
      dbus >= 1.12.8
     
      dbus-common >= 1.12.8
     
      dbus-daemon >= 1.12.8
     
      dbus-tools >= 1.12.8
     
      dbus-x11 >= 1.12.8
     
      xorg-x11-server-utils >= 7.7
     
      xorg-x11-xinit >= 1.3.4
     
      libXpm >= 3.5.12
     
      libXrandr >= 1.5.1
     
      libXtst >= 1.2.3
     
      pam >= 1.3.1
     
      util-linux >= 2.32.1
     
      util-linux-user >= 2.32.1
     
      xorg-x11-utils >= 7.5
     
      bash >= 4.3
     
      findutils >= 4.6
     
      gawk >= 4.2
     
      sed >= 4.5
     
      cups >= 1.6.0
     
      foomatic-filters >= 4.0.9
     
      cups-filters >= 1.20.0
     
      ghostscript >= 9.25
     
      libxml2 >= 2.9
     
      libmspack >= 0.7
     
      krb5-workstation >= 1.13
     
      ibus >= 1.5
     
      nss-tools >= 3.44.0
     
      gperftools-libs >= 2.4
     
      cyrus-sasl-gssapi >= 2.1
     
      python3 >= 3.6~
     
      qt5-qtbase >= 5.5~
     
      qt5-qtbase-gui >= 5.5~
     
      qrencode-libs >= 3.4.4
     
      imlib2 >= 1.4.9
      <!--NeedCopy-->
     

     RPM dependency list for Amazon Linux 2:

      java-11-openjdk >= 11
     
      ImageMagick >= 6.7.8.9
     
      firewalld >= 0.3.9
     
      policycoreutils-python >= 2.0.83
     
      dbus >= 1.6.12
     
      dbus-x11 >= 1.6.12
     
      xorg-x11-server-utils >= 7.7
     
      xorg-x11-xinit >= 1.3.2
     
      xorg-x11-server-Xorg >= 1.20.4
     
      libXpm >= 3.5.10
     
      libXrandr >= 1.4.1
     
      libXtst >= 1.2.2
     
      pam >= 1.1.8
     
      util-linux >= 2.23.2
     
      bash >= 4.2
     
      findutils >= 4.5
     
      gawk >= 4.0
     
      sed >= 4.2
     
      cups >= 1.6.0
     
      foomatic-filters >= 4.0.9
     
      libxml2 >= 2.9
     
      libmspack >= 0.5
     
      ibus >= 1.5
     
      cyrus-sasl-gssapi >= 2.1
     
      gperftools-libs >= 2.4
     
      nss-tools >= 3.44.0
     
      qt5-qtbase >= 5.5~
     
      qrencode-libs >= 3.4.1
     
      imlib2 >= 1.4.5
      <!--NeedCopy-->
     

   Note:

   For a matrix of the Linux distributions and the Xorg versions that this version of the Linux VDA supports, see System requirements.

Step 6b: Upgrade an existing installation (optional)

The Linux VDA supports upgrades from the most recent version. For example, you can upgrade the Linux VDA from 2308 to 2311 and from 1912 LTSR to 2203 LTSR.

For Amazon Linux 2, RHEL, and Rocky Linux distributions:

sudo yum -y localinstall <PATH>/<Linux VDA RPM>
<!--NeedCopy-->

Note:

• Upgrading an existing installation overwrites the configuration files under /etc/xdl. Before you conduct an upgrade, make sure to back up the files.

• Before upgrading the Linux VDA on RHEL 9.4/9.3/9.2 and Rocky Linux 9.4/9.3/9.2, update the libsepol package to version 3.4 or later.

• Starting with the 2407 release, the Linux VDA delegates package managers rpm or dpkg to handle configuration files during upgrades. The following describes how rpm and dpkg interact with changes to configuration files:

  • rpm: by default keeps the local version and saves the new version from the package with a .rpmnew extension.

  • dpkg: interactively prompts you with a choice on how to proceed. To silently upgrade the Linux VDA while retaining your local configuration file and saving the new package version as .dpkg-new or .dpkg-dist, use the following command:

     dpkg --force-confold -i package.deb  # Always keep your version, then save new package's version as *.dpkg-new or *.dpkg-dist
     <!--NeedCopy-->
    

• Restart the Linux VDA machine after upgrading the software.

Step 7: Install NVIDIA GRID drivers

Enabling HDX 3D Pro requires you to install the NVIDIA GRID drivers on your hypervisor and on the VDA machines.

Note:

To use HDX 3D Pro for Amazon Linux 2, we recommend you install NVIDIA driver 470. For more information, see System requirements.

To install and configure the NVIDIA GRID Virtual GPU Manager (the host driver) on the specific hypervisors, see the following guides:

• XenServer
• VMware ESX
• Nutanix AHV

To install and configure the NVIDIA GRID guest VM drivers, perform the following steps:

1. Ensure that the guest VM is shut down.
2. In XenCenter, allocate a GPU to the VM.
3. Start the VM.

4. Prepare the VM for the NVIDIA GRID driver:

   yum install gcc
   
   yum install "kernel-devel-$(uname -r)"
   
   systemctl set-default multi-user.target
   <!--NeedCopy-->
   

5. Follow the steps in the Red Hat Enterprise Linux document to install the NVIDIA GRID driver.

Note:

During the GPU driver install, select the default (‘no’) for each question.

Important:

After GPU pass-through is enabled, the Linux VM is no longer accessible through XenCenter. Use SSH to connect.

Set the correct configuration for the card:

etc/X11/ctx-nvidia.sh

To take advantage of large resolutions and multi-monitor capabilities, you need a valid NVIDIA license. To apply for the license, follow the product documentation from “GRID Licensing Guide.pdf - DU-07757-001 September 2015.”

Step 8: Configure the Linux VDA

Note:

Before setting up the runtime environment, ensure that the en_US.UTF-8 locale is installed on your OS. If the locale is not available on your OS, run the sudo locale-gen en_US.UTF-8 command. For Debian, edit the /etc/locale.gen file by uncommenting the # en_US.UTF-8 UTF-8 line and then run the sudo locale-gen command.

After installing the package, you must configure the Linux VDA by running the ctxsetup.sh script. Before making any changes, the script verifies the environment and ensures that all dependencies are installed. If necessary, you can rerun the script at any time to change settings.

You can run the script manually with prompting, or automatically with preconfigured responses. Review Help about the script before proceeding:

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh --help
<!--NeedCopy-->

Prompted configuration

Run a manual configuration with prompted questions:

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->

Automated configuration

For an automated install, provide the options required by the setup script with environment variables. If all required variables are present, the script does not prompt for any information.

Supported environment variables include:

• CTX_XDL_NON_DOMAIN_JOINED=’y|n’ – Whether to join the machine to a domain. The default value is ‘n’. For domain-joined scenarios, set it to ‘n’.

• CTX_XDL_AD_INTEGRATION=’winbind|sssd|centrify|pbis|quest’ – The Linux VDA requires Kerberos configuration settings to authenticate with the Delivery Controllers. The Kerberos configuration is determined from the installed and configured Active Directory integration tool on the system.

• CTX_XDL_DDC_LIST=’<list-ddc-fqdns>‘ – The Linux VDA requires a space-separated list of Delivery Controller Fully Qualified Domain Names (FQDNs) to use for registering with a Delivery Controller. At least one FQDN or CNAME must be specified.

• CTX_XDL_VDI_MODE=’y|n’ – Whether to configure the machine as a dedicated desktop delivery model (VDI) or hosted shared desktop delivery model. For HDX 3D Pro environments, set the value to ‘y’.

• CTX_XDL_HDX_3D_PRO=’y|n’ – The Linux VDA supports HDX 3D Pro, a set of GPU acceleration technologies designed to optimize the virtualization of rich graphics applications. If HDX 3D Pro is selected, the VDA is configured for VDI desktops (single-session) mode - (that is, CTX_XDL_VDI_MODE=‘y’).

• CTX_XDL_START_SERVICE=’y|n’ – Determines whether the Linux VDA services are started when the configuration is complete.

• CTX_XDL_REGISTER_SERVICE=’y|n’ – The Linux Virtual Desktop services are started after machine startup.

• CTX_XDL_ADD_FIREWALL_RULES=’y|n’ – The Linux VDA services require incoming network connections to be allowed through the system firewall. You can open the required ports (by default ports 80 and 1494) automatically in the system firewall for the Linux Virtual Desktop.

• CTX_XDL_DESKTOP_ENVIRONMENT=gnome/gnome-classic/kde/mate/xfce/’<none>‘ – Specifies the GNOME, GNOME Classic, KDE, MATE, or Xfce desktop environment to use in sessions. If you set it to ‘<none>‘, the default desktop configured on the VDA is used.

  You can also switch between desktop environments by running commands or using the system tray. For more information, see Desktop switching commands and System tray.

• CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime – The path to install .NET for supporting the new broker agent service (ctxvda). The default path is ‘/usr/bin’.

• CTX_XDL_VDA_PORT=port-number – The Linux VDA communicates with Delivery Controllers through a TCP/IP port.

• CTX_XDL_SITE_NAME=<dns-name> – The Linux VDA discovers LDAP servers through DNS. To limit the DNS search results to a local Site, specify a DNS Site name. If unnecessary, set to ‘<none>‘.

• CTX_XDL_LDAP_LIST=’<list-ldap-servers>‘ – The Linux VDA queries DNS to discover LDAP servers. If DNS cannot provide LDAP service records, you can provide a space-separated list of LDAP FQDNs with LDAP ports. For example, ad1.mycompany.com:389 ad2.mycompany.com:3268 ad3.mycompany.com:3268. To enable faster LDAP queries within an Active Directory forest, enable Global Catalog on a domain controller and specify the relevant LDAP port number as 3268. This variable is set to ‘<none>‘ by default.

• CTX_XDL_SEARCH_BASE=search-base-set – The Linux VDA queries LDAP through a search base set to the root of the Active Directory Domain (for example, DC=mycompany,DC=com). To improve search performance, you can specify a search base (for example, OU=VDI,DC=mycompany,DC=com). If unnecessary, set to ‘<none>‘.

• CTX_XDL_SUPPORT_DDC_AS_CNAME=’y|n’ – The Linux VDA supports specifying a Delivery Controller name using a DNS CNAME record.

Set the environment variable and run the configure script:

export CTX_XDL_NON_DOMAIN_JOINED='n'
export CTX_XDL_AD_INTEGRATION=sssd|winbind|centrify|pbis|quest
export CTX_XDL_DDC_LIST='<list-ddc-fqdns>'
export CTX_XDL_VDI_MODE='y|n'
export CTX_XDL_HDX_3D_PRO='y|n'
export CTX_XDL_START_SERVICE='y|n'
export CTX_XDL_REGISTER_SERVICE='y|n'
export CTX_XDL_ADD_FIREWALL_RULES='y|n'
export CTX_XDL_DESKTOP_ENVIRONMENT=gnome|gnome-classic|kde|mate|xfce|'<none>'
export CTX_XDL_DOTNET_RUNTIME_PATH='<path-to-install-dotnet-runtime>'
export CTX_XDL_VDA_PORT='<port-number>'
export CTX_XDL_SITE_NAME='<dns-site-name>'|'<none>'
export CTX_XDL_LDAP_LIST='<list-ldap-servers>'|'<none>'
export CTX_XDL_SEARCH_BASE='<search-base-set>'|'<none>'
export CTX_XDL_SUPPORT_DDC_AS_CNAME='y|n'
sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh --silent
<!--NeedCopy-->

When running the sudo command, type the -E option to pass the existing environment variables to the new shell it creates. We recommend that you create a shell script file from the preceding commands with #!/bin/bash as the first line.

Alternatively, you can specify all parameters by using a single command:

sudo CTX_XDL_NON_DOMAIN_JOINED='n' \
CTX_XDL_AD_INTEGRATION=winbind|centrify|sssd|pbis|quest \
CTX_XDL_DDC_LIST='<list-ddc-fqdns>' \
CTX_XDL_VDI_MODE='y|n' \
CTX_XDL_HDX_3D_PRO='y|n' \
CTX_XDL_START_SERVICE='y|n' \
CTX_XDL_REGISTER_SERVICE='y|n' \
CTX_XDL_ADD_FIREWALL_RULES='y|n' \
CTX_XDL_DESKTOP_ENVIRONMENT=gnome|gnome-classic|kde|mate|xfce|'<none>' \
CTX_XDL_DOTNET_RUNTIME_PATH='<path-to-install-dotnet-runtime>' \
CTX_XDL_VDA_PORT='<port-number>' \
CTX_XDL_SITE_NAME='<dns-site-name>'|'<none>' \
CTX_XDL_LDAP_LIST='<list-ldap-servers>'|'<none>' \
CTX_XDL_SEARCH_BASE='<search-base-set>'|'<none>' \
CTX_XDL_SUPPORT_DDC_AS_CNAME='y|n' \
/opt/Citrix/VDA/sbin/ctxsetup.sh --silent
<!--NeedCopy-->

Remove configuration changes

In some scenarios, you might have to remove the configuration changes made by the ctxsetup.sh script without uninstalling the Linux VDA package.

Review Help about this script before proceeding:

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh --help
<!--NeedCopy-->

To remove configuration changes:

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh
<!--NeedCopy-->

Important:

This script deletes all configuration data from the database and renders the Linux VDA inoperable.

Configuration logs

The ctxsetup.sh and ctxcleanup.sh scripts display errors on the console, with additional information written to the configuration log file /tmp/xdl.configure.log.

Restart the Linux VDA services to have the changes take effect.

Step 9: Run XDPing

Run sudo /opt/Citrix/VDA/bin/xdping to check for common configuration issues with a Linux VDA environment. For more information, see XDPing.

Step 10: Run the Linux VDA

After configuring the Linux VDA by using the ctxsetup.sh script, you can run the following commands to control the Linux VDA.

Start the Linux VDA:

To start the Linux VDA services:

sudo systemctl restart ctxhdx

sudo systemctl restart ctxvda
<!--NeedCopy-->

Stop the Linux VDA:

To stop the Linux VDA services:

sudo systemctl stop ctxvda

sudo systemctl stop ctxhdx
<!--NeedCopy-->

Note:

Before you stop the ctxvda and ctxhdx services, run the systemctl stop ctxmonitord command to stop the monitor service daemon. Otherwise, the monitor service daemon restarts the services you stopped.

Restart the Linux VDA:

To restart the Linux VDA services:

sudo systemctl stop ctxvda

sudo systemctl restart ctxhdx

sudo systemctl restart ctxvda
<!--NeedCopy-->

Check the status of the Linux VDA:

To check the running status of the Linux VDA services:

sudo systemctl status ctxvda

sudo systemctl status ctxhdx
<!--NeedCopy-->

Step 11: Create machine catalogs

The process for creating machine catalogs and adding Linux VDA machines is similar to the traditional Windows VDA approach. For a more detailed description of how to complete these tasks, see Create machine catalogs and Manage machine catalogs.

For creating machine catalogs that contain Linux VDA machines, there are a few restrictions that differentiate the process from creating machine catalogs for Windows VDA machines:

• For the operating system, select:
  • The Multi-session OS option for a hosted shared desktops delivery model.
  • The Single-session OS option for a VDI dedicated desktop delivery model.
• Do not mix Linux and Windows VDA machines in the same machine catalog.

Note:

Early versions of Citrix Studio did not support the notion of a “Linux OS.” However, selecting the Windows Server OS or Server OS option implies an equivalent hosted shared desktops delivery model. Selecting the Windows Desktop OS or Desktop OS option implies a single user per machine delivery model.

Tip:

When you rejoin a removed machine to the Active Directory domain, remove the machine from and add it back to its machine catalog.

Step 12: Create delivery groups

The process for creating a delivery group and adding machine catalogs containing Linux VDA machines is almost identical to Windows VDA machines. For a more detailed description of how to complete these tasks, see Create delivery groups.

For creating delivery groups that contain Linux VDA machine catalogs, the following restrictions apply:

• Ensure that the AD users and groups that you select have been properly configured to log on to the Linux VDA machines.
• Do not allow logon of unauthenticated (anonymous) users.
• Do not mix the delivery group with machine catalogs that contain Windows machines.

Important:

Publishing applications is supported with Linux VDA Version 1.4 and later. However, the Linux VDA does not support the delivery of desktops and apps to the same machine.

For information about how to create machine catalogs and delivery groups, see Citrix Virtual Apps and Desktops 7 2407.