What it does

The Microsoft 365 network connectivity test runs from a user's location and tells you whether that network can reach Teams media properly — UDP open, loss, latency and jitter to the nearest Teams front door — alongside egress, DNS and VPN checks. The older standalone Teams Network Assessment Tool does a similar media check from the command line.

Key facts

• The connectivity test is at https://connectivity.m365.cloud.microsoft (21Vianet: connectivity.sovcloud.cn). Older material still points at connectivity.office.com.
• Teams thresholds it reports against: packet loss under 1.00% (over a 10-second test audio call), UDP latency under 100 ms, UDP jitter under 30 ms, plus a pass/fail on UDP connectivity to the Teams front door.
• If UDP is blocked, Teams falls back to TCP and audio and video are impaired — the test calls this out directly.
• It also reports network egress location and distance, DNS resolver performance, SharePoint speed and buffer bloat, VPN and split tunnel detection, TLS inspection and Copilot WebSocket connectivity.
• The advanced tests need a Windows client app that the page downloads; it needs the .NET 6.0 runtime (admin rights to install it) and TCP 443 to connectivity.service.signalr.net.
• Signed-in runs upload to the tenant. Reports are shared within the organisation by default, public ReportID links are off by default, and reports expire after 90 days by default.
• A command-line build (MicrosoftConnectivityTest.exe) can run unattended from Task Scheduler and writes JSON to a TestResults folder, but doesn't upload to the tenant.
• Network insights in the Microsoft 365 admin center come from in-product measurements aggregated daily; the connectivity test is a local, point-in-time run. Microsoft positions them as complementary.
• The Teams Network Assessment Tool is still on the Microsoft Download Center. NetworkAssessmentTool.exe checks connectivity to Teams media relays; NetworkAssessmentTool.exe /qualitycheck runs a media quality test.

When to use / skip

Run the connectivity test at every office during discovery, before anyone signs off a Teams Phone or Teams Rooms rollout, and from a representative sample of home workers. It's the quickest way to find the real problems: UDP blocked at the firewall, internet egress three countries away, traffic dragged through a cloud proxy, or a VPN swallowing media. Ten minutes per site, and it gives you evidence the network team can't argue with.

Use the Network Assessment Tool when you need a longer-running or scripted media test from a specific machine — a Teams Rooms build PC on a new VLAN, say — or when the browser test can't be run. For ongoing monitoring, neither is the answer; that's CQD and call analytics once real traffic exists.

Skip neither on a voice project. A Teams Phone design that hasn't been tested from the actual sites is guesswork.

Configuration decisions

• Which locations to test: every office, or a representative set by circuit type and egress model. Include at least one site per region and one typical home setup.
• Signed-in or anonymous runs. Signed-in is better — results land in the tenant and feed admin center network insights — but some clients won't let consultants sign in with tenant accounts.
• Whether to allow public ReportID sharing for partner access, or stick with in-tenant sharing.
• Whether to schedule the command-line build on a few fixed machines for repeated measurements across a day, which catches busy-hour problems a single run misses.
• Whether the advanced client is allowed on managed devices at all, given it needs .NET 6.0 and admin rights.

Gotchas

• One test is one moment. A clean result at 8am tells you nothing about the 10am peak; repeat at busy times.
• The browser test only covers what the browser can do. Without the advanced client you lose the deeper checks — users often close the page before it finishes.
• A pass on latency doesn't mean the path is sensible. Look at the egress location and the front door chosen; backhauled or proxied traffic often passes the thresholds while still taking the long way round.
• The tests run from wherever the device is attached. Testing over guest Wi-Fi when users sit on the corporate SSID gives you the wrong answer.
• Old documentation and blogs reference retired URLs and the classic Skype for Business-era tools. Check you're using the current connectivity test link.
• The command-line build's results stay local. If you rely on it, you're collecting and comparing the JSON yourself.

Consultant notes

• Make the connectivity test part of the discovery checklist and attach the report IDs to the site survey. It saves arguments later.
• If UDP 3478–3481 fails, stop and get it fixed before anything else. Every other quality problem is secondary to TCP fallback.
• Compare the egress location to the user's physical location. A London office egressing in Amsterdam or via a US-hosted proxy is the classic finding.
• Run it again after firewall and split tunnel changes to prove the fix — before-and-after screenshots carry more weight than a change ticket.
• Once the tenant is live, cross-check site findings against CQD by building; the two should tell the same story.

---

Check whether the standalone Network Assessment Tool is still offered, and whether the connectivity test has moved URL again, at the start of each new engagement