Microsoft Teams audio calling fails with the error: “We ran into a problem – Try again in a few minutes” on Azure Virtual Desktop with Teams Media Optimization

One of the issues I recently encountered during a Azure Virtual Desktop deployment with Teams Media Optimization was where outbound calls from the virtual desktop would display the spinning wheel while constantly playing the dialing audio until the call fails with:

We ran into a problem
Try again in a few minutes

I wasn’t sure if it was the ordering of the software installation or the Remote Desktop Client app and after reinstalling all the components yet still receiving this error, I remembered that the profile cache may be the cause so went ahead and navigated to %appdata%\Microsoft\Teams to delete the files:

Then tried dialing again and this corrected the issue. The issue took a bit if time to resolve so I hope this short blog post will help anyone who may encounter this problem.

Azure Virtual Desktop Teams Media Optimization fails to display local client devices

I’ve configured quite a few Teams Media Optimization with Azure Virtual Desktop as per the following Microsoft documentation in the past:

Use Microsoft Teams on Azure Virtual Desktop
https://learn.microsoft.com/en-us/azure/virtual-desktop/teams-on-avd

The configuration isn’t difficult and I never had any issues until recently when I had to repeat the same for an environment I worked on. After performing all the steps, I noticed that the settings in Teams would either display:

Audio Devices: Custom Setup
Speaker: None
Microphone: None

Which means no devices are redirected or optimized:

Or:

Audio Devices: Custom Setup
Speaker: Remote Audio
Microphone: Remote Audio
Camera: Integrated Camera (Redirected)

Which means redirected audio and video devices were taking place but not optimization.

**Note that redirect works if these RDP settings are configured:

audiocapturemode:i:1 Enable audio capture from the local device and redirection to an audio application in the remote session

audiomode:i:0 Plays sound on the local computer

camerastoredirect:s:* Redirect cameras

After going through all the steps multiple times and not having any luck, I recalled a long time ago when I experienced an issue where if I had logged into Teams on an Azure Virtual Desktop BEFORE configuring Microsoft Teams Media Optimization, the optimization would fail. This generally wasn’t an issue for me as I always configure the optimization before rolling out the desktops but for this instance I had not so I went into the folder %appdata%\Microsoft\Teams to delete all the items and long behold it corrected the issue.

I haven’t encountered this issue as much but this took up quite a bit of my time to troubleshoot so I hope others with this issue will find this post and be able to resolve it quicker.

The versions of the applications I used for this deployment are:

Microsoft Teams: 1.6.00.11166

Remote Desktop WebRTC Redirector Service: 1.33.2302.07001

Microsoft Remote Desktop: 1.2.4337.0 (x64)

Microsoft Visual C++ 2015-2022 Redistributable (x64): 14.36.32532.0

Attempting to join a Windows desktop to a Active Directory Domain Services (AD DS) fails with: "The following error occurred attempting to join the domain contoso.local": The specified network name is no longer available.

One of the projects I’ve been working on was a small Azure Virtual Desktop deployment for resources outside of Canada to securely access a VDI in Azure’s Canada Central region. To provide a “block all traffic and only allow whitelisted domain” solution, I opted to use the new Azure Firewall Basic SKU with Application Rules. Given there wasn’t any ingress traffic originating from the internet for published applications and connectivity to the AVDs were going to be through Microsoft’s managed gateway, I decided to place the Azure Firewall in the same VNet as the virtual desktops and servers. This doesn’t conform to the usual hub and spoke topology and the main reason for this is to avoid VNet to VNet peering costs between the subnets. What I have elected for the security network design was to send all traffic between the subnets within the same VNet through the firewall for visibility and logging so the default of traffic free flowing within the same VNet is not allowed. The following is a diagram of the topology:

The traffic originating from the AVD subnet containing the virtual desktops to the server subnet containing the AD DS servers are protected by the firewall. After placing the required route in the UDR associated to the AVD subnet and configuring the required firewall ports from client to server in the Network rules of the firewall policy:

• UDP Port 88 for Kerberos authentication.
• UDP and TCP Port 135 for the client to domain controller operations and domain controllers to domain controller operations.
• TCP Port 139 and UDP 138 are used for File Replication Service between domain controllers.
• UDP Port 389 for LDAP to handle regular queries from client computers to domain controllers.
• TCP and UDP Port 445 for File Replication Service.
• TCP and UDP Port 464 for Kerberos Password Change.
• TCP Port 3268 and 3269 for Global Catalog from client to domain controller.
• TCP and UDP Port 53 for DNS from domain controller to domain controller and client to the domain controller.

… then proceeding to deploy the desktops with AVD, it would fail to join the desktop to the domain with the error message:

VM has reported a failure when processing extension 'joindomain'. Error message: "Exception(s) occurred while joining Domain contoso.local

Trying to manually join the desktops to the domain will display the following message:

"The following error occurred attempting to join the domain contoso.local": The specified network name is no longer available.

Parsing through the logs of the Azure Firewall did not reveal any Deny activity but I did notice that there wasn’t any return traffic captured. It was then that I found I had forgotten to associate the UDR that would force traffic from the server subnet to the VDI subnet through the firewall.

This meant that any traffic originating from the VDI subnet would be sent through the firewall:

… while any traffic originating from the server subnet to the VDI subnet would just be sent through subnet to subnet within the same VNet. I’m not completely sure why this would be a problem given return traffic should have returned through the firewall and only new traffic from the domain controllers would not.

In any case, I went ahead and updated the server subnet to use the UDR that would route the traffic through the firewall and the domain join operation succeeded. Firewall logs would also began displaying the domain communication traffic to the AVD subnet.

This probably would have been resolved when I completed the configuration but I hope this blog post would help anyone who may encounter a similar issue.