by Ray Davis, CTA
Here’s a quick little write-up for Zoom users around Citrix VDI setups who want to stop all connections coming in unless they have the Zoom HDX plugin on the Client. In other words, it prevents unoptimized connections.
I needed a way to stop users from using Zoom if they didn’t have the Zoom HDX Media Plugin installed on their clients from home. Without the Plugin, it uses the VDA resource in an unoptimized fashion. I know you can tune Citrix policies around this, and this may be ok for smaller setups. But in a larger environment, it most certainly impacts each VDA, which dramatically affects the Hypervisor and even causes significant issues if many users are not using the optimized fashion around the intended use case.
Luckily, Zoom had done their homework and made this possible for all of us EUC folks:
https://support.zoom.us/hc/en-us/articles/360032343371-VDI-Client-Registry-Settings
Current testing and results The current versions I am running in the Lab Citrix Environment:
- Zoom Client for VDI 5.4.59208
- Zoom HDX plugin version is 5.4.592.8
- Citrix Virtual Apps 1912.3000
In my testing, I added the HKCU (this can be HKLM as well) Failback mode to 4 on the VDI side, which detects if the Plugin is not installed and denies users from joining a meeting using the traditional way.
I then removed my Zoom HDX plugin from my Client.
Results: it detected I did not have the Plugin and wouldn’t allow me to join.

I added the Plugin back, and then I got the same results. I did some research, and this is a known issue on the version I am using on the VDA side while publishing this blog.

Bug Fix
- The Version that fixed this is 5.5.3
- https://support.zoom.us/hc/en-us/articles/360031768011
- Resolved Issues
- Minor bug fixes
- Resolved an issue that blocked the connection to the VDI plugin for customers configured to use Mode 4 fallback mode.
- April 3, 2021 version 5.5.3
- I installed the 5.5.8 version on the VDI machine, then left the Zoom HDX plugin removed from my Client
Results are Denied, which I expected because I didn’t install it, and I need to make sure I had a deny before I installed the Zoom HDX Client. I then installed the 5.5.8.20606 Zoom HDX media plugin on my Client. At this point, the VDI has the fixed version, and it allowed me to connect.

Now, I downgraded my Plugin from 5.58 to 5.4.592.8 to see if it allowed the new VDI installer to work with an Older Zoom HDX media plugin.
Client Media plugin is now back on the older one we communicated out when deploying Zoom.

Remember 5.58 is on the Citrix VDI at this point.
Results were It allowed me to connect in from the Old Zoom Media Plugin. It’s important because we can update the VDI versions, but the clients are outside your company’s control. I needed to ensure they could still use Video/Audio Optimized and not inconvenience the users to upgrade or get blocked. Ideally, you want them to upgrade, and I am not sure if you can force them to do yet as the VDI version is higher. I was looking for some detection method that would notify them. For example, the Avaya Workplace software will. For now, I have to conduct more research.

“The standard Zoom client in a screen and video sharing session with minimal screen updates, such as a demo of business software, may easily consume two full CPU cores (50 percent of a quad-core VDA). The CPU consumption is even higher if generic drivers are used, so this is why it is recommended using optimized drivers by Zoom or by another provider.”
“The ICA traffic carrying the video and screen sharing data can also exceed 1 Mb/s of bandwidth, which is four times higher that of “normal” consumption (baselined around 250Kb) with a dual monitor setup at 1920 by 1080 resolution. The bandwidth consumption while sharing full-screen high-resolution 1080p video with an optimized driver set is even greater — 3Mb just for the video alone. Generic driver bandwidth consumption may reach 10Mb — another reason to use optimized drivers.”
“A sample of this from a test environment is shown below:” Note: this was a screenshot from a Citrix blog.

“The participant in the same screen and video sharing meeting, who is using Zoom VDI, consumes a small fraction of the compute (15 percent of the overall CPU) and network (100Kb) resource utilization — a quarter of the CPU and a tenth of the network bandwidth as compared to the desktop client. Please note, these numbers may be affected by the type and configuration of the underlying host CPU.”

Sources
https://support.zoom.us/hc/en-us/articles/360031768011
My preferred rollout is to apply WEM policy to the group or domain users, and it depends on the setup in your environment. You can roll this out, what best suits you.
WEM Registry “Action.”


Go to the assignment and Select the Registry action, Then apply it to how you use it in your environment. I always do “true” for me in situations like this.

WEM applied it on the next reboot, or you can refresh them from the console here.
As you can see here when you try to join a meeting and don’t have the Zoom HDX plugin, each user receives this message.

Note: This doesn’t apply to the Web version of Zoom, meaning a user running it from Edge. The reason why is, reg keys take effect when the VDI Zoom installer is present. Now in my testing, it’s almost like Teams. If the Client is detected, it will open it up with the location software that the VDA currently has installed. But if the Client isn’t seen or noticed, I would assume it will hammer the VDA resources based on other experience in web audio/video software in CVAD. I suppose Content redirection can come to the rescue here as a second option. For now, it’s something I would need to test and hammer out.
I hope this has been informative.
Until next time 😊