Bug: Zoom VDI + Screen Capture Protection = Blank Zoom

So, this is going to be an interesting post. I don’t know for fact if this is an issue others are facing, it could be self-inflicted. However, all testing doesn’t suggest this and ultimately, I would rather write something and have nobody else experience it than say nothing while others suffer in confusion like we did.

Long story short, the Zoom VDI plugin doesn’t seem to work (as of 5/24/23, VDI 5.14.23547) when going cross OS between the host and the Cloud PC.

Update: Adding some clarity here since there was some confusion with some folks. This may only make sense to those who have read the whole article. 99% of our org is running optimized Zoom via the VDI client/plugin properly setup without an issue. It’s we few who have upgraded to Windows 11 CPCs, and the even fewer of those who did not upgrade their host devices from Win10 that have a problem. And again, those few can setup Windows 11 hosts to test and get things running without an issue – so this is not a simple issue of failure to install X or getting them backwards or a misconfig at the enterprise level.

Update 5/30/23: It appears a root cause has been identified, and I have now tested on Windows 10 CPCs and found the issue is even bigger. Update header towards the end. Zoom support is still engaged.

Update 6/6/23: See update header below.

Update 6/7/23: See update header below.

Update 8/18/23: See update header below.

The Issue:

For some time now my team has been facing a strange issue where a small number of employees (mainly those on our team) are unable to see the inner contents of Zoom windows. Pardon the crappy screen capture, but I think it conveys what I am trying to say just fine.

As you can see, there are two participants in this meeting yet the small box at the top that and large box at the bottom are both grey voids. These should be things like screen shares, name plates, cameras, etc, but they are simply empty.

The other person on this call is not affected by the issue and can thus still see me through my camera, despite me not being able to see them or even my own preview. Audio is not affected.

Why is this happening?

Another engineer had been engaged with Zoom support on this problem to no avail for quite literally months before it eventually landed in my lap to look into.

What I quickly discovered is it’s only occurring where we are going cross-OS. For instance, a Windows 10 host to a Windows 11 Cloud PC. I don’t yet know if the issue also effects a Windows 11 host to a Windows 10 Cloud PC.

We ended up confirming the Win10 to Win11 scenario by taking a multitude of Windows 10 and 11 devices, getting them setup as they should be, and trying to connect to the same few Win11 Cloud PCs from them. We tried personal devices, company devices, etc. Whenever we went Win11 host to Win11 CPC, it worked. Whenever we went Win10 host to WIn11 CPC, it didn’t.

Our last and most interesting test was taking a WIn10 host which was not functioning (at least when trying to connect it to a Win11 CPC), upgrading it to Win11 (in place upgrade, not a scratch install) and ta-da, it started working when connected to the Win11 CPC – no other action needed. No re-install of the VDI agent, nothing. It just worked.

Solutions & Support:

Zoom support is now aware of these findings (as of 5/24/23) and actively looking into them but, given what I heard of the months of stagnation so far, I am not expecting an overnight revelation.

The only solutions I currently know of are to…

1. Use a host device of the same OS as the cloud PC (obviously not convenient).
   
2. UNINSTALL the VDI client from the host device. This will allow the Zoom window to show content such as cameras however, it will be unoptimized. This means video will be delayed, even your own preview video, compared to audio. Audio quality will be worse, and possibly also delayed, and the video resolution will be lower. And, you can’t do things like background effects.
   

I am obviously hoping a more permanent solution is released, likely from Zoom as best I can tell currently, and I will keep this blog updated as that moves forward.

Update 5/30/23 – Root cause and Win10 to Win10:

I believe I have identified the root trigger. This all started when Zoom concluded from logs that something on the host was “blocking the video overlay” and then provided a Windows 11 CPC test unit for us to try one of our hosts on to prove our hosts were the problem. Well, I took my Win10 host which fails on my Win11 CPC and connected to their Win11 CPC and quickly found Zoom works just fine. So, the root cause isn’t coming from our host… but…

For some time we have also been testing the AVD/W365 screen capture protection. This blocks you from doing things like using Snip & Sketch on the host to capture contents in side the CPC. This requires a compliant host device and it’s the host itself that actually detects and blanks the screen, the CPC/connection delivers the instructions to the host to do so.
Screen capture protection in Azure Virtual Desktop – Azure | Microsoft Learn

I mentioned earlier on this was a topic I had inherited recently. Well, I knew this was also something limited to the folks having a problem and thus asked and thought someone had tested turning this off. Apparently not, as I turned it off myself and quickly found that Zoom (including Windows 10 host to Windows 11 Cloud PC) fully functioned.

But wait – there’s more!
I then took a Windows 10 Cloud PC with screen capture protection OFF, verified with a Windows 10 host that Zoom optimization worked just fine, enabled the screen capture protection on the Win10 CPC, and then found that it also broke. I then took a Windows 11 host, connected to that same Windows 10 CPC, and that worked.

So, it seems (as of 5/30/23) that Windows 10 or Windows 11 Cloud PCs with screen capture protection enabled will make Zoom optimization break when combined with a Windows 10 host device, but not when using a Windows 11 host device. Since Zoom support clearly has CPCs at their disposal, I have asked them to configure this policy and confirm the same results.

The really bad news is that this begs the question, is this Zoom’s problem or Microsoft’s problem? – I am sure it will be fun to figure that out.

Update 6/6/23 – Response & recommendation from Zoom

It was a while (a week, and only once prodded) before we heard back from Zoom after relaying the above information in my last update. And it was a response alright.

They opted not to confirm or deny their ability to replicate, despite most definitely having their own test Cloud PCs (they let us onto one after all), and despite that confirmation being the one thing we asked for an update when we followed up with them. The rest of the email seems to indicate they did though, as I have a hard time believing they would make the recommendation they did without replicating it. I am still trying to get a clearer confirmation of this though.

They did confirm that “We do capture the screen for (from?) VDI environment to find the Zoom VDI client window, then overlay the media through the plugin on top of that. If this is being blocked we have no way of seeing this or getting around this function.”

This happily confirms one of my beliefs. To explain, the Zoom plugin on your host machine overlays the video (think camera’s and screenshares) over-top of where the Zoom window is on the RDP session. Teams does the same thing. This is why Teams video windows can sometimes seemingly get knocked off the call window and float around on their own, often moving in sync with the window but misaligned. It’s also why Zoom video feed remains visible when the screen goes blank/black due to a loss in connection. So, Zoom is basically saying that they locate this window in the session by, I guess, visually capturing the screen and looking for it.

They then went on to say, “We are also unsure as to why this works with Windows 11 and (but?) not Windows 10. This would be something on the screen capture side that is either set or designed this way by Microsoft. We can’t see into the screen capture backend to know what it is doing to our app as there is no feedback function for the screen protection that we could find. This is something that you would have to take to Microsoft so they can get the logs needed to find out why the same Zoom app works in one scenario (Win11 host) and not the other (win10 host).”

Any my favorite – “At this point, the recommendation is to not use the screen capture protection app since we do have to capture the VDI window in order to show the media correctly through the plugin.“

So, in other words, Zoom locates the Zoom meeting window for the plugin to overlay on top of by visually searching for it on the host screen. Screen capture protection does just that, and that causes the plugin to be unable to find the window. Zoom has a point in that it works fine in Win11 hosts but not Win10, and that this may thus be on Microsoft’s end to resolve, but I can already guess how that will go.

For now, I am waiting on clearer confirmation from Zoom that they replicated this issue before potentially opening at ticket with Microsoft.

Update 6/7/23 – Replication and Microsoft Ticket

Zoom support has confirmed their ability to replicate the issue in their clean environment. This confirms that Screen Capture Protection when enabled on a Cloud PC (and possibly AVD), and then combined with a Windows 10 host, will cause Zoom’s VDI Plugin to break. The effect happens regardless of Win10/11 on the Cloud PC itself, and it does not occur when the host device is Windows 11.

A Microsoft ticket has been raised and we will see where that goes.

Update 8/18/23 – Movement!

I have a positive update but, it doesn’t start positively.

After calling together a meeting of the Microsoft engineers, we were able to sync up and unfortunately confirm that really nothing has happened on our Microsoft case in the roughly two and a half months it has been open. To our shock/confusion/surprise, nobody had actually replicated the issue. They thought they had in early July, as did we, but they soon realized they hadn’t yet never told us. They didn’t communicate that they needed help, nor that they needed logs. Nobody was 100% sure if our use case was supported and thus if the issue was supportable. Even with us doing the reproduction on the call, nobody was sure how to get the logs that were needed to try and analyze the issue. That quickly made them realize on their own they really needed to be able to internally repro this. All in all, the list of accomplishments on our case read like something two and a half weeks in, not two and a half months.

That said, the right people were on the call, and by cooperating with them we were able to open their eyes to the fact a lot of things were not right with our case. Mainly, the abysmal communication and that apparently, the personnel assigned to us to perform the internal repro were not at all familiar with the products we needed support with. I don’t like to put horror stories online, it’s why I am removing the update info from the 5th, but our engineer didn’t know how to use Zoom on a Windows 365 device at all – let alone do replication of our problem. I won’t give the details of what exactly they were doing as it may give my readers a migraine. Again, luckily the right Microsoft support members were on the call and quickly realized this failure on their own.

Since then in just a few days they have successfully replicated the issue and opened some sort of cooperative case with Zoom themselves. In other words, things are now happening like they should have two months ago.

This sort of experience is by no means a first for me, but I think strangely I have gotten really good at handling this situation. So much so that I plan to write an article on it soon. “How to handle Microsoft Support Cases” – that will be a fun one.

Update 11/20/23 – Resolution!

I am happy to announce that the case is nearing resolution. Long story short, they were able to track down the source of the issue and are planning to patch Win11 21H2 (which was also affected) and Win10 devices come late November 2023. I was given the opportunity to test it myself and was able to confirm it functioned so I have high hopes that this will soon be water under the bridge.

Clarification: This issue was resolved via a Windows update to Windows 10 and Windows 11 21H2 devices November 30th – The official KB, at least for Windows 10, was KB5032278: November 30, 2023—KB5032278 (OS Build 19045.3758) Preview – Microsoft Support

While not straight forward in being related to this issue, I believe the note related to this topic is… “This update addresses an issue that affects protected content. It stops cross-process windows from being created. Because of this update, you can keep using out-of-process hosting for things like WebView2 under protected, top-level windows.”

If you are experiencing a similar issue, it’s likely unrelated or at worst, something has rebroken this and you should refer your engineers to that KB.

Disclaimer

The following is the disclaimer that applies to all scripts, functions, one-liners, setup examples, documentation, etc. This disclaimer supersedes any disclaimer included in any script, function, one-liner, article, post, etc.

You running this script/function or following the setup example(s) means you will not blame the author(s) if this breaks your stuff. This script/function/setup-example is provided AS IS without warranty of any kind. Author(s) disclaim all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall author(s) be held liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the script or documentation. Neither this script/function/example/documentation, nor any part of it other than those parts that are explicitly copied from others, may be republished without author(s) express written permission. Author(s) retain the right to alter this disclaimer at any time. 

It is entirely up to you and/or your business to understand and evaluate the full direct and indirect consequences of using one of these examples or following this documentation.

The latest version of this disclaimer can be found at: https://azuretothemax.net/disclaimer/