LearnMicrosoft Teams › 9 · Mobile & VDI

Teams on VDI

In VDI the pixels live in the datacentre but the voice must not: optimisation offloads media to the physical endpoint, and every VDI-Teams incident starts with one question — is offload actually active?

The architecture in one breath

Unoptimised: the virtual desktop runs Teams; audio/video hairpin between datacentre and endpoint over the display protocol — latency stacked on latency, echo cancellation fighting the remoting stack, server CPU burning per call. Optimised: the Teams UI runs in the VM, but a media engine on the PHYSICAL endpoint (the new VDI plugin architecture — SlimCore-based — succeeding the WebRTC redirection era) handles capture/render/transport: media flows endpoint -> Microsoft directly, exactly like a fat client. The session host never touches RTP.

Platform coverage (AVD/Windows 365, Citrix, Omnissa/VMware) each pair a host-side component with an endpoint-side plugin — version pairing matters: mismatched pairs silently fall back to unoptimised, which 'works' and then melts under load.

Consequences of the split brain

  • Network path = the ENDPOINT'S network (thin client's branch), not the datacentre's — all the network-module rules apply at the user's edge; the datacentre's beautiful egress is irrelevant to media.
  • Devices = endpoint devices via the plugin — headset issues are thin-client local, not VM.
  • Feature matrix: optimised VDI trails the fat client (specific effects, advanced meeting features arrive later or never per platform) — publish the known-gaps list to your service desk or relitigate it weekly.
  • The old fallback modes (audio-only via remoting) are graceful-degradation tools, not targets.

What to watch (proofs)

  • Optimisation state, per session: Teams client > about/version (or the connection info panel) shows media optimised + component versions — "is it green" is the first question of every VDI ticket; teach the desk to read it.
  • Version pairing: host component vs endpoint plugin versions across the estate (your VDI mgmt tooling) — the mismatch report predicts the fallback tickets.
  • The path proof: capture at a thin client during a call — SRTP from the ENDPOINT to Microsoft ranges (offload live) vs display-protocol-only traffic (fallen back).
  • Load truth: session-host CPU during meeting hours before/after optimisation coverage — the graph that justifies the plugin rollout project.

The wire

  • Optimised: endpoint media engine -> Microsoft directly (UI remoted, media local)
  • Fallback: media hairpins through the session host over the display protocol

PowerShell for this concept

  • Get-CsTeamsVdiPolicy The Get-CsTeamsVdiPolicy cmdlet enables you to return infomration about all the Vdi...

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.