The Manila pilot is failing and the CIO wants more bandwidth
Contoso is piloting Teams for 400 users in Manila ahead of a 12,000-seat rollout. Pilot feedback is uniformly bad: screen sharing freezes, audio drops mid-call, and file uploads time out. The network team reports a 40 Mbps symmetric internet circuit, all client traffic backhauled over MPLS to the Chicago datacenter proxy for URL inspection, and no decryption of UDP. Measured Manila-to-Chicago round trip is 210 ms with 45 ms jitter and 2.1% packet loss; Manila to the nearest Microsoft 365 edge is 32 ms with 8 ms jitter and 0.2% loss. Remote workers in Japan connect through a full-tunnel VPN that also routes Teams traffic to Chicago. The CIO wants a decision this week on whether to buy an 80 Mbps circuit.
1. The CIO proposes doubling the Manila circuit to 80 Mbps. Evaluate that proposal and state what you would change instead.
Read the worked answer
Reject the upgrade as the primary fix. 40 Mbps for 400 users is roughly 100 kbps per user, which is adequate for normal meeting workloads; throughput is not the failing metric. The measurements point squarely at the path, not the pipe:
- 210 ms round trip and 45 ms jitter to Chicago, versus 32 ms / 8 ms to the Microsoft 365 edge, means every real-time packet is taking a detour through a datacenter hundreds of milliseconds away.
- 2.1% packet loss against a 0.2% baseline is above Microsoft's guidance (target well under 1%), and packet loss hurts far more than bandwidth for audio and screen sharing.
What to do instead:
- Move Manila to local internet egress so Teams traffic reaches the nearest Microsoft 365 edge directly, per Microsoft's connectivity principles (Optimize / Allow / Default endpoint categories).
- Stop forcing Teams traffic through the Chicago proxy for URL inspection. Proxy inspection of real-time media breaks the Optimize category; exclude the Microsoft 365 Optimize endpoints from inspection entirely and use the published endpoint list rather than hand-built firewall exceptions.
- For the Japan remote workers, enable VPN split tunneling so Microsoft 365 Optimize endpoints bypass the tunnel, and replace full-tunnel reliance with device compliance plus Conditional Access.
- Only after those changes, re-measure. Bandwidth becomes the conversation only if measured utilization during peak meetings stays saturated.
2. Which measurements would you take, from where, and what thresholds must be met before the full 12,000-seat rollout is approved?
Read the worked answer
Measurement is only meaningful if it is taken from the client subnets that users actually sit on, not from a datacenter.
Tools:
- Microsoft 365 network connectivity test (from a Manila client machine and from a representative Japan remote session) to validate the path, the detected egress location, and whether the endpoint categories are being reached correctly.
- Microsoft Teams Network Assessment Tool or the network assessment capability in the Teams admin center for sustained jitter/loss sampling over at least a full business day, including peak hours.
Thresholds (Microsoft guidance):
- Latency: under 300 ms round trip is the outer limit; under 100 ms is the target.
- Jitter: under 30 ms.
- Packet loss: under 1%, with a target of 0.1%.
- Correct local egress detected (not Chicago) and no proxy in the media path.
Then confirm with production evidence, not just synthetic tests: publish the pilot and watch Call Quality Dashboard poor-call ratio for the pilot population filtered by building/subnet, and compare before and after. Proceed to rollout when the poor-call ratio is at or below the tenant baseline and no subnet shows a localised spike.
3. Japan remote workers report the same symptoms although they are nowhere near Manila. What do you change for them, and what is the risk you must mitigate?
Read the worked answer
Change: configure VPN split tunneling so that Microsoft 365 Optimize endpoints - including Teams media traffic - route directly to the internet instead of through the Chicago VPN concentrator. Full-tunnel VPN is the single most common cause of 'it works for me at the office' call quality tickets.
Mechanics:
- Publish the split-tunnel routes from Microsoft's published endpoint list, and keep the rest of the corporate traffic tunnelled.
- Ensure DNS resolution for Microsoft 365 endpoints happens on the tunnelled or local resolver consistent with where egress occurs, otherwise the client is sent to a distant front door even though the media path is direct.
- Keep the VPN in place for line-of-business applications.
Risk and mitigation: once traffic leaves the tunnel, you lose the network-perimeter assumption. Compensate with identity-based controls - device compliance in Intune, Conditional Access requiring compliant or hybrid-joined devices for Microsoft 365, and Defender for Cloud Apps if you need to police unsanctioned SaaS. Document that Teams media is unauthenticated UDP at the network layer and must be protected by endpoint and identity controls, not by the firewall.