How to resolve Citrix Virtual Apps and Desktops EDT and DTLS issues

Table of Contents

Case
Solution
- Sources

Case #

You are experiencing intermittent Citrix Virtual Apps and Desktops connection issues, which you suspect are network related. In most cases the issues manifestate with black screen or grey/white screen for end users when they try to launch a hosted app or desktop. You may review the separate article on troubleshooting black, white and grey screens of death in Citrix Virtual Apps and Desktops. You have eliminated all other potential issues and the root cause seems to be network related. Users get either a black or a grey/white screen. The ICA session seems to be established on the VDA server side but there is no activity on the client side. If you examine the Citrix Workspace App connection details in the Connection Center, you will see that DTLS over UDP is configured.

Solution #

You should in this case examine the Citrix VAD Adaptive Transport and the Enlightened Data Transport (EDT) configuration in your environment.

Adaptive transport is a data transport mechanism for Citrix Virtual Apps and Desktops. It is faster, can scale, improves application interactivity, and is more interactive on challenging long-haul WAN and internet connections. Adaptive transport maintains high server scalability and efficient use of bandwidth. By using adaptive transport, ICA virtual channels automatically respond to changing network conditions. They intelligently switch the underlying protocol between the Citrix protocol called Enlightened Data Transport (EDT) and TCP to deliver the best performance. It improves data throughput for all ICA virtual channels including Thinwire display remoting, file transfer (Client Drive Mapping), printing, and multimedia redirection. The same setting is applicable for both LAN and WAN conditions.

By default, adaptive transport is enabled (Preferred), and EDT is used when possible, with fallback to TCP.

There are two places which you should check when dealing with potential Adaptive Transport and EDT issues. Firstly on the client side, you can eliminate the root cause of the issue quickly by following the workaround procedure below in one of your failing clients (local computer). This workaround enforces usage of TCP/TLS on the client side, instead of preferred UDP/DTLS.

Download Citrix workspace app ADMX/ADML templates from https://www.citrix.com/downloads/workspace-app/windows/workspace-app-for-windows-latest.html (see “downloads for admins” section) and copy them to local machine to path C:\Windows\PolicyDefinitions (for Windows 10).
Configure the relevant EDT policy in gpedit.msc local group policy tool by following step-by-step at https://docs.citrix.com/en-us/citrix-workspace-app-for-windows/configure.html (see section “ To configure adaptive transport using the Citrix Workspace app Group Policy Object (GPO) administrative template”). Value should be set to “Off”.
Check registry at HKEY\_LOCAL\_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\UDT and verify that the HDXOverUDP key is included with value Off. Value off means that EDT is disabled and hence TCP is enforced. Ideally this should be set to value “Preferred” so that UDP/DTLS is used instead for better performance.

Bear in mind that Citrix black screens can in some cases be due to a known FsLogix profile issue and not EDT related. For these cases you should follow a standard procedure for Citrix user graceful logoff cycle, paying attention to known local_ profile leftover issue. This is still open with Microsoft FsLogix Support and waiting on their fix.

If issue is resolved by applying the above workaround then you should check the client Citrix Workspace App connection center and validate that TCP is enforced, as shown in the example below.

This could explain the black/grey screen issue since routing from larger MTU to smaller MTU causes IP fragmentation, thus the disruption in UDP transmission (unreliable protocol). The TCP enforcement on the other hand is working because TCP (reliable protocol) retransmits the data in case of fragment loss in an IP fragmentation scenario (at the cost of low performance in higher latency networks).

If you have the above behavior and the issue does not occur again for the specific client with TCP enforced, then this means that something is not allowing EDT mechanism (DTLS/UDP) to work as expected. In many cases this is due to an Maximum Transfer Unit (MTU) value mismatch, in networks were a non-default MTU value is used (1500). For example this can happen with some ISP providers which use a different MTU value in their home/business modems and then they introduce a higher value, e.g. 9000 for jumbo frames at a higher level up in the ISP core network hierarchy. Packets moving from higher to lower MTU sized networks can be lost due to IP fragmentation. To avoid this packet loss in cases where networks you should make use of a Citrix VAD feature called MTU autodiscovery which must be configured on the VDA server side.

MTU Discovery enables EDT to automatically determine and set the appropriate MTU for each session, so every session will use the MTU that is best for that user’s connection, avoiding packet fragmentation and providing enhanced performance and reliability. MTU Discovery is not supported if the Multi-Stream computer setting policy is enabled. To apply MTU autodiscovery in your Citrix VDA servers by policy, following the procedure below.

Set this registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd Name: MtuDiscovery Type: DWORD Data: 00000001
Restart the VDA and wait for the VDA to register.
To disable EDT MTU Discovery, delete this registry value and restart the VDA.

This setting is machine-wide and affects all sessions connecting from a supported client. You can set this registry key by using local or domain group policy, as explained above for the case on the Citrix Workspace App client side.

You can also control EDT MTU Discovery selectively on the client by adding the MtuDiscovery parameter in the ICA file. To disable the feature, set the following under the Application section: MtuDiscovery=Off. To re-enable the feature, remove the MtuDiscovery parameter from the ICA file. For this ICA file parameter to work, enable the feature on the VDA. If the feature is not enabled on the VDA, the ICA file parameter has no effect.

Remember that the default value for the HDXOverUDP key is "Preferred", thus the EDT mechanism is enabled by default with fallback to TCP. This means that in other cases, you may also want to change the default HDXOverUDP value by policy from "Preferred" to "Off".

If you have an old installation of Citrix VAD (Citrix Virtual Apps and Desktops 7 1912 LTSR or later with Citrix Workspace app for Windows 1911 or later) and MTU autodiscovery is therefore not supported, you should apply the fix provided in the following Citrix article: https://support.citrix.com/article/CTX231821.

Last but not least bear in mind that in some rare cases, some ISP providers apply a firewall rule policy by default which seems to block DTLS traffic on port 443. So you should always double check with your ISP to ensure that no such default firewall policy is applied from their side.

For more troubleshooting guidance on a series of known Citrix issues, you can consult my “Citrix Virtual Apps and Desktops Troubleshooting” e-book.