Optimize your Citrix Virtual Apps and Desktops services Traffic flow

The default traffic flow isn’t optimized when designing a new Citrix Virtual Apps and Desktops services (CVAD) environment. There are a couple of options that would result in a better traffic flow. The more you optimize the traffic flow, the better the User Experience, and I think that’s what everybody wants because happy users make happy admins. Some options are only for on-premises deployments, while others are for both on-premises and public cloud deployments. This article shows some options that don’t need any massive changes and are easy to implement.

The Default

The default traffic flow isn’t optimized, and it depends on a couple of different components that could all result in latency. When one of these components fails, it results in a disconnected session or even downtime. To better understand how the current traffic flows, look at the diagram below.

Default CVAD traffic Flow
Default CVAD traffic Flow

As you can see, all traffic goes through your Cloud Connectors, causing a high dependency on your Cloud Connectors. That’s why you would like to have them redundant and give them the appropriate resources.

Now that you understand the default traffic flow, it’s time to look at the options to optimize your traffic flow and realize a better user experience.

Rendezvous Protocol Traffic flow

The first option to optimize your traffic flow is the Rendezvous protocol. With this option enabled, your users don’t depend on the Cloud Connectors when they have a session. This option is available for public Cloud, Private Cloud, and on-premises. Whit every new Citrix Virtual Apps and Desktop Services deployment, this option is enabled by default, but current deployments could benefit from enabling this option.

What’s the benefit of this for you and your end-users:

  1. The user doesn’t notice any delay if the Cloud Connectors are overloaded or fail.
  2. As the cloud connectors no longer proxies the VDA-Gateway traffic makes them more scalable.

Have a look at the below diagram where the Rendezvous protocol is enabled

CVAD Rendezvous Traffic flow
CVAD Rendezvous Traffic flow

Requirements and validation

As mentioned before, Whit every new Citrix Virtual Apps and Desktop Services deployment, this option is enabled by default. An updated and detailed list of the requirements is available here. Below are some of the requirements you should take a look at:

  • Access to the environment using Citrix Workspace and Citrix Gateway service.
  • Control Plane: Citrix Virtual Apps and Desktops Service (Citrix Cloud).
  • VDA: Version 1912 or later.
    • 2012 is the minimum required for EDT Rendezvous.
    • 2012 is the minimum required for non-transparent proxy support (no PAC file support).
    • 2103 is the minimum required for proxy configuration with a PAC file.
  • The VDAs must have access to https://*.nssvc.net
  • The VDAs must be able to connect to the addresses mentioned above on TCP 443 and UDP 443 for TCP Rendezvous and EDT Rendezvous, respectively.
  • Cloud Connectors must obtain the VDAs’ FQDNs when brokering a session. Accomplish this in one of these two ways:
    • Enable DNS resolution for the site.
    • DNS Reverse Lookup Zone with PTR records for the VDAs.

If you meet all these requirements, you can validate if the rendezvous protocol is enabled. The first thing you should look at is to see if the policy is enabled. This option is enabled by default but could have been disabled by another admin or a previous deployment. Below you can see the policy enabled.

When the policy is configured correctly, you can validate if the rendezvous protocol is working by following these steps:

  1. Launch PowerShell or a command prompt within the HDX session.
  2. Run ctxsession.exe –v.
  3. The transport protocols in use indicate the type of connection:
    1. TCP Rendezvous: TCP > SSL > CGP > ICA
    1. EDT Rendezvous: UDP > DTLS > CGP > ICA
    1. Proxy through Cloud Connector: TCP > CGP > ICA

Direct Workload Connection Traffic flow

When you have configured the Rendezvous protocol and notice it, your users undoubtedly notice this next option. The downside of this next option is that it requires that your workload is on-premises or your branch offices have a direct connection to your data center.

The default traffic flow and rendezvous protocol traffic flow directs all traffic through the Gateway Service, even when you sit next to your VDA. We don’t want to take a detour while you can use a direct route. A direct route gives us fewer dependencies and the best user experience, and that’s when Direct Workload Connection comes in place.

Whit Direct Workload Connection, your internal users connect to the VDA directly, without the traffic going through the Gateway Service. Although there are numerous Points of Presence (PoPs) for the Gateway Services to reduce latency, this is never the most optimized connection for internal users that connect to an internal VDA routed through an external Gateway. That is causing latency, and latency causes unhappy users.

How does Direct Workload Connection work?

When a user connects to the Citrix Cloud, the traffic comes from a public IP address. This address is used to determine if the user is an Internal or External user. But before Citrix Workspace knows which Public IP Address is associated with your on-premises VDA and internal users, you need to create these locations in your workspace management plane.

But why shouldn’t you use the internal Ip address, you would think? The answer is relatively simple. When using the endpoint/internal IP address, we quickly would run into issues. How many users, public places, and customers you visit have the following internal-only IP Address scheme (10.0.0.0, 192.168.0.0, 172.16.0.0)? Suppose you connect to Citrix Workspace with an endpoint with an IP address the same as you defined as internal. In that case, Citrix Workspace thinks you are internal and tries to bypass the Gateway Service, resulting in a failed connection.

Below you can see the diagram of how Direct Workload Connection is working. As you can see, the internal user has the same Public IP (I think everyone knows this one) as the VDA, which means the internal user connects directly to the VDA. The External user has a different Public IP address (non-existing) as the VDA, so this traffic goes through the Gateway Service.

To add the public IP addresses of your on-premises environment and branch offices that have a direct connection to your data center. Sign in to Citrix Cloud and go to the “Network Locations”, there you can see all previously added locations and add a new Network location.

Validate Direct Workload

There are two options to see if Direct Workload is configured correctly and is working

Option 1: Using the Citrix Director
Go to a user’s session and then go to the Details of that session, there you see the Session Details. When the Connected via IP address equals its Endpoint IP address, Directworkload is working. See below two examples:

Option 2: ICA file logging

Navigate to the following registry key by using the registry editor:

32-bit Systems: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\Logging

64-bit Systems: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\Logging

Set the following two string key values:

  1. LogFile=” path to the log file”
  2. LogICAFile=true

Then start a new Citrix Session and open the log file, there you see that it shows the VDA’s IP INTERNAL address. See the image below:

Conclusion

There are a few options to optimize the traffic flow as described before. The Rendezvous Protocol can you use on-premises as in the public cloud, where Direct Workload Connection is only an option when you can connect to your VDA’s directly. Both options help you get a better user experience. Your external users will benefit from the rendezvous protocol, where your internal users will benefit from the Direct Workload Connection. All that matters is that happy users make happy admins.

Do we need to upgrade to Windows Server 2022 for RDS (Citrix)

Updated 18-11-2021:

Citrix released CVAD version 2109 where all the know issues in 2106 are fixed, even Microsoft changed updated their documentation and is supporting Windows Server 2022 for FSLogix. Take a look here for more information regarding FSLogix.

Microsoft released Windows server 2022 (Version 21H2) at the beginning of September 2021. This version of Windows is a so-called Long-Term Servicing Channel (LTSC). An LTSC version gets five years of support and another five years of extended support, where a Semi-Annual Channel only receives two to three years of support. Besides the more extended support, an LTSC version only receives security and regular updates. In other words, during these ten years, there’s no extra functionality added.

What’s in Windows Server 2022 for Remote Desktop Services (RDS)?

Windows Server 2022 adds multiple improvements for “Advanced multi-layered security”, “Hybrid capabilities with Azure” and, “Flexible application platform”. Sadly for RDS, there are no improvements announced, mainly because Microsoft is investing in their Windows 10 and the upcoming Windows 11 multi-user in Azure. As for the previous versions of RDS, we rely on Third Parties that bring added value to keep up with the user’s wishes and demands with the changing market. Third Parties like Citrix and VMware are helping the IT admins to achieve this.

Citrix

Citrix has a Day 1 support for Windows Server 2022 with Citrix Virtual Apps and Desktops (VAD) in version 2106 Current Release (CR). This version has a couple of known issues, which probably they are fixing in the next release. Look here for the know issues! With Citrix Hypervisor (Current version 8.2), no official support is announced for Windows Server 2022. They are probably announcing this in the upcoming cumulative update (CU).

Microsoft

Microsoft isn’t supporting its own Microsoft 365 apps (previously called Office 365) on Windows Server 2022. They only support Microsoft 365 Apps on Windows Server 2016- and 2019-editions. Microsoft is supporting this until October 2025 for these server OS’es. When using Microsoft 365 Apps, it’s not advisable to upgrade to Windows Server 2022 for your RDS or Citrix environment. If you are using Office 2019, they are supporting this on Windows Server 2022.

FSLogix

Besides Citrix VAD and Microsoft 365 Apps, FSlogix is a commonly used user profile solution in RDS and Citrix environments in the EUC market. The latest version of FSlogix 2105 doesn’t officially support Windows Server 2022. When depending on FSlogix, you need to be aware that this component also isn’t supported yet. Previously I stated that FSlogix 2105 isn’t supported on Windows Server 2022, I did read this somewhere but can’t find the document any longer. Looking at the FSlogix Overview site, they now support FSlogix on all Microsoft Supported Operating Systems.

NVIDIA

A GPU is one of the essential components in a Citrix Environment. More and more applications are using graphics and rely on a GPU. NVIDIA is supporting Windows Server 2022 as of version 13.0 of their vGPU software. Version 13.X is just like Windows Server 2022, a Long-Term Support Branch (LTSB). Only the NVIDIA support isn’t that long as from Microsoft. NVIDIA is supporting version 13.X until August 2024. Currently, version 13.0 only supports Windows Server bare-metal installations ore when using virtualized on VMWare ESXi. As Citrix Hypervisor currently isn’t supporting Windows Server 2022, NVIDIA can’t support this.

Conclusion

Looking at RDS, Windows Server 2022 doesn’t have any improvements. Knowing this and the lag of support from Microsoft 365 Apps, there isn’t any reason to currently migrate to this version of the OS. When you need to upgrade your older environment, the current advice is to upgrade to Windows Server 2019. This version of the OS supports all most-used components. When there are any changes in support from most-used components, I’ll update the article.

1. Support until October 2025.
2. Support using version 2106 with some known issues.
3. Using Bare-Metal or VMWare ESX 6.7U3 and up.