January 6, 2023
Contributed by:
B
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: Launch the YaST tool
The SUSE Linux Enterprise YaST tool is used for configuring all aspects of the operating system.
To launch the text-based YaST tool:
su -yast<!--NeedCopy-->
To launch the UI-based YaST tool:
su -yast2 &<!--NeedCopy-->
Step 1b: Configure networking
The following sections provide information on configuring the various networking settings and services used by the Linux VDA. Configuring networking is carried out via the YaST tool, not via other methods such as Network Manager. These instructions are based on using the UI-based YaST tool. The text-based YaST tool can be used but has a different method of navigation that is not documented here.
Configure host name and Domain Name System (DNS)
- Launch the UI-based YaST tool.
- Select System and then Network Settings.
- Open the Hostname/DNS tab.
- Select the no option for Set Hostname via DHCP.
- Select the Use Custom Policy option for Modify DNS Configuration.
-
Edit the following to reflect your networking setup:
- Static Hostname – Add the DNS host name of the machine.
- Name Server – Add the IP address of the DNS server. It is typically the IP address of the AD Domain Controller.
- Domain Search List – Add the DNS domain name.
-
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 <FQDN of the VDA> <hostname of the VDA> localhost
Note:
The Linux VDA currently does not support NetBIOS name truncation. Therefore, 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.
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 machine’s FQDN.
Check name resolution and service reachability
Verify that you can resolve the FQDN and ping the domain controller and Delivery Controller:
nslookup domain-controller-fqdnping domain-controller-fqdnnslookup delivery-controller-fqdnping delivery-controller-fqdn<!--NeedCopy-->
If you cannot resolve the FQDN or ping either of these machines, review the steps before proceeding.
Step 1c: Configure the NTP service
It is crucial to maintain accurate clock synchronization between the VDAs, Delivery Controllers, and domain controllers. Hosting the Linux VDA as a virtual machine (VM) can cause clock skew problems. For this reason, maintaining time using a remote NTP service is preferred. Some changes might be required to the default NTP settings.
For SUSE 15.3:
- Launch the UI-based YaST tool.
- Select Network Services and then NTP Configuration.
- In the Start NTP Daemon section, select Now and on Boot.
- Select Dynamic for Configuration Source.
- Add NTP servers as needed. The NTP service is normally hosted on the Active Directory domain controller.
-
Delete or uncomment the following line in /etc/chrony.conf if it exists.
include /etc/chrony.d/*.conf
After editing chrony.conf, restart the
chronyd
service.sudo systemctl restart chronyd.service<!--NeedCopy-->
Step 1d: Install Linux VDA dependent packages
The Linux VDA software for SUSE Linux Enterprise depends on the following packages:
- OpenJDK 11
- Open Motif Runtime Environment 2.3.1 or later
- Cups 1.6.0 or later
- ImageMagick 6.8 or later
Add repositories
You can obtain most required packages except ImageMagick from official repositories. To obtain the ImageMagick packages, enable the sle-module-desktop-applications
repository by using YaST or the following command:
SUSEConnect -p sle-module-desktop-applications/<version number>/x86_64
Install the Kerberos client
Install the Kerberos client for mutual authentication between the Linux VDA and the Delivery Controllers:
sudo zypper install krb5-client<!--NeedCopy-->
The Kerberos client configuration depends on which Active Directory integration approach is used. See the following description.
Install OpenJDK 11
The Linux VDA requires the presence of OpenJDK 11.
To install OpenJDK 11, run the following command:
sudo zypper install java-11-openjdk<!--NeedCopy-->
Install and specify a database to use
As an experimental feature, you can use SQLite in addition to PostgreSQL. You can also switch between SQLite and PostgreSQL by editing /etc/xdl/db.conf
after installing the Linux VDA package. For manual installations, you must install SQLite and PostgreSQL manually before being able to switch between them.
This section describes how to install the PostgreSQL and SQLite databases and how to specify a database to use.
Note:
We recommend you use SQLite for VDI mode only.
Install PostgreSQL
To install Postgresql
, run the following commands:
sudo zypper install postgresql13-serversudo zypper install postgresql-jdbc<!--NeedCopy-->
Run the following commands to start PostgreSQL upon machine startup or immediately, respectively:
sudo systemctl enable postgresqlsudo systemctl restart postgresql<!--NeedCopy-->
Install SQLite
For SUSE, run the following command to install SQLite:
sudo zypper install sqlite3<!--NeedCopy-->
Specify a database to use
After you install SQLite, PostgreSQL, or both, you can specify a database to use by editing /etc/xdl/db.conf
after installing the Linux VDA package. To do so, complete the following steps:
- Run
/opt/Citrix/VDA/sbin/ctxcleanup.sh
. Omit this step if it is a fresh installation. - Edit
/etc/xdl/db.conf
to specify a database to use. - 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 Citrix Hypervisor
If the Citrix Hypervisor Time Sync feature is enabled, within each paravirtualized Linux VM you experience issues with NTP and Citrix Hypervisor. Both try to manage the system clock. To avoid the clock becoming out of sync with other servers, synchronize the system clock within each Linux guest with NTP. This case requires disabling host time synchronization. No changes are required in HVM mode.
If you are running a paravirtualized Linux kernel with Citrix VM Tools installed, you can check whether the Citrix Hypervisor 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:
reboot<!--NeedCopy-->
After restart, verify that the setting is correct:
su -cat /proc/sys/xen/independent_wallclock<!--NeedCopy-->
This command returns the value 1.
Fix time synchronization on Microsoft Hyper-V
Linux VMs with Hyper-V Linux Integration Services installed can apply the Hyper-V time synchronization feature to use the host operating system’s time. To ensure that the system clock remains accurate, enable this feature alongside the NTP services.
From the management operating system:
- Open the Hyper-V Manager console.
- For the settings of a Linux VM, select Integration Services.
- Ensure that Time synchronization is selected.
Note:
This approach is different from VMware and 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
If the VMware Time Synchronization feature is enabled, within each paravirtualized Linux VM you experience issues with NTP and the hypervisor. Both try to synchronize the system clock. To avoid the clock becoming out of sync with other servers, synchronize the system clock within each Linux guest with NTP. This case requires disabling host time synchronization.
If you are running a paravirtualized Linux kernel with VMware Tools installed:
- Open the vSphere Client.
- Edit settings for the Linux VM.
- In the Virtual Machine Properties dialog, open the Options tab.
- Select VMware Tools.
- 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
- 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 for the account in AD.
Samba Winbind
Join Windows domain
Your domain controller must be reachable and you must have an Active Directory user account with permissions to add machines to the domain:
-
Launch YaST, select Network Services and then Windows Domain Membership.
-
Make the following changes:
- Set the Domain or Workgroup to the name of your Active Directory domain or the IP address of the domain controller. Ensure that the domain name is in uppercase.
- Check Use SMB information for Linux Authentication.
- Check Create Home Directory on Login.
- Check Single Sign-on for SSH.
- Ensure that Offline Authentication is not checked. This option is not compatible with the Linux VDA.
-
Click OK. If you are prompted to install some packages, click Install.
-
If a domain controller is found, it asks whether you want to join the domain. Click Yes.
-
When prompted, type the credentials of a domain user with permission to add machines to the domain and click OK.
-
Restart your services manually or restart the machine. We recommend you restart the machine:
su -reboot<!--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
Make sure 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 machine account details 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.
Verify that the Winbind PAM module is configured correctly. To do so, log on to the Linux VDA using a domain user account that has not been used before.
ssh localhost -l domain\\usernameid -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 user’s 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 service
Configure Quest on domain controller
Assume that you have installed and configured the Quest software on the 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:
- In the Active Directory Users and Computers management console, open Active Directory user properties for that user account.
- Select the Unix Account tab.
- Check Unix-enabled.
- 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
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 32400sudo /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 logons through HDX and other services such as su, ssh, and RDP, configure PAM and NSS manually:
sudo /opt/quest/bin/vastool configure pamsudo /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 machines to the Active Directory domain. The domain-name is the DNS name of the domain, for example, example.com.
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
Verify that Quest can authenticate domain users through PAM. To do so, log on to the Linux VDA using a domain user account that has not been used before.
ssh localhost -l domain\\usernameid -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 Windows domain
With the Centrify DirectControl Agent installed, join the Linux machine to the Active Directory domain using the Centrify adjoin command:
sudo adjoin -w -V -u user domain-name<!--NeedCopy-->
The user is any Active Directory domain user who has permissions to join machines 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:
sudo 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 alladinfo –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 on SUSE, 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 SUSE, complete the following steps:
- Join the domain and create host keytabs
- Configure PAM for SSSD
- Set up SSSD
- Enable SSSD
- Verify domain membership
- Verify the Kerberos configuration
- Verify user authentication
Join the domain and create host keytab
SSSD does not provide Active Directory client functions for joining the domain and managing the system keytab file. You can use the Samba approach instead. Complete the following steps before configuring SSSD.
-
Stop and disable the Name Service Cache Daemon (NSCD) daemon.
sudo systemctl stop nscdsudo systemctl disable nscd<!--NeedCopy-->
-
Check the host name and Chrony time synchronization.
hostnamehostname -fchronyc traking<!--NeedCopy-->
-
Install or update the required packages:
sudo zypper install samba-client sssd-ad<!--NeedCopy-->
-
Edit the
/etc/krb5.conf
file as a root user to permit the kinit utility to communicate with the target domain. Add the following entries under the [libdefaults], [realms], and [domain_realm] sections:Note:
Configure Kerberos based on your AD infrastructure. The following settings are meant for the single-domain, single-forest model.
[libdefaults] dns_canonicalize_hostname = false rdns = false default_realm = REALM forwardable = true[realms] REALM = { kdc = fqdn-of-domain-controller default_domain = realm admin_server = fqdn-of-domain-controller }[domain_realm] .realm = REALM<!--NeedCopy-->
realm is the Kerberos realm name, such as example.com. REALM is the Kerberos realm name in uppercase, such as EXAMPLE.COM.
-
Edit
/etc/samba/smb.conf
as a root user to permit the net utility to communicate with the target domain. Add the following entries under the [global] section:[global] workgroup = domain client signing = yes client use spnego = yes kerberos method = secrets and keytab realm = REALM security = ADS<!--NeedCopy-->
domain is the short NetBIOS name of an Active Directory domain, such as EXAMPLE.
-
Modify the passwd and group entries in the
/etc/nsswitch.conf
file to reference SSSD when resolving users and groups.passwd: compat sssgroup: compat sss<!--NeedCopy-->
-
Use the configured Kerberos client to authenticate to the target domain as Administrator.
kinit administrator<!--NeedCopy-->
-
Use the net utility to join the system to the domain and generate a system keytab file.
net ads join osname="SUSE Linux Enterprise Server" osVersion=15 -U administrator<!--NeedCopy-->
Configure PAM for SSSD
Before configuring PAM for SSSD, install or update the required packages:
sudo zypper install sssd sssd-ad<!--NeedCopy-->
Configure the PAM module for user authentication through SSSD and create home directories for user logons.
sudo pam-config --add --ssssudo pam-config --add --mkhomedir<!--NeedCopy-->
Set up SSSD
-
Edit
/etc/sssd/sssd.conf
as a root user to permit the SSSD daemon to communicate with the target domain. An examplesssd.conf
configuration (extra options can be added as needed):[sssd] config_file_version = 2 services = nss,pam domains = domain-dns-name[domain/domain-dns-name] id_provider = ad auth_provider = ad access_provider = ad ad_domain = domain-dns-name ad_server = fqdn-of-domain-controller ldap_id_mapping = true ldap_schema = ad# Kerberos settings krb5_ccachedir = /tmp krb5_ccname_template = FILE:%d/krb5cc_%U# Comment out if the users have the shell and home dir set on the AD side fallback_homedir = /home/%d/%u default_shell = /bin/bash# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available# ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM ad_gpo_access_control = permissive<!--NeedCopy-->
domain-dns-name is the DNS domain name, such as example.com.
Note:
ldap_id_mapping is set to true so that SSSD itself takes care of mapping Windows SIDs to Unix UIDs. Otherwise, the Active Directory must be able to provide POSIX extensions. ad_gpo_access_control is set to permissive to prevent an invalid logon error for Linux sessions. See the man pages for
sssd.conf
andsssd-ad
. -
Set the file ownership and permissions on
sssd.conf
:sudo chmod 0600 /etc/sssd/sssd.conf<!--NeedCopy-->
Enable SSSD
Run the following commands to enable and start the SSSD daemon at system startup:
sudo systemctl enable sssdsudo systemctl start sssd<!--NeedCopy-->
Verify domain membership
-
Run the
net ads
command of Samba to verify that the machine is joined to a domain:sudo net ads testjoin<!--NeedCopy-->
(Video) Installation of Opensuse Leap 15.4 -
Run the following command to verify extra domain and computer object information:
sudo net ads info<!--NeedCopy-->
Verify Kerberos configuration
Make sure 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
SSSD does not provide a command-line tool for testing authentication directly with the daemon, and can only be done via PAM.
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.
ssh localhost -l domain\\usernameid -uklistexit<!--NeedCopy-->
Verify that the Kerberos tickets returned by the klist
command are correct for that user and have not expired.
As a root user, verify that a corresponding ticket cache file was created for the uid returned by the previous id -u
command:
ls /tmp/krb5cc_uid<!--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.
PBIS
Download the required PBIS package
For example:
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
For example:
chmod +x pbis-open-9.1.0.551.linux.x86_64.rpm.sh<!--NeedCopy-->
Run the PBIS installation script
For example:
sh pbis-open-9.1.0.551.linux.x86_64.rpm.sh<!--NeedCopy-->
Join a Windows domain
Your domain controller must be reachable and you must have an Active Directory user account with permissions to add machines to the domain:
/opt/pbis/bin/domainjoin-cli join domain-name user<!--NeedCopy-->
The user is a domain user who has permissions to add machines 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
Verify that PBIS can authenticate domain users through PAM. To do so, log on to the Linux VDA using a domain user account that has not been used before.
ssh localhost -l domain\\userid -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 Runtime 6.0
Before installing the Linux VDA, install .NET Runtime 6.0 according to the instructions at https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.
After installing .NET Runtime 6.0, 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
- Go to the Citrix Virtual Apps and Desktops download page.
- Expand the appropriate version of Citrix Virtual Apps and Desktops.
-
Click Components to download the Linux VDA package that matches your Linux distribution and the GPG public key that you can use to verify the integrity of the Linux VDA package.
To verify the integrity of the Linux VDA package by using the public key, import the public key into the RPM database and run the following commands:
rpmkeys --import <path to the public key>rpm --checksig --verbose <path to the Linux VDA package><!--NeedCopy-->
Step 6: Install the Linux VDA
Step 6a: 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.
-
Stop the Linux VDA services:
sudo /sbin/service ctxvda stopsudo /sbin/service ctxhdx stop<!--NeedCopy-->
Note:
Before you stop the
ctxvda
andctxhdx
services, run theservice ctxmonitorservice stop
command to stop the monitor service daemon. Otherwise, the monitor service daemon restarts the services you stopped. -
Uninstall the package:
sudo rpm -e XenDesktopVDA<!--NeedCopy-->
Important:
Upgrading from the latest two versions is supported.
Note:
You can find installed components under /opt/Citrix/VDA/.
To run a command, the full path is needed; alternatively, you can add /opt/Citrix/VDA/sbin and /opt/Citrix/VDA/bin to the system path.
Step 6b: Install the Linux VDA
Install the Linux VDA software using Zypper:
sudo zypper install XenDesktopVDA-<version>.sle15_x.x86_64.rpm<!--NeedCopy-->
Install the Linux VDA software using the RPM package manager:
sudo rpm -i XenDesktopVDA-<version>.sle15_x.x86_64.rpm<!--NeedCopy-->
Step 6c: Upgrade the Linux VDA (optional)
You can upgrade an existing installation from the previous two versions and from an LTSR release.
Note:
(Video) Linux Crash Course - Formatting & Mounting Storage VolumesUpgrading an existing installation overwrites the configuration files under /etc/xdl. Before you conduct an upgrade, make sure to back up the files.
sudo rpm -U XenDesktopVDA-<version>.sle15_x.x86_64.rpm<!--NeedCopy-->
RPM Dependency list for SUSE 15:
java-11-openjdk >= 11ImageMagick >= 7.0dbus-1 >= 1.12.2dbus-1-x11 >= 1.12.2xorg-x11 >= 7.6_1libXpm4 >= 3.5.12libXrandr2 >= 1.5.1libXtst6 >= 1.2.3pam >= 1.3.0bash >= 4.4findutils >= 4.6gawk >= 4.2sed >= 4.4cups >= 2.2cups-filters >= 1.25libxml2-2 >= 2.9libmspack0 >= 0.6ibus >= 1.5libtcmalloc4 >= 2.5libcap-progs >= 2.26mozilla-nss-tools >= 3.53.1libpython3_6m1_0 >= 3.6~libQt5Widgets5 >= 5.12libqrencode4 >= 4.0.0libImlib2-1 >= 1.4.10<!--NeedCopy-->
Important:
Restart the Linux VDA machine after upgrading.
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.
To install and configure the NVIDIA GRID Virtual GPU Manager (the host driver) on the specific hypervisors, see the following guides:
- Citrix Hypervisor
- VMware ESX
- Nutanix AHV
To install and configure the NVIDIA GRID guest VM drivers, perform the following general steps:
- Make sure that the guest VM is shut down.
- In the hypervisor control panel, allocate a GPU to the VM.
- Start the VM.
- Install the guest VM driver on the VM.
Step 8: Configure the Linux VDA
After installing the package, you must configure the Linux VDA by running the ctxsetup.sh
script. Before the script makes any changes, it 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 installation, 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_SUPPORT_DDC_AS_CNAME=Y | N – The Linux VDA supports specifying a Delivery Controller name using a DNS CNAME record. Set to N by default.
- 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 alias must be specified.
- CTX_XDL_VDA_PORT=port-number – The Linux VDA communicates with Delivery Controllers through a TCP/IP port, which is port 80 by default.
- CTX_XDL_REGISTER_SERVICE=Y | N - The Linux VDA services are started after machine startup. The value is set to Y by default.
- 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 (ports 80 and 1494 by default) automatically in the system firewall for the Linux VDA. Set to Y by default.
- CTX_XDL_AD_INTEGRATION=1 | 2 | 3 | 4 – 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. Specify the supported Active Directory integration method to use:
- 1 – Samba Winbind
- 2 – Quest Authentication Service
- 3 – Centrify DirectControl
- 4 – SSSD
- 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_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 this variable to Y. This variable is set to N by default.
- 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. This variable is set to <none> by default.
- 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. If you specify the LDAP port number as 389, the Linux VDA queries each LDAP server in the specified domain in polling mode. If there are x number of policies and y number of LDAP servers, the Linux VDA performs the total of X multiplied by Y queries. If the polling time exceeds the threshold, session logons might fail. To enable the faster LDAP queries, 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). This variable is set to <none> by default.
- CTX_XDL_FAS_LIST=’list-fas-servers’ – The Federated Authentication Service (FAS) servers are configured through AD Group Policy. The Linux VDA does not support AD Group Policy, but you can provide a semicolon-separated list of FAS servers instead. The sequence must be the same as configured in AD Group Policy. If any server address is removed, fill its blank with the <none> text string and do not modify the order of server addresses. To communicate with FAS servers properly, make sure you append a port number consistent with that specified on the FAS servers, for example, CTX_XDL_FAS_LIST=’fas_server_1_url:port_number; fas_server_2_url: port_number; fas_server_3_url: port_number’.
- CTX_XDL_DOTNET_ RUNTIME_PATH=path-to-install-dotnet-runtime – The path to install .NET Runtime 6.0 for supporting the new broker agent service (
ctxvda
). The default path is /usr/bin. -
CTX_XDL_DESKTOP _ENVIRONMENT=gnome/gnome-classic/mate – Specifies the GNOME, GNOME Classic, or MATE desktop environment to use in sessions. If you leave the variable unspecified, the desktop currently installed on the VDA is used. However, if the currently installed desktop is MATE, you must set the variable value to mate.
You can also change the desktop environment for a target session user by completing the following steps:
- Create an
.xsession
file under the $HOME/<username> directory on the VDA. -
Edit the
.xsession
file to specify a desktop environment.-
For MATE desktop on SUSE 15
MSESSION="$(type -p mate-session)" if [ -n "$MSESSION" ]; then exec mate-session fi
-
For GNOME Classic desktop on SUSE 15
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then export GNOME_SHELL_SESSION_MODE=classic exec gnome-session --session=gnome-classic fi
-
For GNOME desktop on SUSE 15
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then exec gnome-session fi
-
- Share the 700 file permission with the target session user.
Starting with Version 2209, session users can customize their desktop environments. To enable this feature, you must install switchable desktop environments on the VDA in advance. For more information, see Custom desktop environments by session users.
- Create an
- CTX_XDL_START_SERVICE=Y | N – Whether or not the Linux VDA services are started when the Linux VDA configuration is complete. Set to Y by default.
- CTX_XDL_TELEMETRY_SOCKET_PORT – The socket port for listening for Citrix Scout. The default port is 7503.
- CTX_XDL_TELEMETRY_PORT – The port for communicating with Citrix Scout. The default port is 7502.
Set the environment variable and run the configure script:
export CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|Nexport CTX_XDL_DDC_LIST='list-ddc-fqdns'export CTX_XDL_VDA_PORT=port-numberexport CTX_XDL_REGISTER_SERVICE=Y|Nexport CTX_XDL_ADD_FIREWALL_RULES=Y|Nexport CTX_XDL_AD_INTEGRATION=1|2|3|4export CTX_XDL_HDX_3D_PRO=Y|Nexport CTX_XDL_VDI_MODE=Y|Nexport 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_FAS_LIST='list-fas-servers' | '<none>'export CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtimeexport CTX_XDL_DESKTOP_ENVIRONMENT= gnome | gnome-classic | mate | '<none>'export CTX_XDL_TELEMETRY_SOCKET_PORT=port-numberexport CTX_XDL_TELEMETRY_PORT=port-numberexport CTX_XDL_START_SERVICE=Y|Nsudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh<!--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_SUPPORT_DDC_AS_CNAME=Y|N \CTX_XDL_DDC_LIST='list-ddc-fqdns' \CTX_XDL_VDA_PORT=port-number \CTX_XDL_REGISTER_SERVICE=Y|N \CTX_XDL_ADD_FIREWALL_RULES=Y|N \CTX_XDL_AD_INTEGRATION=1|2|3|4 \CTX_XDL_HDX_3D_PRO=Y|N \CTX_XDL_VDI_MODE=Y|N \CTX_XDL_SITE_NAME=dns-name \CTX_XDL_LDAP_LIST='list-ldap-servers' \CTX_XDL_SEARCH_BASE=search-base-set \CTX_XDL_FAS_LIST='list-fas-servers' \CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime \CTX_XDL_DESKTOP_ENVIRONMENT=gnome|gnome-classic|mate \CTX_XDL_TELEMETRY_SOCKET_PORT=port-number \CTX_XDL_TELEMETRY_PORT=port-number \CTX_XDL_START_SERVICE=Y|N \/opt/Citrix/VDA/sbin/ctxsetup.sh<!--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 /usr/local/sbin/ctxcleanup.sh --help<!--NeedCopy-->
To remove configuration changes:
sudo /usr/local/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 a 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 /sbin/service ctxhdx startsudo /sbin/service ctxvda start<!--NeedCopy-->
Stop the Linux VDA:
To stop the Linux VDA services:
sudo /sbin/service ctxvda stopsudo /sbin/service ctxhdx stop<!--NeedCopy-->
Note:
Before you stop the
ctxvda
andctxhdx
services, run theservice ctxmonitorservice stop
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 /sbin/service ctxvda stopsudo /sbin/service ctxhdx restartsudo /sbin/service ctxvda start<!--NeedCopy-->
Check the Linux VDA status:
To check the running status of the Linux VDA services:
sudo /sbin/service ctxvda statussudo /sbin/service ctxhdx status<!--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:
If you remove and rejoin a machine to the Active Directory domain, you must remove and add the machine to the machine catalog again.
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:
- Make sure 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:
(Video) Using Rufus to make Linux boot-able on USB drive.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 2212.
FAQs
How install VDA Linux? ›
- Step 1a: Verify the network configuration. ...
- Step 1b: Set the host name. ...
- Step 1c: Assign a loopback address to the host name. ...
- Step 1d: Check the host name. ...
- Step 1e: Check name resolution and service reachability. ...
- Step 1f: Configure clock synchronization.
/dev/vda is the first detected paravirtualizated disk driver. It is faster than emulated sdX devices if both are referred to the same disk, because there are less overhead in its operation compared to an emulated drive.
How to install SLES 12 SP5? ›- Insert the SUSE Linux Enterprise Server DVD into the drive, then reboot the computer to start the installation program. ...
- Select Installation on the boot screen, then press Enter.
- Step 1: Prepare Ubuntu for VDA installation. Step 1a: Verify the network configuration. ...
- Step 2: Prepare the hypervisor. ...
- Step 3: Add the Linux virtual machine (VM) to the Windows domain. ...
- Step 4: Install the Linux VDA.
Location: By default, components are installed in C:\Program Files\Citrix . This default is fine for most deployments. If you specify a different location, that location must have execute permissions for the network service. Components: By default, Citrix Workspace app for Windows is not installed with the VDA.
How do I connect to VDA? ›- On the Delivery Controller page in the VDA installation wizard, select Do it manually. Then, enter the FQDN of an installed Controller and then click Add. ...
- For a command-line VDA installation, use the /controllers option and specify the FQDNs of the installed Controllers or Cloud Connectors.
To upgrade a VDA, download a VDA installer and run it on the machine or image. You can use the installer's graphical or command-line interface.
How does a VDA work? ›Virtual Delivery Agent (VDA)
Those machines deliver applications or desktops. The VDA enables the machine to register with the Controller, which in turn allows the machine and the resources it is hosting to be made available to users. VDAs establish and manage the connection between the machine and the user device.
- On the VDA: Restart the Citrix Desktop service. ...
- Ensure Anti-virus exclusions are configured correctly: Endpoint Security, Antivirus and Antimalware Best Practices.
- Check DNS settings CTX235416.
- Review Troubleshooting Tab in Studio: Verify the VDA is powered on.
- Insert the SUSE Linux Enterprise Server DVD into the drive, then reboot the computer to start the installation program. ...
- Select Installation on the boot screen, then press Enter.
How to upgrade suse 12 SP3 to sles 15 SP1? ›
Upgrading from SLES 12 SP2 or older service packs directly is not supported. You need at least SLES 12 SP3 before you can proceed to SLES 15 SP1. If you cannot do a fresh installation, first upgrade your installed SLES 12 service pack to SLES 12 SP3. This upgrade is described in the SLES 12 SP3 Deployment Guide.
How to upgrade SLES 15 SP1 to SP2? ›- 3.1 Make Sure the Current System Is Up-To-Date.
- 3.2 Read the Release Notes.
- 3.3 Make a Backup.
- 3.4 Listing Installed Packages and Repositories.
- 3.5 Disable the LTSS Extension.
- 3.6 Upgrading from SUSE Linux Enterprise Server 11 SP4.
- 3.7 Migrate Your PostgreSQL Database.
- 3.8 Shut Down Virtual Machine Guests.
- Download Linux Agent installation package. Go to Agent > Download Agent (or File > Add Device > Download Agent) ...
- Install the Agent. Run the following commands as root to install the Agent on the target operating system. ...
- Register the Linux Agent.
Or VDA, in short, is a relatively small piece of software that gets installed on all virtual and physical machines running a Windows/Linux server and/or desktop operating system as part of our XenDesktop Site, making their resources remotely available to users.
What is a VDA solution? ›Windows Virtual Desktop Access (VDA) is an authorization strategy that requires each device seeking access to a Windows virtual desktop in a virtual desktop infrastructure (VDI) to be licensed.
What is VDA and where it is deployed? ›Windows VDA is a device or user-based licensing mechanism for managing access to virtual desktops. Deployment instructions are provided for the following scenarios: Active Directory-joined VMs. Azure Active Directory-joined VMs.
What is VDA port? ›Component | Usage | Default incoming port |
---|---|---|
VDA | ICA/HDX with Session Reliability | 2598 |
VDA | ICA/HDX over TLS/DTLS | 443 |
VDA | ICA/HDX over WebSocket | 8008 |
VDA | ICA/HDX audio over UDP Real-time Transport | 16500..16509 |
Time skew may cause VDAs not to register with the DDC and can be easily checked/tested by verifying the Windows Time Service is running on the VDA. If the service is in stopped state, try starting the service and check if this has fixed the Time Sync issue and the VDA is registering correctly.
How do I know if my VDA is registered? ›Verify that VDA registered with a Controller
In Windows Logs > Application log, you should see an event 1012 from Citrix Desktop Service saying that it successfully registered with a controller. If you don't see successful registration, then you'll need to fix the ListOfDDCs registry key.
VDI is the actual solution and platform itself. If you want a multitude of devices to be able to access one desktop then a VDI solution is a good choice. VDA on the other hand is the license each user-owned device needs in order to access a VDI desktop.
What are VDA licenses? ›
What is Windows Virtual Desktop Access (VDA)? Windows VDA is a device based subscription designed to help organizations license devices that do not qualify for Windows Client SA, such as thin clients and contractor-owned PCs, so these devices can access a virtual desktop.
What is VDA application? ›The Bangalore Development Authority (BDA) offers apartments at an affordable price to the residents with the various housing schemes. The motive of this initiative is to provide homes to lower and middle-class people at very reasonable rates. Click on the link below to know how to apply for the BDA site.
What is the VDA full form? ›Rate of Minimum Wages (Variable Dearness Allowance) Revised for Central sphere workers.
How do I run VDA Cleanup utility? ›- Run the VDA cleanup utility with administrator privileges.
- The tool might prompt for a system restart to complete driver removal.
- After system restart, log on to the machine with the same administrator account, The tool automatically reruns.
Users can access their virtual desktops remotely over a network. Any endpoint device, such as a laptop, smartphone or tablet, can be used to access a virtual desktop. The virtual desktop provider installs client software on the endpoint device, and the user then interacts with that software on the device.
How do I restart VDA? ›- Launch the Services console: Click Start and then type Services.
- Verify the Citrix Desktop Service is present, restart the service, and check the Event Log for any errors: From the Services console, right-click the Citrix Desktop Service and select Restart.
...
To use the tool from the command line:
- To start the tool, run the command “Citrix Health Assistant.exe" –start.
- To view the command line help, run the command “Citrix Health Assistant.exe" –help.
- Create the mount point directory on Linux: sudo mkdir /mnt/iso.
- Mount the ISO file on Linux: sudo mount -o loop /path/to/my-iso-image.iso /mnt/iso.
- Verify it, run: mount OR df -H OR ls -l /mnt/iso/
- Unmount the ISO file using: sudo umount /mnt/iso/
1 The bash Package and /etc/profile. Bash is the default system shell.
Are SLES and Suse the same? ›SUSE Linux Enterprise Server (SLES) is a Linux-based server operating system created and maintained by the German-based organization, SUSE.
How do I convert Suse 12 to Suse 15? ›
Upgrade from SUSE 12 SP4 or SP5 to SUSE 15 SP1
After the installation is finished, restart the VM. Verify the kernel and OS version. Make sure that the version is SUSE 12 SP4 or SUSE 12 SP5. Install the suse-migration-sle15-activation.
Similar to prior service packs, SUSE Linux Enterprise Server 12 SP5 will also be supported for a maximum of 8 years (General End Oct 2024, LTSS upto 2027).
How do I update my Suse Linux repository? ›- Open the terminal application.
- Log in to the server using the ssh command as follows. ssh user@server-ip.
- Refresh OpenSUSE repository from the Internet, execute: sudo zypper refresh.
- Upgrade OpenSUSE Linux, type: sudo zypper update.
- Open the terminal app.
- For remote server log in using the ssh command: ...
- Refersh SUSE repository from the Internet or local server, execute: ...
- Show information about update advisories, run: ...
- Issue the command sudo zypper update to install updates.
- 3.1 Make sure the system is up-to-date.
- 3.2 Read the release notes.
- 3.3 Make a backup.
- 3.4 Check the available disk space.
- 3.5 Listing installed packages and repositories.
- 3.6 Disable the LTSS extension.
- 3.7 Perform version-specific upgrade steps.
- 3.8 Migrate your PostgreSQL database.
Click Settings > All Settings. Under Node & Group Management, click Manage Agents > Add Agent. Click Connect to a previously installed agent > click Next. Enter the name, IP address, and port number for the agent and click Server-initiated communication.
How do I manually install an ePO agent? ›- Copy the installation package, FramePkg.exe, from your McAfee ePO to a shared folder on a network server accessible by the target system.
- On the target system, navigate to and right-click FramePkg.exe, select Run as administrator, and wait a few moments while McAfee Agent is installed.
- Copy the zip file and the localagent-config. ...
- Unzip the agent installer to \\LBDFFILE01\Install\LocalAgent.
- Copy the localagent-config. ...
- In a PowerShell window, navigate to \\LBDFFILE01\Install\LocalAgent, and run the following command.
From the diskpart prompt, type clean and press Enter. The drive's partition, data, and signature is now removed. You will return to the diskpart prompt. Warning: Once you type clean and hit enter the drive will be erased.
Do I need a VDA license? ›Customers who want to use devices that do not qualify for Windows Client SA, such as thin clients, will need to license those devices with Windows Virtual Desktop Access (VDA) in order to access a Windows VDI desktop. Windows VDA is also applicable to third party devices, such as contractor or employee-owned PCs.
Does E3 include VDA? ›
The VDA add-on allows Microsoft 365 E3 and E5 users to access the Windows Enterprise Virtual Desktop Infrastructure (VDI) on dedicated servers when those users don't have a primary device with a Qualifying Operating System (QOS), for example, Windows Pro.