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 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 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.


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.


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.


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.

NVIDIA License System (NLS) – General Availability

On the 19th of august, NVIDIA made the new License System (NLS) generally available. The announcing email also mentioned the End-of-Life (EOL) of the current vGPU Software License Server. As of 23th of July 2023, the on-premises NVIDIA License Server is no longer supported. The EOL date of the on-premises License Server is the same as the EOL of the vGPU software release branch 11. That means that as of that date, you can only use the new NVIDIA License System. As an engineer, you need to migrate your customers and their License Server(s) to the new NLS and use the new NLS for new deployments. The requirement for using the new NLS is that the environment needs to use NVIDIA vGPU software release 13.0 or later.

With the new version of the NVIDIA license services, you can choose between two types of license services:

Cloud License Service (CLS)

NVIDIA manages the new CLS License Server, and you don’t need any on-premises components. That means that your vGPU clients connect directly to the NVIDIA Cloud to get their licenses.

The downside is that you need to rely on the NVIDIA uptime and your internet connection, and there is no redundancy at the moment. The upside is that you don’t need to manage a VM and can use these resources (time and hardware) for other needs, and you have a cost reduction.

Delegated License Service (DLS)

The DLS is a virtual appliance.  You need to download the appliance from the NVIDIA license portal, and just like the current License Server, you need to assign licenses to it. The main difference is that this VM doesn’t require a Windows license.
The new DLS Virtual appliance supports the following hypervisors:

  • Citrix Hypervisor 8.2
  • Linux Kernel-based Virtual Machine (KVM) hypervisors with QEMU 2.12.0 (qemu-kvm-2.12.0-64.el8.2.27782638)
  • Microsoft Windows Server with Hyper-V 2019 Datacenter Edition
  • Red Hat Virtualization 4.3
  • VMware vSphere Hypervisor (ESXi) 6.7, 7.0, and 7.0.2


The new License Server has some advantages over the old vGPU License Server.

  1. You don’t need to have a Windows VM.
  2. It doesn’t need the JAVA software, which requires patching and securing.
  3. You don’t need to back-up the CLS.

Overall it saves you time and resources you could spend on other activities, and it gives you a more secure environment. For more information, look at the latest NLS documentation.

The need for a GPU in VDI/SBC environments

There are already many blogs about the pros and cons of using GPUs in VDI and SBC environments. I also would like to point out why I advise the usage of GPUs in these types of environments.


First, let me explain the difference between CPU and GPU. A CPU is designed to handle a few software threads at a time using its few cores and lots of memory cache. A GPU is designed to handle thousands of threads using their hundreds of cores.

In a production situation, the above difference means that when you have an application that wants to use a GPU but there isn’t one available, it will use the CPU instead. The downside of using a CPU is that it’s slower than a GPU and more expensive. A user can notice this when his programs are sluggish and not performing as expected. You can read more about the difference between a CPU and a GPU here.

VDI/SBC without GPU

In the early days, we had Windows 7 or Windows Server 2008R2 without a GPU and that would work perfectly. Users could do their work as if they were working on a local device. The architecture of the OS and most of the applications one was using, didn’t depend on a GPU. If they needed a graphics card and the server had none, Citrix offered a tool called OpenGL Software Accelerator and the VMware alternative was Soft 3D. This would work for some lightweight applications that required a graphics card and get fooled using the software.

In the last couple of years, we see increased usage of GPU accelerated programs like Chrome, Edge, Firefox, Dynamics, Teams, etc. Windows 10 is also more graphics-intensive than it was with Windows 7. A lot of applications already recommend or even require GPUs. They will function without a GPU but to get the best user experience (UX), you definitely should implement GPUs.

Maintaining the very best UX is exactly why I always advise the use of a GPU. I did several VDI projects where they were creating 3D drawings. In such cases implementing GPU is a no-brainer, because the 3D acceleration completely depends on it. You can read about one of those projects here. Those environments are not the ones that I would like to explain.

Looking back at projects starting with Windows Server 2012, users started to use more and more graphic intensive websites. They started consuming more video content like YouTube, online learning platforms, and websites that are more and more requiring GPU. Both Citrix and VMware developed solutions to keep giving the user the best UX without having to install graphics cards also. The downside of these software solutions is that everything is rendered using the CPU. That means you needed a faster (read: more expensive) CPU and when someone was using a graphics-intensive application, other users could start complaining that their system was slow. This all because the CPU couldn’t handle all requests fast enough.


And then came Nvidia, offering virtual GPUs (vGPU), where we could assign multiple VMs to one physical Graphics Card and give a portion of the card, this is called profiles. First, only Citrix supported this with Citrix Hypervisor (f.k.a. XenServer), and then also VMware supported this type of virtual GPUs. Nowadays we can create more VMs on the same physical server because we can assign more VMs to one GPU graphics card.

This all had a positive effect on the return on investment (ROI) for a VDI or SBC environment with GPU cards. Because of the profiles, we need both fewer physical servers and CPUs, resulting in less Rackspace, less maintenance, and fewer investments. Now we can start using the vGPU more often and help users get the best UX with the new and more graphics-intensive applications.

Almost always a GPU

Nowadays we almost always advise customers to buy GPUs for their VDI/SBC environment. We have a couple of reasons why we don’t advise GPUs:

  1. When they have a small number of VMs (≤ 4) and adding them to their already existing backend VMware environment. To use the GPU profiles, VMware requires the use of VMware vSphere Enterprise Plus. When customers don’t already have an Enterprise Plus license, it’s usually too expensive to add GPUs;
  2. That it’s just a temporary environment because they are migrating to local machines or the cloud.
  3. Usage, some customers are using the EUC environment just for some users or only when they have to work in remote offices. When this isn’t a daily situation, we can decide to only use CPU.


Based on the above pros and cons, you definitely need to consider GPUs when upgrading or migrating your VDI/SBC environment.

Upgrading Nvidia firmware

During the last couple off days I needed to update the firmware from the Nvidia Tesla T4 card in our servers. When following the installation steps provided by HPE I ran into some issues, so I decided to create a step by step guide on how to update the firmware.

  1. Download the latest firmware from your vendor
  2. Upload the RPM file to /usr/local/bin using Winscp or your favorite tool
  3. Connect using SSH to the host
    1. Browse to cd /usr/local/bin
    2. unpack the RPM file using the following command: rpm –ivh ./Tesla_T4_90.
      The RPM file name can be different when upgrading a newer version or other Nvidia card.
    3. Go to the folder where the RPM file is extracted for now this is the Tesla_T4_90. folder: cd /usr/local/bin/Tesla_T4_90.
    4. Change the permissions of the file
      chmod +x Tesla_T4_90.
    5. Make sure all nvidia kernel modules are removed
      init 3
      rmmod nvidia
    6. When you get the following error :
      ERROR: Module nvidia is in use
      run the following command:
      service xcp-rrdd-gpumon stop
      and then run:
      rmmod nvidia
    7. Now we can upgrade the firmware using the following command:
      ./Tesla_T4_90. -f
      The SCEXE file name can be different when upgrading a newer version or other Nvidia card.
      Choose -i if you would control the upgrade for every card in the host.
  4. When all the cards are upgraded you need to reboot the host and continue to the next host.

Good luck with upgrading, as you can see it’s easy.