Optimize your network for Microsoft Teams

Before you start planning your network for Microsoft Teams network connectivity, it is important to understand the connectivity principles for managing Microsoft Teams traffic and getting the best possible performance for your end users.

Traditional enterprise networks are mostly designed to provide users access to applications and data hosted in company or co-located datacenters with focus on strong perimeter security and easy to manage for the IT departments. The traditional model assumes that users will access applications and data from inside the corporate network perimeter, over WAN links from branch offices, or remotely over VPN connections and will use one break out to the public internet managed by a corporate firewall.

When you will use products from the Office365 portfolio you will connect to online (SaaS) services over the public internet.

Microsoft strongly recommends the following principles to achieve optimal Microsoft Teams connectivity and performance. Use these connectivity principles to manage your traffic and get the best performance when connecting to Microsoft Teams.

The primary goal in the network design is to minimize latency by reducing the round-trip time (RTT) from your network into the Microsoft Global Network (MGN), Microsoft’s public network backbone that interconnects all of Microsoft’s datacenters with low latency and cloud application entry points spread around the world.

Identifying Microsoft Teams network traffic is the first step in being able to differentiate that traffic from generic internet traffic. Office 365 connectivity can be optimized by implementing a combination of approaches like network route optimization, firewall rules, browser proxy settings, and bypass VPN or network inspection devices for certain endpoints.

Microsoft publishes all Office 365 endpoints in order to make it easy to configure. You can find the IP addresses, FQDNs and Port in the Firewall chapter.

Here are some tips to help you roll out smootly.

The three major risks that affect performance, happiness and satisfaction are:

• Insufficient bandwidth available
• Firewall and proxy blockers
• Network impairments such as jitter and packet loss

Local testing

With the Network Testing companion you can make some quick checks on the Windows endpoint if everything works well. I’ve writen a article some while ago how to use the Network Assessment Tool.

The tool contains some basic tests for:

• Connectivity to Office365 (Ports TCP443 and UDP3478)
• Make some test calls (Roundtrip latency, jitter etc)

If you wan to use a graphical interface for testing, you can use the Network testing Companion from Microsoft. You can find more information about the tool right here This tool also includes some testing for your hardware, internet connection and your peripheral equipment.

Bandwidth

In belows table you will find some scenario with their bandwidth usage.

Firewall

With belows script you can get all of the up to date endpoints from Office 365.

• IPv4 ranges
• IPv6 ranges
• URLS for Proxy server

Firewall ports IPs and FQDNs

    <# Get-O365WebServiceUpdates.ps1
    From https://aka.ms/ipurlws
    v1.1 8/6/2019

    DESCRIPTION
    This script calls the REST API of the Office 365 IP and URL Web Service (Worldwide instance)
    and checks to see if there has been a new update since the version stored in an existing
    $Env:TEMP\O365_endpoints_latestversion.txt file in your user directory's temp folder
    (usually C:\Users\<username>\AppData\Local\Temp).
    If the file doesn't exist, or the latest version is newer than the current version in the
    file, the script returns IPs and/or URLs that have been changed, added or removed in the latest
    update and writes the new version and data to the output file $Env:TEMP\O365_endpoints_data.txt.

    USAGE
    Run as a scheduled task every 60 minutes.

    PARAMETERS
    n/a

    PREREQUISITES
    PS script execution policy: Bypass
    PowerShell 3.0 or later
    Does not require elevation
    #>

    #Requires -Version 3.0

    # web service root URL
    $ws = "https://endpoints.office.com"
    # path where output files will be stored
    $versionpath = $Env:TEMP + "\O365_endpoints_latestversion.txt"
    $datapath = $Env:TEMP + "\O365_endpoints_data.txt"

    # fetch client ID and version if version file exists; otherwise create new file and client ID
    if (Test-Path $versionpath) {
        $content = Get-Content $versionpath
        $clientRequestId = $content[0]
        $lastVersion = $content[1]
        Write-Output ("Version file exists! Current version: " + $lastVersion)
    }
    else {
        Write-Output ("First run! Creating version file at " + $versionpath + ".")
        $clientRequestId = [GUID]::NewGuid().Guid
        $lastVersion = "0000000000"
        @($clientRequestId, $lastVersion) | Out-File $versionpath
    }

    # call version method to check the latest version, and pull new data if version number is different
    $version = Invoke-RestMethod -Uri ($ws + "/version/Worldwide?clientRequestId=" + $clientRequestId)
    if ($version.latest -gt $lastVersion) {
        Write-Host "New version of Office 365 worldwide commercial service instance endpoints detected"
        # write the new version number to the version file
        @($clientRequestId, $version.latest) | Out-File $versionpath
        # invoke endpoints method to get the new data
        $endpointSets = Invoke-RestMethod -Uri ($ws + "/endpoints/Worldwide?clientRequestId=" + $clientRequestId)
        # filter results for Allow and Optimize endpoints, and transform these into custom objects with port and category
        # URL results
        $flatUrls = $endpointSets | ForEach-Object {
            $endpointSet = $_
            $urls = $(if ($endpointSet.urls.Count -gt 0) { $endpointSet.urls } else { @() })
            $urlCustomObjects = @()
            if ($endpointSet.category -in ("Allow", "Optimize")) {
                $urlCustomObjects = $urls | ForEach-Object {
                    [PSCustomObject]@{
                        category = $endpointSet.category;
                        url      = $_;
                        tcpPorts = $endpointSet.tcpPorts;
                        udpPorts = $endpointSet.udpPorts;
                    }
                }
            }
            $urlCustomObjects
        }
        # IPv4 results
        $flatIp4s = $endpointSets | ForEach-Object {
            $endpointSet = $_
            $ips = $(if ($endpointSet.ips.Count -gt 0) { $endpointSet.ips } else { @() })
            # IPv4 strings contain dots
            $ip4s = $ips | Where-Object { $_ -like '*.*' }
            $ip4CustomObjects = @()
            if ($endpointSet.category -in ("Allow", "Optimize")) {
                $ip4CustomObjects = $ip4s | ForEach-Object {
                    [PSCustomObject]@{
                        category = $endpointSet.category;
                        ip = $_;
                        tcpPorts = $endpointSet.tcpPorts;
                        udpPorts = $endpointSet.udpPorts;
                    }
                }
            }
            $ip4CustomObjects
        }
        # IPv6 results
        $flatIp6s = $endpointSets | ForEach-Object {
            $endpointSet = $_
            $ips = $(if ($endpointSet.ips.Count -gt 0) { $endpointSet.ips } else { @() })
            # IPv6 strings contain colons
            $ip6s = $ips | Where-Object { $_ -like '*:*' }
            $ip6CustomObjects = @()
            if ($endpointSet.category -in ("Optimize")) {
                $ip6CustomObjects = $ip6s | ForEach-Object {
                    [PSCustomObject]@{
                        category = $endpointSet.category;
                        ip = $_;
                        tcpPorts = $endpointSet.tcpPorts;
                        udpPorts = $endpointSet.udpPorts;
                    }
                }
            }
            $ip6CustomObjects
        }

        # write output to screen
        Write-Output ("Client Request ID: " + $clientRequestId)
        Write-Output ("Last Version: " + $lastVersion)
        Write-Output ("New Version: " + $version.latest)
        Write-Output ""
        Write-Output "IPv4 Firewall IP Address Ranges"
        ($flatIp4s.ip | Sort-Object -Unique) -join "," | Out-String
        Write-Output "IPv6 Firewall IP Address Ranges"
        ($flatIp6s.ip | Sort-Object -Unique) -join "," | Out-String
        Write-Output "URLs for Proxy Server"
        ($flatUrls.url | Sort-Object -Unique) -join "," | Out-String
        Write-Output ("IP and URL data written to " + $datapath)

        # write output to data file
        Write-Output "Office 365 IP and UL Web Service data" | Out-File $datapath
        Write-Output "Worldwide instance" | Out-File $datapath -Append
        Write-Output "" | Out-File $datapath -Append
        Write-Output ("Version: " + $version.latest) | Out-File $datapath -Append
        Write-Output "" | Out-File $datapath -Append
        Write-Output "IPv4 Firewall IP Address Ranges" | Out-File $datapath -Append
        ($flatIp4s.ip | Sort-Object -Unique) -join "," | Out-File $datapath -Append
        Write-Output "" | Out-File $datapath -Append
        Write-Output "IPv6 Firewall IP Address Ranges" | Out-File $datapath -Append
        ($flatIp6s.ip | Sort-Object -Unique) -join "," | Out-File $datapath -Append
        Write-Output "" | Out-File $datapath -Append
        Write-Output "URLs for Proxy Server" | Out-File $datapath -Append
        ($flatUrls.url | Sort-Object -Unique) -join "," | Out-File $datapath -Append
    }
    else {
        Write-Host "Office 365 worldwide commercial service instance endpoints are up-to-date."
    }

Quality of Service Considerations

Although Quality of Service (QoS) isn’t required to use Teams, it is highly recommended that you deploy QoS in your network. If you know that QoS is already configured in your environment then you should definitely consider using it for Teams as well. If you have QoS being used today by other applications but not Teams, this will mean that your users will have an adverse experience with Teams since the other applications utilizing QoS are getting priority over Teams. SCRIPT.

However, if you don’t have QoS in place on your network, you may opt to leave things as is due to the high cost and management difficulties it may present. Instead, you may want to invest in additional bandwidth since QoS really only comes into play when you have a lack of bandwidth and in turn it helps you prioritize your audio/video/desktop sharing traffic. If you do have sufficient bandwidth then QoS won’t have any affect on your network so many customers will typically just purchase more bandwidth rather than dealing with a huge QoS project.

By default QoS in Teams is not activated, you can activate and configure this in the Teams Admin Center below Meeting.

Teams Advisor Tool

You can use the Advisor for Teams thats walks you through your Microsoft Teams rollout. It assesses your Office 365 tenant environment and identifies the most common configurations that you may need to update or modify before you can successfully roll out Teams in your organization.

The Advisor for Teams creates a Deployment team (in Teams ofcourse ;-)), with channels for each workload you want to roll out. Each workload in the Deployment team comes with a comprehensive Planner plan that includes all the rollout tasks for each workload. Using the Planner plan, you’ll assign tasks to the people responsible for each phase of the rollout - including the project manager, Teams and Office 365 admins, support people, and your adoption and user readiness team.

Each rollout task contains all the guidance and resources you need to successfully complete the task.

You can find the Advisor tool in the Teams Admin Center.

Network Planner

You can find the Network planner in your Teams Admin Center The network planner consists of 2 parts.

The network planner helps you to determine and organize network requirements for connecting people that use Teams across your organization in some basic steps. By providing your networking details and Teams usage, you will get calculations and the network requirements you need when deploying Teams in your organization.

Network plan

Depending on your organization’s network, you want to use sites to represent a building, an office location, or something else. Sites might be connected by a WAN to allow sharing of internet and/or PSTN connections.

For best results, create sites with local connections before you create sites that remotely connect to the internet or PSTN.

Personas

The personas tab you can use to setup the specific user/device types. By default you already have 3 personas (Microsoft Recommended).

• Teams Room System
• Office worker
• Remote worker

Of course you can create your own custom personas to, for example a Remote Office work without PSTN and one with PSTN.

Call Quality Dashboard (CQD)

The Call Quality Dashboard is a powerfull tool to locate problems in your network when rolling out and maintaining the service.

One thing you don’t need to forget is that you need to upload your building data by hand, this is not (yet) combined with the Network Plan.

You can find more information about the CQDv3 over here.

VPN and Proxy

When it comes to Teams traffic over proxies or VPN, Microsoft recommends bypassing proxies and VPNs. Proxies and VPNs don’t make Teams more secure because the traffic is already encrypted by default.

Having a proxy can cause a lot of issues. Performance-related problems can be introduced to the environment through high-latency and packet loss. Issues such as these will result in a negative user experience in such Teams scenarios as audio and video, where real-time streams are essential.

/