Remote Display Analyzer 2205 released

Hi all,

Happy to announce that a new version of Remote Display Analyzer (RDA) has been released: RDA version 2205.

What’s new in Remote Display Analyzer 2205:

  • Remote Display Analyzer now supports Windows 365
  • Support for Nutanix Frame has been added
  • Citrix Rendezvous 2 detection has been added
  • Support has been added for all the latest Microsoft, VMware and Citrix protocol versions
  • You can now start Remote Display Analyzer in minimized mode with a parameter (for all parameters click on the about (i) button at the top of the RDA window)
  • Various bug fixes and improvements

Thanks for all the community feedback received. Version 2205 is now available on the website.

Remote Display Analyzer 2106 released

Hi all,

Happy to announce that a new version of Remote Display Analyzer (RDA) has been released: RDA version 2106.

What’s new in Remote Display Analyzer version 2106:

  • A new Teams Offloading status has been added for Microsoft AVD, Citrix & VMware

Teams Citrix

  • Support for Microsoft Azure Virtual Desktop (AVD) RDP Shortpath

AVD Shortpath

  • A new Citrix Build-to-Lossless Quality Slider has been added


  • Added GUI ability to turn on/off NVIDIA GPU monitoring


  • RDA now supports session disconnect / reconnect, monitoring now continues if session is reconnected
  • A Microsoft Max FPS Policy check for server\multi session OS has been added
  • Fixed NVIDIA license detection issue with server\multi session OS
  • Support for all the latest Microsoft, Citrix and VMware versions
  • Various fixes and improvements

You can check which RDA build you are using by clicking on the about (i) button at the top of the RDA window. You will also find the possible parameters there.
Thanks for all the community feedback received. The 2106 version is now available on the website.

Remote Display Analyzer 2007 released

Hi all,

Happy to announce that a new version of Remote Display Analyzer (RDA) has been released: RDA version 2007.

What’s new in Remote Display Analyzer version 2007:

  • RDS GPU policy detection, reminder to configure this setting and easily verify if GPU is leveraged for RDS workloads

  • Multi language OS support for RDS\WVD
  • Enhanced support for Citrix EDT with MTU size detection, MTU discovery detection and available EDT bandwidth detection

  • The Receiver client version is now detected and displayed next to the detected VDA version
  • Citrix Glyph detection support
  • Citrix build to lossless configuration option has been added

  • Support for the latest Windows 10 Builds
  • Support for the latest Citrix VDA (2006) version
  • Support for the latest VMware Horizon (7.12) version
  • Various Fixes and improvements

You can check which RDA build you are using by clicking on the about (i) button at the top of the RDA window. You will also find the possible parameters there.
Thanks for all the community feedback received. The 2007 version is now available on the website.

Remote Display Analyzer 1911 released

Hi all,

Happy to announce that a new version of Remote Display Analyzer (RDA) has been released: RDA version 1911.

What’s new in Remote Display Analyzer version 1911:

  • RDA now supports the latest Windows 10 builds for both RDS and WVD deployments
  • Support for the latest Windows Virtual Desktop (WVD) Infrastructure agent

  • Support for the latest Citrix VDA (1909) version and latest HDX updates
  • RDA will now also show you in real-time if hardware encode is being used. This is handy when you run workloads and want to verify if the video codec is leveraging hardware encoding. See screenshot below:

  • Support for the latest VMware Horizon (7.10) version and latest Blast updates
  • VMware Blast codec switching and the new Blast codec has been integrated (and can be changed on the fly):

  • Integration with click-to-photon: Click-to-photon uses a small device that can measure response times in remote display environments. You can find more information about the click-to-photon device on the GitHub page of Magnar Johnsen. The click-to-photon device is connected from the endpoint to the remote session using comport redirection. The tool running in the remote session generates screen updates and the device at the endpoint calculates the time between the remote screen update and the endpoint device receiving the update. This statistics are reported back in Remote Display Analyzer.

  • Last but not least: RDA build 1911 contains overall improvements and bug fixes

You can check which RDA build you are using by clicking on the about (i) button at the top of the RDA window. You will also find the possible parameters there.
Thanks for all the community feedback received. The 1911 version is now available on the website.

Key considerations when designing your Windows 10 Virtual Desktop solution

Key considerations when designing your Windows 10 Virtual Desktop solution

Together with TeamRGE co-member Ryan Ververs-Bijkerk we did a short presentation at E2Evc about the performance impact of different components you will find in every Windows 10 Virtual Desktop solution. Ryan used to work for LoginVSI and is really good at performing this kind of benchmarks, you can find some of them here. We shared some benchmark results together with some key designing considerations. Because time in a presentation is always limited, this blogpost dives a bit deeper into the designing considerations around the following 5 topics:

  • Windows 10 build
  • Office build
  • Application deployment
  • Remote display protocol and (v)GPU
  • Antivirus

Please note that one of the assumptions in this blog post is that you are leveraging Windows 10 Enterprise edition.

Some design considerations also applies to other Windows 10 deployment types, so this blog post might also be worth reading when you are not designing a Windows 10 Virtual Desktop solution.

Windows 10 build

Deciding which Windows 10 build you are going to pick is one of the first design choices you are going to make. Basically you have the following 2 options:

1: Windows 10 LTSC (Long Time Servicing Channel)

This separate build of Windows 10 (also known as LTSB) is released by Microsoft for special use cases. Think of locked down and general purpose PC’s you will find for example in factories or in medical peripherals. For this use cases you might not want to leverage new features, but only stay current on security updates. A new LTSB build is released every 2 to 3 years and security updates are supported for 10 years after the release.

Please consider the following when choosing this Windows 10 build for your Virtual Desktop solution:

  • There is no Edge browser
  • There are missing features like no built-in UWP applications which your users might expect
  • You need to re-install your image when a new Windows 10 LTSB build has been released to get new features or to extend support
  • You only have to optimize your image once
2: Windows 10 SAC (Semi-Annual Channel)

This is the primary Windows 10 build which receives new features twice a year. One release around March and one around September, you can recognize the release by looking at its name, the first 2 digits are the year, the second 2 digits the month. For example the 1803 is the 2018 March release and 1809 is the 2018 September release. This may sound very obvious, but I often speak people who didn’t know this. Important to take into account is the servicing period for each release: The March release will be serviced for 18 months and the September release for 30 months. As you can see on the below print screen (source: Microsoft).

Please consider the following when choosing this Windows 10 built for your Virtual Desktop solution:

  • It includes all Windows 10 features and builtin apps
  • You don’t have to re-install your image to get new features or to extend support, you can instead just update the same image
  • Recommended is to use the September release because of its longer servicing period
  • While you can defer updates by for example using Windows Update for Business, eventually you have to go with the release waves and stay current
  • You will need to check your image optimization after each release, there might be new services or scheduled tasks that could impact your performance and server density. This was clearly noticeable on the LoginVSI benchmark across the Windows 10 builds (without optimization)

Office build

Like the Windows 10 build, you also have 2 options when it comes down to the Office build you are going to deploy in your Windows 10 Virtual Desktop solution:

1: Office365 ProPlus

The version of Office that comes with the Office365 subscription and can be downloaded and installed locally, this version is installed by a click-to-run method, which basically is a container based installation similar to App-V. This Office version is also based on a Semi-Annual update Channel (SAC), but can also be configured to receive monthly updates. The latter might not be very practical in a Virtual Desktop solution.

2: Office Stand-Alone (also known as perpetual Office)

This is the on-premises variant of Office like we used pre-cloud era. You know this Office builds by the names: Office 2013, Office 2016 and now Office 2019 has also been released. This Office build is not meant to connect to cloud services, but is intended for restricted (offline) use cases or if you have no Office365 license of course.

Deciding on which Office build you should pick depends on:

  • Licensing (which license type you are using or bound to use)
  • If you use Office365 or not
  • Application compatibility and support (add-ins, macro’s, templates, etc)

Besides above please consider and note the following when deciding the Office build for your Virtual Desktop solution:

  • When you decided to go for Windows 10 LTSC (the LTSB build), also use the Office Stand-Alone (Perpetual) build. Microsoft will stop supporting (even block) Office365 ProPlus on their Long Time Servicing Channel builds (same goes for Server 2019)
  • When you decided to go for Windows 10 SAC, you can use both Office365 ProPlus or the Office Perpetual build. You will primarily make this decision based on the current license type but also don’t forget to investigate the application landscape you need to support on your Virtual Desktop solution

The LoginVSI benchmark included Office 2013, 2016 and 2019. The results showed that Office 2016 scored better than 2013 but also better than 2019. The latter had a noticeable higher impact and it needs to be deeper investigated to check what the exact reason for this higher impact was.

Application deployment

When you are at the point of choosing a way to deploy your applications you basically have 3 options:

1: Leverage traditional application installation methods

In this option you deploy applications with MSI’s, scripts, etc. Be aware that central deployment and life cycle management can be hard to manage and when you remove applications there is often still footprint (files and registry) of the application which pollutes your image over time. Central deployment tools doesn’t solve this issue and are often not designed for Virtual Desktop solutions.

2: Leverage App-V

As you might know the App-V client is built-in Windows 10 and ready to use. You only have to enable it. App-V has a lot of great features for both VDI and non-VDI scenarios. For VDI the Shared Content Store mode is a really handy feature in combination with non-persistent images. Consider using App-V Scheduler for real-time insight, control and advanced cache management for your Virtual Desktop solution. This will make your life a lot easier. By the way App-V Scheduler is not limited to VDI and also supports RDS and Fat-client\Laptop Windows 10 deployments. App-V will be supported for a very long time, you maybe don’t hear much about it because it’s now part of the operating system and Microsoft doesn’t need to sell it as additional product any more.

3: Leverage MSIX

This application format is based on the UWP framework (also previous known as AppX format). This makes it possible to deploy applications through, for example, the Windows Store. You might want to consider if this matches your deployment strategy and if it makes sense for your VDI environment. There are similarities between App-V and MSIX, like they both run the application isolated from the OS inside a container. There will be even a way to easily convert the file format. MSIX is quite new and lacks real-time deployment and management features, good to know is that App-V Scheduler already started building support for MSIX in the product to support real-time control and management features also for MSIX. You are already a step ahead if you are managing your applications with App-V.

The LoginVSI benchmark showed that App-V and MSIX have similar application start times. This was tested with a simple PDF reader. The traditional installed instance had a lower start time, but of course that’s because there is no isolation layer that isolates the application from the OS. Also note we are talking milliseconds here and this might not even impact the perceived user experience.

Remote display protocol and (v)GPU

A Windows 10 Virtual Desktop workspace is highly secure because all information stays in the cloud or datacenter and only screen updates are sent to the client. One of the key success factors of your Virtual Desktop workspace is the configuration of your remote graphics stack. The remoting protocols from all major vendors matured over time to the point they are all very suitable for all kinds of general uses cases.

Please consider the following when designing the remote graphics stack for your Windows 10 Virtual Desktop solution:

  • Consider to apply (v)GPU power to your VDI machines, besides your applications the remoting protocol can also benefit from this. But:
  • Investigate if a (v)GPU makes sense for your workload type and if it’s really worth the investment. LoginVSI benchmark results showed us that the CPU reduction when adding a (v)GPU can be minimal for general workload types like task workers and knowledge workers. This benchmark included the latest Office versions, scrolling through data and playing a video through internet explorer
  • Don’t primarily size your VDI workspace based on (v)GPU profiles, don’t forget that a decent CPU and enough Memory is just as important. A good example are applications like AutoCAD and Revit which relies a lot on CPU also when you have a (v)GPU in place
  • Take note of the recommended memory size for (v)GPU’s: Use at least 1GB profiles for Windows 10. If you are designing your environment for heavy 3D workloads also look at the recommended GPU specs for the applications you need to support
  • Use REX Analytics to capture and analyze the perceived end user experience
  • Use Remote Display Analyzer to analyze, configure and understand your remote display protocol behavior and to verify your (v)GPU implementation


It goes without saying that antivirus and anti malware is an important security aspect of your Windows 10 deployment. Whether you use a virtual desktop or not, it’s important to understand the impact of your antivirus solution.
Please consider the following when designing  your Windows 10 Virtual Desktop solution:

  • Apply best practices and optimizations like: file exclusions, pre-scans, scheduled scans & the definition update interval. Especially for state-less VDI this is a very important part to invest time in
  • Consider to analyze the workspace performance before and after the antivirus solution has been implemented\enabled. In this way you know if it has an impact on your application performance or not. The pilot phase might be a good moment to verify this
  • Consider leveraging Windows Defender, it’s already build in Windows 10 and it scores really well in numerous independent virus and malware detection tests (score of 99,5%). The LoginVSI benchmark showed an performance impact when not doing any optimization at all in Defender, so please pay attention for the optimizations part (see bullet 1)
The end

Thanks for reading, hopefully this design considerations are helpful for you!

Remote Display Analyzer 2.0 released

Hi all,

I want to begin with a big thank you for all the positive feedback about Remote Display Analyzer (RDA) and also a very big thanks to the members in the sponsor program, this really helps to drive RDA forward and to help balance the amount of time spend in this project by giving something back to the family. So thank you very much for becoming a sponsor!

If you are new to Remote Display Analyzer (RDA), this tool will help you understand your remote display configuration and it’s behavior, it will only show you relevant information and help you decide which setting is the best for your specific use case. It’s also very handy for troubleshooting remote display configurations. RDA is just a portable executable without any installation needed, just run it in your remote session and you will get all relevant statistics and settings right away.

There is a lot of new functionality in RDA 2.0, both under the hood as on the outside. I don’t want to make this a long article so I will just give you a short summary of the new features together with some print screens.

What’s new in version 2.0

  • Support for VMware Blast and PCoIP with also the possibility to change settings on the fly (please note that support for Blast and PCoIP is experimental in this release and not yet tested on different OS and VMware View versions)
  • GPU addon for all protocols: This addon will show basic GPU information and when Nvidia is detected RDA will show GPU usage and (v)GPU information
  • Support for the latest Citrix HDX features like H.265, also the RTT counter has been added and RDA will show you the YUV mode for the active video codec
  • RDA is now multi threaded which means that settings and real-time counters are retrieved on different threads making the tool more snappy and more real-time
  • Counter that indicates the run time of RDA with the option to reset the counter and the total statistics collected during  a specific run time. This is handy for analyzing and comparing workloads
  • Print screen option to easily generate a print screen of the RDA window
  • Multiple improvements for RDP & new statistics information
  • Transparent mode, this option makes the RDA window transparent as you can see in the below print screen

Below you will find some print screens of RDA 2.0

RDA running in transparent mode

RDA support for VMware

GPU addon (available for all protocols) and extended support for HDX

Remote Display Analyzer 2.0 is now available for free on the website where you can also find more information about the sponsor program. Existing sponsors should have received an automatic e-mail about this new release. If you didn’t receive the mail please send an e-mail to support at Thanks again for your support!

Using ThreadLocker to control runaway applications

threadlockerLately I was troubleshooting some performance issues in a XenApp 6.5 environment, the customer was observing 2 issues 1: degraded performance in user sessions and 2: scalability problems.  The root cause of this issues was fairly easy to detect when looking at the performance history of the XenApp servers :  A (cr)application was hitting the CPU constantly which causes CPU spikes and overall performance degradation. The environment wasn’t using any form of CPU management other than the default CPU Dynamic Fair Share Scheduling (DFSS) feature in 2008 R2. While DFSS does a great job in equally distributing CPU resources amongst user sessions, the problem with this application is that it’s running away in every user session resulting in overall performance degradation of other applications and lower scalability of the XenApp farm.

While the software vendor is looking at the issue (I will not call the vendor by name because I don’t want to “name and shame”) a community tool developed by Andrew Morgan named ThreadLocker came to mind. ThreadLocker is a tool that can change the CPU affinity and priority of processes on the fly.

In this blog post I will show you how ThreadLocker is helping to improve the overall performance and scalability by changing the CPU affinity of the process that causes the CPU spikes on the fly. Beneath is a snapshot of the CPU usage before ThreadLocker was running, this spikes are caused by the application running in different user sessions.


The task list reveals the application running away with the CPU resources :


So I installed ThreadLocker and configured the affinity of the process to CPU core 0 and 1, I didn’t changed the priority because this caused the application to hang completely  :


ThreadLocker is very light weight and runs as a background service so it does its job in every user session, nothing to configure at a per user basis. After ThreadLocker is running it changes the affinity of the process to CPU core 0 and 1 at a custom interval  :


After ThreadLocker is active notice CPU core 2 and 3 on the right when the users start using the application :


ThreadLocker will also write its activity in the event logs when the verbose logging option is switched on, in this way you can check how often ThreadLocker switches the affinity.

Conclusion :

In this blog post I showed you a good use case for ThreadLocker, with this tool you can tie processes to certain CPU cores to free others. In this way the run away application cannot consume all CPU resources on the XenApp servers so other applications have always free CPU resources to use. Please note that in this use case it’s not a permanent solution for this issue, by binding the process to less CPU cores the application itself has less resources to consume and will perform slower, but that weight is much lower than the performance and scalability impact in the whole environment. We will use ThreadLocker here till the software vendor has fixed the issue and ThreadLocker will be in my Toolbox when I come around this kind of situation again.

You can download and read more about ThreadLocker here.

Please note that the information in this blog is provided as is without warranty of any kind.