Using Zoom with SBC\VDI

Working from home (WFH) requires having a lot of video calls. I noticed a great demand from users that need to attend or organize a video call. The downside is that there are multiple vendors and that a company can’t force everybody only to use one solution. Users receive invitations from multiple organizations, and they all need their own client applications. When using an SBC\VDI based remote workplace, you need to manage all the clients and make sure the video call works great. Luckily, the vendors are working together and making sure that you could have a great experience even when working in a remote session. One of those vendors is Zoom, they have created a client that is created for a VDI deployment. Zoom currently supports Citrix, VMware, and WVD.

How it works

When making a video call the video rendering requires CPU and Memory, when using a multi-session OS this could cause other users to have a degraded performance. The users that are making the video call could notice latency during the call because every moving image has to be rendered and send to the client. To get a better experience Zoom created software that could offload the rendering to the local clients. How is that offloading working?

In most cases, the media plugin will offload the video encoding and decoding and communicates directly to the Zoom cloud, bypassing the VDI infrastructure. All other information is sent over the VDI channel. There are three options:

The three options
The three options
  1. Everything is within the VDI and all the resources are used within the VDI, communication is from the VDi to the Zoom Cloud
    This won’t work with Citrix as described here: https://support.citrix.com/article/CTX270931
  2. Only the Video encoding and decoding are rendered on the client and all communication is going from the Zoom media plugin through the VDI channel to the VDI and from the VDI to the Zoom Cloud.
  3. Most of the communication is going from the Zoom Media Plugin to the Zoom cloud and only the Authentication and window location is going from the Zoom Media Plugin through the VDI channel to the VDI and then connects to the Zoom Cloud.

Installing

Time needed: 15 minutes.

Installing the Zoom VDI Installer in your base image and your client.

  1. Download the latest Zoom VDI Installer client and the corresponding Zoom Media Plugin

    https://support.zoom.us/hc/en-us/articles/360041602711
    You need to download Zoom Media Plugin based on the environment you have: Citrix, VMware, or WVD.

  2. Install the Zoom VDI Installer within your VDI

    This is basically a Next,Next,Finish installation.

  3. Install the Zoom Media Plugin on the Client

    To make sure you don’t receive an error when using Zoom, you need to run the installer as an Administrator.
    Close all Citrix, VMware, or WVD clients before starting the installation.
    Then follow the wizard.

Verifying Zoom installation

After installing the Zoom VDI and Zoom Media Plugin, the testing starts. I made a Zoom call with myself. As I’m not so photogenic, I will spare you these images. To give you a good view of how it’s working. First, I made a Zoom call (without video in my session as this isn’t working for Citrix https://support.citrix.com/article/CTX270931), you can see there is 9.7% CPU usage. This isn’t that much, but when there are more people on a VM and you share the CPU, this could be affecting the user experience of other users.

Zoom call without the plugin enabled

Below you can see that that the Zoom client shows it’s not connected to any plugin and is working as a regular Zoom client.

Zoom session without a working plugin
Zoom without VDI plugin connected

After the first test, I installed the Zoom Media Plugin (for Citrix) and made another Zoom call. This time I was able to use my local Webcam (Laptop integrated) and as you could see below the CPU usage is 0% within the Citrix Session (First Image) and uses 8.4% CPU on the local workstation (Second image).

Zoom Session CPU usage within the Citrix Session
Zoom Session CPU usage within the Citrix Session
Zoom Session CPU usage local workstation
Zoom Session CPU usage local workstation

When looking at the statistics within the Zoom client you now see that the Zoom VDI plugin is Connected. The rendering is now completely offloaded to the Clients workstation and this saves you CPU and Memory on the VM (SBCB\VDI) and gives the user a good user experience during the call.

Zoom Media Plugin Connected
Zoom Media Plugin Connected

Features

When using the Zoom VDI client and the Zoom Media Plugin, you don’t have all the features that are available when using the Full Desktop version of Zoom. As this changes with every new release, I advise you to look at the comparison matrix that Zoom created and hopefully kees updated: https://support.zoom.us/hc/en-us/articles/360031441671-VDI-client-features-comparison

Tips and Tricks

I will update the Tips and Tricks section if new information is available or I needed to solve an issue that could help you as reader.

Registry Settings

Zoom has a list of Registry Settings that can help you troubleshoot or control the client. Here is a list of all available registry keys: https://support.zoom.us/hc/en-us/articles/360032343371

Error Zoom VDI

As mentioned in step 3, if you don’t install the Zoom Plugin on the local device, you could see an error. I only tested with the Citrix Media Plugin and can’t verify if the same happens with VMware or WVD. The error I received is:

Zoom.exe is using NTDLL.dll from an unknown publisher. Are you sure you want to run this software?

Error when Zoom Media Plugin is wrongly installed.
Error when Zoom Media Plugin is wrongly installed.

You could click on Yes as often as you like but that’s not going to work.

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.

CPU vs. GPU

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.

VDI/SBC with GPU

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.

Conclusion

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

From PoC to production during Covid-19

In the beginning of this year I was asked to look at a Citrix Virtual Apps and Desktops (VAD) environment which wasn’t performing great. Customer’s users were constantly complaining about performance and stability. The environment was set up in a mix of outdated software versions, which weren’t always compatible with each other.

I was asked to look into this matter and create a working environment with the current Windows 10 version on their existing hardware. We also offered a temporary server with the latest Nvidia T4 graphics card, to let them experience the enhanced performance with this new kind of graphics card. A Nvidia T4 card is a graphics card that offers GPU’s, so the VDI’s (or RDS) can perform more powerful tasks than integrated graphics adaptors do.

The Proof of Concept (PoC)

I started of with a simple single non High Available (HA) “design”, where we combined as much components to one server as possible. This was done from both a cost and management perspective.

I prefer to work with software I have experience with, so I installed Citrix VAD 7.15 LTSR. Yes, this isn’t the best version to show every new 3D HDX improvement, but it is a very stable version and we were sure we could provide the customer a much better experience than they were having before. We installed all the required applications within their new golden image, without optimizing them or check for Win10 compatibility.

After a week the PoC users were able to test their brand new workspace and informed us constantly how they experienced the new PoC desktop. The results were great. Everyone was enthusiastic and could do their work from anywhere. You can imagine what the experience could be after best-practice deployment and some finetuning.

Covid-19

And then came Covid-19 ☹
Just a few weeks after the PoC the news came that Covid-19 didn’t stay in China and was spreading around the world. Many countries announced (complete) lockdowns and everybody was obliged to stay home. Traditional office workers were in need of a remote workplace. Our customer asked if it was possible to move and upscale the PoC setup (sized for 10 users max) to a production environment suitable for approximately 100 users. We were able to use existing hardware and expanded the PoC to 30 users at first. By doing so we bought some time for our customer to order new hardware for the rest of the users.

Because of the urgency we offered two separate hardware options. Based on the delivery times they decided to order the hardware that could be delivered as soon as possible. But by then, they weren’t the only company that needed extra hardware rapidly. So in the meantime we provided them with rental hardware instead and we were able to give them the extra resources they needed.

The hardware was delivered in batches because of the poor availability and so in just a couple of days we expanded the PoC with an extra 30 users on their own hardware in a production environment with 100 users, at that time on rental hardware.

Production

During the current Covid-19 pandemic, many customers requested changes and extra resources within their current deployments. Our PoC is still in production, the upside of this is that we now know a lot of design changes which we could do better when creating a complete new design and implementation for this customer. Currently we are planning the design and implementation for a new solid and HA Citrix VAD environment.