Today Microsoft is excited to announce that the new VDI solution for Teams on Azure Virtual Desktops/Windows 365 environments is generally available.
As explained in our previous blog, this new architecture brings the Teams’ user experience to a closer alignment between physical and virtual desktops.
By introducing a new media engine (same one used by the Teams native Windows app) that is decoupled from the Remote Desktop client, and always up to date, we can introduce features faster without requiring VDI infrastructure upgrades.
As part of the release activities, we wanted to provide an F.A.Q based on all the interactions we had with customers during the public preview phase, so all IT Admins can benefit from this curated summary of typical questions.
What are the critical new components?
First, an up-to-date new version of Teams (24193.1904.3031.6050 or higher).
Second, an up-to-date version of the Remote Desktop client or Windows App for Windows endpoints, that bundle a component called “the plugin”, a small dll (~230 KB) that terminates a virtual channel and downloads the third and last component, the media engine (called “SlimCore”).
Do we need to deploy the WebRTC-based optimization as a pre-requisite to get the new SlimCore-based optimization?
No. You can deploy the new SlimCore-based optimization directly (in other words, the WebRTC Redirector Service and IsWVDEnvironment regkey are not needed on the RD Host for the new optimization, but you could/should leave them if you have endpoints that don’t support the new optimization).
What are the benefits of the new optimization based on SlimCore?
More features (full list here), performance improvements (lower resource consumption on the endpoint, faster call set up times, higher resolutions, new codecs and more), auto-updates thanks to a decoupled architecture from your VDI environment, and streamlined support for any Teams issue.
Does the plugin installation need admin rights?
No. The plugin is bundled with the Remote Desktop client MSI or the Windows App MSIX, hence you can choose your preferred installation method (per user, or per machine).
So I don’t need to deploy SlimCore on the endpoint?
Correct! This is all handled transparently by the plugin. The plugin will download SlimCore (~23 MB MSIX package) from Microsoft’s public CDN (https://res.cdn.office.net/*) and silently provision and register it for the user. No admin rights or reboots required on the endpoint.
The plugin will keep up to twelve versions of SlimCore, and clean them up after 6 months. Teams will always instruct the plugin to load the exact version of SlimCore that it needs.
Can multiple SlimCore versions co-exist on the same endpoint?
Yes – up to 12 versions. This is intended so we can provide a faster optimization in case users connect to different VDI environments with different Teams versions (e.g. a persistent and a non-persistent virtual desktop). The SlimCore MSIX packages all have different PackageFamilyName, so that is how they can coexist.
Use the PowerShell command ‘Get-AppXPackage *SlimCore*’ to enumerate all the versions available on the endpoint.
How frequently are newer versions of the plugin released?
The plugin (MsTeamsPluginAvd.dll) we use for SlimCore-based optimization is designed to be a simple component (hence its small size, ~ 230KB). When compared to the old WebRTC plugin (MsRdcWebRTCAddIn.dll ~ 17MB) this becomes more evident.
MsTeamsPluginAvd has two main tasks, virtual channel establishment and SlimCore download. It also plays a small role in screensharing. The plugin is backwards and forwards compatible with SlimCore versions. In other words, Microsoft will avoid forcing customers to upgrade the plugin (which means you can stay on a specific RD Client or Windows App version, as long as that is still supported).
Some new features might require a new plugin, but again, we will try to avoid that.
How frequently are newer versions of SlimCore released?
Every time there is a new Teams version, which happens once or twice a month.
Check here for more information.
Can you explain again what is ‘auto-updating’ in this new architecture?
First of all, new Teams will automatically update. The release cadence for new Teams is once or twice a month. (Customers with non-persistent VDI environments probably disable auto-update with this registry key, and in that case Admins need to manually update their golden image).
The plugin is bundled with the Remote Desktop or Windows app client, which can also auto-update, but Microsoft will try to avoid newer plugin versions so we don’t have to ask you to upgrade your Remote Desktop or Windows app client.
Lastly, and most importantly, when Teams is upgraded (either automatically or after a golden image update), it will request a new SlimCore version to the plugin. The plugin will then fetch it from Microsoft’s CDN and provision it on the user’s device silently.
What if I have a locked down environment (like a Thin Client) – can I deploy SlimCore on my own?
While we don’t recommend this, there is a way to provision SlimCore packages ‘manually’ (using SCCM or Intune), just like any other MSIX package.
But beware, this is only recommended for specific scenarios (non-persistent VDI) where the endpoint is locked down, and has no internet connection to Microsoft’s public CDN (where SlimCores are hosted).
In order to do this, you must guarantee that SlimCore packages are deployed ahead of time on the endpoints, before you update Teams on the golden image. Otherwise, a newer version of Teams will require a newer version of SlimCore and if it cannot be loaded, the user will be in fallback mode (a.k.a server-side rendering).
Check here for more details and version matches.
Are there any networking changes expected for the new optimization?
Yes. SlimCore handles both media and signaling, hence you must configure your network to allow IDs 11, 12, 47 and 127. It is critical that you also allow UDP 3478 traffic, as signaling will try to leverage UDP for faster call set up times.
Additionally, now you can also apply DSCP markings / QoS on the different modalities (video, audio and screensharing) from Teams Admin Center.
Why is a Teams restart needed to switch between the old and the new optimizations?
A single restart is required because by default, the first launch experience will be on the old WebRTC-based optimization. Then, in the background, Teams will try to open a virtual channel and if there is a plugin on the user’s device, the next time Teams is restarted it will attempt to use SlimCore (the new architecture).
What about the Administrator? Any changes in supportability?
Numerous improvements have been made. Teams Admin Center can now display full information about the ongoing call made from VDI, and Call Quality Dashboard can be leveraged to create custom reports.
The VM’s Event Viewer is capturing all the error codes that happen on the endpoint, and we are exposing their meaning on this table.
But that is not all – we have more coming soon.
What happens if the user roams between devices that support and don’t support the new optimization yet (e.g. Windows to MAC) ?
Session roaming and reconnections are described here. To prevent the user from ending up in a non-optimized mode, we are rolling out a new ‘restart dialogue’ that will prompt the user to restart the app and get optimized with the old WebRTC-based solution.
Is there a way to disable the new optimization?
By default it is enabled (Org-wide level). You can disable it using this PowerShell policy, and control the rollout by re-enabling it at a user-group level.
When will Mac and Linux endpoints be supported?
Stay tuned for the announcements in the public roadmap.
When will the legacy WebRTC optimization be deprecated?
Microsoft will review the EOS/EOL timelines soon and announcements will be made through Message Center Posts. No new features are planned for WebRTC-based optimization (only security and critical bug fixes).
Source link
No Comment! Be the first one.