Session summary:
Blame it on the network is often used when users experience issues with business applications. In Teams, this is a very real possibility. In this session, I will outline various concepts on how and why your network should be prepared to accommodate Teams.
Topics covered are how network traffic should be classified, routed and prioritised and how you can verify network performance.
My notes:
Any recommendations in this session can be implemented before you fully migrate to Teams, or afterwards. Teams is engineered in a way that a local internet breakout from the client is strongly recommended.
The ten recommendations
- Allow ALL Teams traffic through your network
Office 365 URLs and IP address ranges
Bypass Proxy, SSL decryption, DPI and content filtering
Keep it updated by using the Office 365 IP Address and URL web service - Bypass Proxies
- Use Quality of Service
Yes, Teams is cloud-based and the Internet does not use QoS, but it is best practice to ensure that the route to the Internet is prioritised correctly.
DSCP - differentiated services code point - Values
46 audio
34 video
18 Application/Screen Sharing - Have the client "break out" locally and make sure you a split-tunnel VPN for Teams traffic (if VPN is used.)
- Be aware of Peer to Peer routing scenarios
Route the media directly between the two clients on their internal IP addresses. - Use the Office 365 Network Onboarding tool
- Use the Teams Network Planner
Found inside the Teams Admin center, will give you an estimation, not exact science. - Capture Teams traffic to determine usage patterns
Monitoring Microsoft Teams Network Traffic
This will naturally be more accurate than the Network Planner. - Use the Teams Network Assessment tool
- Use the Office 365 Call Quality analysis tools
Use CQD as an ongoing exercise, and the reports available in the Teams Admin center.
Lee himself created a blog post about this session that can be found here: Preparing Your Network for Microsoft Teams
No comments:
Post a Comment