Preparing Your Network for Microsoft Teams

Microsoft Teams

The running joke when having a poor user experience with applications is to “blame the network”. As it turns out, there is some truth to that. You see, if your network is not configured correctly or capable it may well be the cause of common complaints - especially when using real-time communication applications such as Teams.

At Symity we are helping more and more customers shift from on-premises Skype for Business to Teams, with that comes network considerations that were not previously needed.

The following are my best network practices when preparing for Microsoft Teams. If you have already made the jump and are experiencing issues, hopefully this will give you some guidance on how you may improve your network for Teams.

Office 365 URLs, IPs and ports

This one is key, but it is commonly overlooked. When working with Teams - or Office 365 in general - it is a good idea to be aware and classify this network traffic to ensure it is handled correctly.

Thankfully, Microsoft provide an up-to-date list of rules that include all URLs, IPs and ports that are used, including 3rd parties e.g. certificate authority CRLs - https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges

Each rule also has a category applied to it, which are:

  • Optimize
  • Allow
  • Default

The full description of each category can be found at https://docs.microsoft.com/en-us/office365/enterprise/office-365-network-connectivity-principles#BKMK_Categories but I’ve put together a brief summary:

Optimize Allow Default
Bypass proxy ☑
Bypass SSL decryption, DPI and content filtering ☑ ☑
Use local internet breakout (avoid WAN backhaul) ☑ ☑

These rules, based on the category, can then be added to firewall rules, bypass proxy servers etc.

One important part to note with this is that this list of rules will change over time, so it is key you keep your policies up-to-date. There is an API that Microsoft provide, which provides changes - some firewalls/proxies can make use of this to stay up-to-date - https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-service

Avoid using proxies where possible

Proxies do have their uses, but for Teams, it can cause issues. Microsoft do recommend not using a proxy server with Teams, but if you do have to, follow their guidance - https://docs.microsoft.com/en-US/microsoftteams/proxy-servers-for-skype-for-business-online

Always connect to your local Microsoft network edge

Microsoft Teams is a cloud-based service and has been designed with this in mind. Because of this, Microsoft recommend that the Teams client connects to its closest Microsoft network edge (aka front door). The theory being, once on Microsoft’s network, they can route traffic over its ‘dark fibres’ to the intended resource more efficiently than the internet can.

One easy way to see if this is the case for your end users, is to use Microsoft’s Office 365 connectivity tool - https://connectivity.office.com/. In this test, you enter your actual location and the tool will determine your egress location (where you reach the internet from) and your actual and optimal front door locations (these may differ)

As you can see in this example, my actual location is Birmingham, UK but my egress location is in Helsinki, Finland which is deemed too far away from being optimal for me.

Here are some examples where this might be:

Centralised internet egress

A common configuration in corporate networks is to centralise the internet egress (commonly known as WAN backhauling). In this scenario, multiple locations breakout of the same internet connection across a WAN. Whilst this may be done to reduce costs or make management easier, it is not recommended when using Teams.

For example, if you have users in London, Paris, Madrid and Helsinki with an internet egress in Helsinki, all Teams clients will connect to the closest network edge in Helsinki, which is only really beneficial to the Helsinki users.

The recommendation here is to implement local internet egress in each location, even if only for Office 365 traffic.

Remote worker VPN

It makes perfect sense from a security standpoint to route all traffic - including internet traffic - via a managed corporate network. However, when this is over a VPN, it can be less than optimal to route Microsoft Teams traffic this way.

For example, a remote worker is based in London and they connect via a VPN to the corporate network in Berlin. The Teams client will be connecting to the closest network edge in Berlin and not where the remote worker is located (which could be many different network edges based on geographic spread of remote workers).

To avoid this scenario it is recommended to configure VPN connections as ‘split-tunnel’.

Peer to peer traffic routing

Part of Teams media negotiation on peer to peer calls is to use the ‘best path’ available. For Teams, it is assumed if two clients are able to reach each other directly they are part of the same corporate network and thus will be the preferred path rather than routing across the internet.

However, with technologies such as SD-WAN e.g. Meraki, which allow sites to route between each other, but using their existing local internet connection it may not be the best path - if the SD-WAN is connected over the same internet connection for local internet access, it may be a better path to route this traffic across the internet.

If the SD-WAN is configured in a ‘hub and spoke’ or ‘star’ topology, all traffic has to route through the ‘hub’. For example, if you have two sites in the UK but the ‘hub’ is in Berlin, when a user in the one UK site calls a user at the other UK site, all that peer to peer traffic is having to traverse via Berlin - routing this traffic over the internet would more than likely provide a better result.

If your SD-WAN looks to be configured in a similar way, you may want to review what traffic is allowed from each site across the SD-WAN.

Use QoS

I hear you, Microsoft Teams is an internet-based service, there is no QoS on the internet! Sure, but perhaps the path to the internet connection is congested? You may find network congestion issues could be on the LAN or WAN between your Teams clients and the internet breakout.

Maybe you are routing peer to peer traffic across a MPLS WAN with QoS queues in place? In this scenario you would also want to prioritise the traffic and ensure your QoS queues are large enough to cope with estimated usage (see Network Planner section).

In my opinion, it is always recommended to enforce QoS where possible, even if there doesn’t appear to be a need. Perhaps all of a sudden network usage peaks and QoS is in place to prioritise the traffic.

Configuring QoS in Teams is a two step process:

  1. Enable QoS under “Meeting Settings” in Teams Admin Centre. You can also specify the ports the clients use, but unless there is a specific need to change I would stay with the default ports

  2. Ensure traffic is being marked with QoS. There are two ways this can be achieved:

    1. Configure network equipment to classify and prioritise Teams client traffic based on source ports configured. Note: Microsoft recommend classifying on source ports any destination. The benefit of this approach is that any client type (not just Windows) will have QoS applied
    2. (Windows Client Only) Create a Group Policy Object to have computer ’tag’ Teams media traffic - https://docs.microsoft.com/en-US/microsoftteams/qos-in-teams-clients

Use Teams Network Planner

When planning for Teams, it is vital you model the estimated network impact to ensure your network is capable of delivering a good experience.

Armed with each site’s network (link speeds, consumption, queue sizes etc.) and user details (personas) you can create a report estimating the network impact of Teams. Whilst ultimately this is not an exact science (concurrency is based on Microsoft’s estimation not yours), it at least gives you a ‘ball park’ figure.

In this sample report, I have a site with a 10 Mbps internet line, with 30% (3.3 Mpbs) ‘reserved’ for Teams. The estimated impact is 4.38 Mbps, taking it about the allowed bandwidth:

The Teams Network Planner can be found at https://admin.teams.microsoft.com/networkplanner/ with detailed instruction found at https://docs.microsoft.com/en-US/microsoftteams/network-planner

Use Teams Network Assessment Tool

Another tool that can be useful is Microsoft’s Skype for Business/Teams Network Assessment Tool - https://www.microsoft.com/en-us/download/details.aspx?id=53885

Microsoft have also created a nice package called the Network Testing Companion to make it easier to use if you don’t want to modify files and run PowerShell scripts - https://docs.microsoft.com/en-us/microsoftteams/use-network-testing-companion

Running the tool, it makes a series of test calls to SfB/Teams and measures the call metrics to determine if there are any issues at that time.

It is worth bearing in mind this tool is used to highlight any glaring network issues, it is not intended fully test your network. It makes a series of test calls but this is a small sample size. At the very least I would recommend this is run a different times of the day to cover different scenarios.

Use call quality analysis tools

If you are already using Teams, you should be using Call Quality Dashboard (CQD) to determine overall network performance. Every call or meeting in Teams should have network metrics recorded throughout the call. This is then stored in the CQD, allowing you to breakdown network performance on many different metrics such as latency, packet loss, jitter etc.

Explaining all the possibilities with CQD is a blog post in it’s own right, but I would recommend looking at the documentation on where to start - https://docs.microsoft.com/en-us/microsoftteams/turning-on-and-using-call-quality-dashboard

The latest v3 CQD can be found at https://cqd.teams.microsoft.com/

In addition to CQD, there is Call Analytics. Call Analytics uses the same data as CQD but allows you to troubleshoot on a per user or call basis. If a particular user is experiencing issues, Call Analytics can be used to troubleshoot the call to determine where the issue may lie.

Call Analytics can be found under each user in the Users section in Teams Admin Centre

Wrap Up

Hopefully this is of some help on how to prepare your network for Teams and also how to manage and monitor your network on an ongoing basis. As usual, all feedback welcome.