During the last months, this question became very relevant as many organizations have shifted to supporting remote workers during COVID-19 work-at-home times. Many organizations have implemented VPN solutions hastily and forgot about the correct routing or DNS resolution strategy for SaaS services like Microsoft 365.
I have been asked questions like:
- Is my network connection the best I can get for Microsoft 365?
- How can we test the connectivity from a home office or an office location to the Microsoft 365 services?
- What is the net impact of a VPN tunnel to the Microsoft Teams video call?
- Is the VPN split tunneling for Microsoft 365 working as expected?
We will look into a new tool from Microsoft which can help to answer these questions. But first, let’s look at the reality and maybe your infrastructure looks something like this: One big, fat Internet pipe at the head office is responsible to give clients access to the Internet. A firewall and proxy pretend additional security.
A lot of companies still follow the above approach, while the overall majority of Internet traffic is already encrypted and cannot be looked at anymore. Maybe some deep packet (SSL) inspection can help here, but this sacrifices a lot of other security and sometimes even lowers security (The risks of SSL inspection). With the upcoming TLS 1.3, it will even be harder to intercept traffic.
I am not going into all disadvantages of a central Internet breakout here. If you want to get the best out of your Microsoft 365 SaaS platform, you will need to embrace more decentralized Internet connectivity! Not many companies have already fully adopted this idea yet: Local Internet break-outs without a proxy can leverage the many entry points (front doors) into the large Microsoft Global network.
„The best Internet for Microsoft 365 is the one where you can watch Youtube in Full HD whiteout any issues!“
An ideal network for SaaS Services would look like this:
How can we test the connectivity from a home office or an office location to the Microsoft 365 services?
The good news is there is a new preview tool available supporting the troubleshooting of this question easily. The Office 365 Network Onboarding Tool consists out of two components: a downloadable Windows client (requiring .Net Core 3.1 Desktop runtime) is performing some advanced network connectivity and DNS lookups tests and a web page, which shows the results along with some guidance about networking connectivity improvements, that can be made between a user location to Microsoft.
Some simple tests can also be run without the client, but if you want to detect the use of a VPN, and evaluate if the VPN is configured for recommended Microsoft 365 split tunneling, it is vital to run the user space application. No installation is required, and normal user privileges are sufficient.
Sharing Test results
The test results can be shared by an anonymous link, with the tenant administrator, and other users, when the user is signed-in with an Office 365 account. Even sharing results with the Microsoft account or support team is possible (without any personally identifiable data). The sharing capabilities can be controlled by an administrator.
Network Connectivity Test Results
The results are shown in the Summary and Details tabs. The summary tab shows a map of the detected network perimeter and a comparison of the network assessment to other Office 365 customers nearby. It also allows for sharing of the test report. Here is what the summary results view looks like.
On the details tab, we see the green circle check mark if the result was compared favorably to a threshold. A red triangle exclamation point is shown if the result exceeded a threshold indicating a network insight. The following paragraphs describe each of the details tab results rows and gives recommendations for the identified network insights.
The location information report gives an insight into how the user’s web browser detected the location or what the typed in himself. It is used to identify network distances to specific parts of the enterprise network perimeter. Only the city from this location detection and the distance to other network points are saved in the report.
The network egress IP address is detected on the server-side. This is like the “What is my IP address” tools. Location databases are used to look up the approximate location for the network egress point (the public IP of your home office router or enterprise edge router). These databases typically have an accuracy of about 90% of IP addresses. If the location looked up from the network egress IP address is not accurate then this would lead to a false result from this test. (This often happens for company owner IPs when the registrar address data is outdated.) Microsoft determines based on the browser/user-provided location and the discover public IP location the distance from that location to the office location. This is shown as a network insight if the distance is greater than 800 kilometers since that is likely to increase the TCP latency by more than 25ms and may affect user experience.
Implementing local and direct network egress from user office locations to the Internet is recommended for Microsoft 365 network connectivity. Improvements to local and direct egress are the best way to address this network insight.
In the next step, the client is identifying proxy server(s) configured on the local machine. It identifies if any of these are configured in the network path for optimizing Microsoft 365 network traffic. The distance from the user location to the proxy servers is determined, first by an ICMP ping and if that fails another test with a TCP ping and finally if that fails, a look up of the proxy server IP Address in an IP Address location database is performed. A network insight is shown if the proxy server is further than 800 kilometers away from the specified user’s office location.
A very important test is the detection if there is a VPN connection to Office 365. If a VPN was detected it will check if the recommended split tunnel configuration for Office 365 is applied. Each service (Exchange Online, SharePoint Online, and Microsoft Teams) is tested to see if it is tunneled on the VPN or not. A passing result will show if all workloads are split out or selective tunneled.
DNS is an important part of the over user experience. A slow DNS response to the client has an overall impact on how fast a user gets connected to a service. The tool measures the time to make a DNS request on your network and it shows the DNS server(s) configured on the client machine. Microsoft uses a trick here: The client’s in-use DNS Recursive Resolver is identified by making a specific DNS request and then asking the Microsoft DNS Name Server for the IP Address that it received the same request from. This IP Address is the client’s DNS Recursive Resolver and it will be looked up in IP Address location databases to find the location. The distance from the user location to the DNS Recursive Resolver server location is then calculated. This is shown as a network insight if the distance is greater than 800 kilometers.
This network insight will specifically impact the selection of the Exchange Online service front door. To address this insight local and direct network egress should be a pre-requisite and then DNS Recursive Resolver should be located close to that network egress.
The in-use Exchange service front door is identified in the same way that Outlook does this, and the TCP latency is measured from the user location to it. The TCP latency is shown, and the in-use Exchange service front door is compared to the list of best service front doors for the current location. This is shown as a network insight if one of the best Exchange service front door(s) is not in use.
Not using one of the best Exchange service front door(s) could be caused by a network “detour” before leaving the corporate network in which case the routing should be reviewed and a local and direct network egress should be implemented. It could also be caused by the use of a remote DNS recursive resolver server that gets not the closest geographical IP. For example, a European client using an Australian DNS resolver will provide Asia-Pacific IPs for the Exchange front-door and leads to a poor network routing. It is recommended aligning the DNS recursive resolver server with the network egress.
The report calculates a potential improvement in TCP latency (ms) to the Exchange service front door. This is done by looking at the tested user office location network latency and subtracting the network latency from the current location to the closets Exchange service front door. The difference represents the potential opportunity for improvement.
The SharePoint service front door is identified in the same way that the OneDrive client does, and the network TCP latency is measured from the user’s location to it.
The download speed is measured with a 15Mb file from the SharePoint service front door. The result is shown in megabytes per second to indicate what size file in megabytes can be downloaded from SharePoint or OneDrive in one second. (The number should be like one tenth of the minimum circuit bandwidth in megabits per second. For example, if you have a 100mbps internet connection, you may expect 10 megabytes per second (10MBps).) To get an understanding of how the network latency is influenced under high load conditions, the tool is measuring the TCP latency to the SharePoint service front door. This is the latency under load, and it is compared to the latency when not under load. The increase in latency when under load is often attributable to consumer network device buffers being loaded (or bloated). A network insight is shown for any bloat of 1,000 or more.
The Media connectivity (audio, video, and application sharing) test validates for UDP connectivity to the Microsoft Teams service front door. If this is blocked Microsoft Teams will fall back using TCP instead, but audio and video quality will be impaired and causes even higher bandwidth consumption, as it needs to confirm every transmitted TCP packet back.
The UDP packet loss is measured in a 10-second test audio call from the client to the Microsoft Teams service front door should be lower than 1.00% for a pass.
Round-Trip latency measures the time taken to send a data packet to a destination and get a response back. An as lowest as possible latency is always preferred. To avoid any issues with Teams, the RTT Latency should be lower than 100ms. An increased latency provides unnatural pauses during the conversation, where users will start talking at the same time and interrupting each other.
Audio and Video data is sent in small packets over the network. Not every packet arrives with the same regularity at the destinations. This is usually because of overall network performance and latency varies over time. Jitter is the average change in delay between successive packets. A local buffer at the receiver side makes sure the packets are reconstructing in the correct order. The UDP jitter should be lower than 30ms in a 15-second average. A WIFI connection is more prone than a wired LAN connection.
The connectivity test checks if the user client can reach out to all of the required Microsoft 365 network endpoints (https://aka.ms/o365ip). A network insight is shown for any required network endpoints which cannot be connected to. Connectivity can be blocked by a proxy server, a firewall, a filtering DNS, or another network security device on the enterprise network perimeter or in use as a cloud proxy.
The SSL certificate at each required Microsoft 365 network endpoint is validated to be a Microsoft issued SSL certificate. When an SSL certificate is found that is not provided by Microsoft, the FQDN for the test and the in-use SSL certificate owner is shown. This SSL certificate owner may be a proxy server vendor, or it may be an enterprise self-signed certificate.
This is the result of an ICMP traceroute to the Exchange Online, the SharePoint Online service front door, and the Microsoft Teams service front door. It is just informational only and there is no associated network insight.
More details can be found here:
Media Quality and Network Connectivity Performance in Skype for Business Online (Applies for Teams in the same ways as for any other Real-Time media)