Teams showing blank boxes for shared content and camera images in meetings

Starting about 7/29/2024, Teams in AVD was showing blank boxes instead of camera video and shared content in meetings of more than 2 people. I think the cause of this was Microsoft's fix for Issue ID: TM808152 Users were unable to use the application window sharing feature within Microsoft Teams meetings on AVD and Windows 365. Microsoft says: Impact is limited to users accessing Microsoft Teams via AVD and Windows 365 while utilizing WebRTC based optimization. We are in East US. 

I tested running Teams with the Remote Desktop Services WebRTC Redirector service stopped, and that did fix the issue, but CPU usage was so much higher it's not a practical solution. 

This is a workaround for being able to see shared content: Go to Together Mode, then select Focus On Content. So far, that has made the shared content visible, although you lose the video feeds from participants. If you want to see faces, Together Mode without Focus on Content works. 

If you're having this issue, please open a ticket in Microsoft 365, and reference Issue ID: TM808152. 

This is from the Microsoft Issue ID: 

Root cause

We've identified an issue preventing the Teams application window sharing feature from functioning as intended after a user attempts to initiate an application window sharing session on AVD or Windows 365.

 

 

Current status

Aug 1, 2024, 11:43 AM EDT

We're performing the final validation checks and expect this to fully complete by tomorrow.

Next update by:

Friday, August 2, 2024 at 12:00 PM EDT

 

 

History of updates

Jul 29, 2024, 11:40 AM EDT

The long-term fix has nearly completed deployment and we continue to perform the final validation processes.

Jul 23, 2024, 11:43 AM EDT

We've completed a period of internal testing to verify the long-term fix provides the expected relief from the underlying root cause. We're now deploying the fix to the affected infrastructure and we'll provide further updates as this progresses.

Jul 22, 2024, 11:55 AM EDT

We've completed the development of the long-term fix to resolve the underlying root cause. We're now conducting internal testing to ensure impact is fully remediated before we begin the deployment to push the fix to the affected infrastructure.

Jul 15, 2024, 11:57 AM EDT

We're making significant progress developing the long-term fix and this work is nearing completion. Once the development completes, we'll begin a period of internal testing to ensure impact is fully resolved before we deploy the fix to the affected infrastructure.

Jul 8, 2024, 11:56 AM EDT

We're continuing to develop the long-term fix to resolve the underlying root cause. Once complete, we'll conduct a period of internal testing to ensure the issue is fully remediated before we begin deploying the fix to the affected infrastructure.

Jul 3, 2024, 5:34 PM EDT

We've identified a configuration issue which is preventing users from using the application window sharing feature during a Microsoft Teams meeting. We're developing a fix to provide long-term relief and will provide more updates as they become available.

0

Comments (15 comments)

Avatar
Peter Yasuda

Just received this response from Microsoft: 

I would like to inform you that the issue can be because of the Ongoing Service incident and the next update is tomorrow and request you to please wait till tomorrow for another update and then we can check the behavior.

If the issue still persist then we can collect the logs and include the Product team on this case.

Maybe this will be fixed before anyone else notices. 

0
Avatar
Dylan Cote
(Edited )

Incase anyone else has this issue as the "fix" from Microsoft did not make a change for us - we found that the "Remote Desktop Services WebRTC Redirector Service" was updated July 29th

We downgraded to the March 2024 version https://learn.microsoft.com/en-us/azure/virtual-desktop/whats-new-webrtc and now The Teams camera feed is working again as expected.

For context, we had the problem of more than 1 Camera feed showing blank in the new teams in Windows 10 Multisession AVD. We utilize the NerdIO-provided script to install the New Teams upon VM Creation. This script also installs the latest WebRTC Redirector, which is where the problem was so I simply added the March 2024 URL in place of the latest URL that is in that script and all was well again.

3
Avatar
Peter Yasuda

Dylan Cote thank you! That looks like the cause; I was thrown off by Microsoft making back end changes the same date, 7/29/2024. I'm going to test the downgrade and I'll report back. 

Did you uninstall the 7/29 version before installing the 3/25 version? I'm also looking at modifying the Nerdio Install Microsoft Teams (New) Scripted Action, which we also use run regularly, and I noticed it is trying to uninstall a very old version of WebRTC. It's 1.0.2006.11001 from 7/28/2020, IdentifyingNumber {FB41EDB3-4138-4240-AC09-B5A184E8F8E4}. The latest version, 1.54.2407.26001, is {9908EDC6-F29E-417E-A88A-90C54EC2C10E}. 

I'm not sure who to contact about getting the SA corrected. Maybe I'll make a new post about that. 

0
Avatar
Dylan Cote

Peter Yasuda I did uninstall the 7/29 on a live host (which closes Teams for everyone on that host) and then installed the 3/25 to confirm it worked. I found the same actually - thankfully I believe it installs it over the version or my image just doesn't have WebRTC on it to be uninstalled during the host creation..

I can confirm I have another firm on Windows11 with this same issue so it doesn't seem to be isolated to Windows 10 for us

Either way I am glad I was able to help 

0
Avatar
Dave Stephenson

Thanks, Peter Yasuda and Dylan Cote for your great work and testing on this!

Our Sales Engineering Team at Nerdio was able to throw together a quick scripted action that helps with this issue which you can download from our GitHub repo.

Alternatively, you can clone/modify our existing scripted action by doing the following:

  1. Open Windows Scripted Actions (at the MSP-Level)
  2. Search for Teams
  3. Click the drop-down for Install Microsoft Teams (New) and choose Clone
  4. Rename the Scripted Action
  5. **OPTIONAL**
    Modify the Description
  6. Scroll to the # grab MSI installer for WebRTC section
  7. Add the following line to the scripted action below the existing $dlink2 variable
  8. Click Clone

From there, you can assign/deploy that scripted action.
Once Microsoft fixes the bug, you can go back to using the Install Microsoft Teams (New) scripted action.

0
Avatar
Peter Yasuda

Hi Dylan Cote, was the Microsoft "fix" to reinstall the latest WebRTC? That's what they suggested, and it may have worked on my test host, but I had to uninstall WebRTC and then install. I say it may have because a test meeting was good, but I was signed in as an admin on console, and somewhere along the way I broke Teams (permissions? the icon reverted to generic 3 squares, tho it showed installed), and the Install Microsoft Teams (new) SA didn't fix it, so I wound up reimaging, uninstalling WebRTC, then installing it with the Install Microsoft Teams (new) SA. That did not break Teams, and the logs showed WebRTC was installed, not reconfigured, as they show when it is not uninstalled first, so I have the SAs scheduled to run on our internal production hosts tonight. If that doesn't resolve the issue, I'll repeat, only with the previous version of WebRTC. 

At some point, I did try installing the older WebRTC over the current version, and that failed. 

Microsoft did say the logs they collected show the problem is with WebRTC. Which we knew, but good to know they believe it too. 

Dave Stephenson thanks for the quick work the SA! I have some concerns though: 

The WebRTC uninstall logic won't work because the IdentifyingNumber in the script, {FB41EDB3-4138-4240-AC09-B5A184E8F8E4}, is out of date. The current one is {9908EDC6-F29E-417E-A88A-90C54EC2C10E}

PS C:\> get-wmiobject Win32_Product | Where-Object Name -like "*webrtc*"                                               
IdentifyingNumber : {9908EDC6-F29E-417E-A88A-90C54EC2C10E}                                                            
Name              : Remote Desktop WebRTC Redirector Service                                                          
Vendor            : Microsoft Corporation                                                                             
Version           : 1.54.2407.26001                                                                                   
Caption           : Remote Desktop WebRTC Redirector Service                        

I don't know how often that changes. I tried to get fancy and use something like $webRTC.IdentifyingNumber in a script, but my skillz were not up to the task. Might go back to it later; maybe I need $($webRTC).IdentifyingNumber

Also, I don't know about the Per-Machine teams uninstall logic. I don't see that identifying number; in fact, I don't see Teams at all in Win32_Product. Is that because it's installed with teamsbootstrapper.exe, and not an MSI? Or is the logic there to remove a specific old version of Teams? This returns nothing for me: 

PS C:\> get-wmiobject Win32_Product | Where-Object Name -like "*teams*"  

Thanks for all the help!

0
Avatar
Dave Stephenson

Great catches, Peter.

You were pretty close on the logic for the webrtc variable.
When I changed it to the code below, it worked for me.

As far as New Teams goes, you're correct in the fact that it isn't an MSI, but reports as an AppX Package.
I was able to make sure I capture those versions being installed by using this code:

I went ahead and published a new version of the script to github.
If/when you have time, could you try the new script and see if it's working correctly in your environment too?

1
Avatar
Erik

Echo here:

https://nmmhelp.getnerdio.com/hc/en-us/community/posts/28903009466253-new-Teams-Group-sharing-on-AVD?page=1#community_comment_29269184845837

 

I attempted but it is not working, still showing black rectangle for camera and screen share.

0
Avatar
Peter Yasuda

Dave Stephenson I will try the updated script, probably tonight. Running it on our test host now. 

I really don't understand AppX packages. I did some testing on our internal production hosts. 3 have both MSTeams directories: 

Directory: C:\Program Files\WindowsApps
Mode                 LastWriteTime         Length Name                                                                
----                 -------------         ------ ----                                                                
d-----         8/14/2024   1:17 PM                MSTeams_24180.205.2980.1757_x64__8wekyb3d8bbwe                      
d-----         8/14/2024   3:30 PM                MSTeams_24193.1805.3040.8975_x64__8wekyb3d8bbwe

1 only has the newer version. 

I ran Get-AppXPackage through Kaseya LiveView PowerShell, because it runs as SYSTEM

Get-AppxPackage | Where-Object { $_.Name -like "*Teams*" }

Of the 3 hosts with both directories, only 1 showed Teams, and it was the older version. The other 2 returned no result. 

The host with a single MSTeams directory also returned no result. 

I ran Get-AppXPackage locally on the host I am on, under my (non-admin) credentials, and it returned the older version of Teams. The strange bit was I ran it again later, and it returned the newer version of Teams. And I saw the timestamp of MSTeams_24193.1805.3040.8975_x64__8wekyb3d8bbwe updated. Running as SYSTEM, there is still no result. 

The Scripted Actions run with SYSTEM credentials, so I am not sure whether Remove-AppXPackage will work, but I don't think it matters, because New Teams seems to update itself whenever it wants once it is installed. Is there a reason to run the Update Teams Scripted Action frequently, as there was with Classic Teams? I think we ran into the bug early because we're running it weekly, and I suspect it was not reported much because most people are not updating WebRTC very often. 

I'll report back with results from the new script. 

 

0
Avatar
Peter Yasuda

Hi Dave Stephenson, overnight I ran the script you provided on our internal production host pool (Windows 11 23H2 multi-session). This morning I was in a 6 person Teams meeting, and camera views and shared content were visible. The script successfully downgraded the Remote Desktop WebRTC Redirector Service to version 1.50.240.29001, the 3/25/2024 release. I have not received feedback from people on other hosts yet, but it looks promising. Thank you!

0
Avatar
Dave Stephenson

That's great news, Peter Yasuda!
Hopefully people on your other hosts have the same experience.🙂

Erik, do you have a case with Nerdio support on this?
If so, they should be able to escalate the issue to our Escalation team for them to look into the issue even though it's a Microsoft problem and not a Nerdio problem.

0
Avatar
Erik

I confirmed I have the right revision of the WebRTC redirector but still no incoming video. Incoming screen share seems to work?

It seems on and off. I tested multiple calls and it worked some of the time but not all.

 

 

0
Avatar
Dave Stephenson

That is odd behavior.
Can you open a case with our Nerdio Support team?
Even though it's a Microsoft problem (something between Teams, Windows, and the WebRTC connector not working correctly) and not a Nerdio problem, our Escalation Team should be able to help you dig into the issue.

0
Avatar
Dylan Cote

FYI Looks like Microsoft released a fixed WebRTC Redirector: https://learn.microsoft.com/en-us/azure/virtual-desktop/whats-new-webrtc

I have tested this on only one Win11 Single session machine so far and it fixed the issue

Updates for version 1.54.2408.19001

Published: August 21, 2024

Download: MSI Installer

In this release, we made the following changes:

  • Fixed an issue where video streams may sometimes not appear.
1
Avatar
Dave Stephenson

Thanks for coming back and sharing the link to the updated WebRTC version, Dylan Cote!

We uploaded an updated version of the scripted action to the NMM-SE repo that makes it even easier to switch from the March release of the WebRTC to the latest.


0

Please sign in to leave a comment.