Office 365 Network Performance tool POC release

Microsoft

[Edit: A new version of the POC was published on 6/19/2019. Announced here: https://techcommunity.microsoft.com/t5/Office-365-Networking/Updated-Office-365-Network-Onboarding-T...]

[Edit: We updated the POC on 3/29/2019. Original post was on 1/16/2019]

 

With the size and scope of Office 365, a deployment can represent significant impact on an enterprise network. Connectivity issues can be complex and there are a variety of aspects to optimize including latency, local egress, WAN routing, open firewall ports, proxy bypass, bandwidth, DNS, DLP devices, cloud security brokers, etc.

 

Published today, a new Office 365 Network Performance POC tool is intended to help Office 365 enterprise customers with network connectivity related testing and connectivity guidance. Our goal is to provide a tool that runs sufficient networking tests that we can provide detailed guidance containing network configuration recommendations about devices between user machines and Microsoft’s network. The scope for this includes connectivity for all applications and services in Office 365 and spanning the customers LAN and WAN, proxy servers, firewalls, other perimeter network devices, ISP connectivity, cloud security brokers, and network routing up to Microsoft’s network.

 

Whilst we have network onboarding guidance to help with this published here, we think that by running network tests at each of your user locations we will be able to provide customized guidance that makes this work easier. It can be difficult to know what changes will make the best improvements in performance for users. Per customer guidance based on specific testing can quantify this and inform you of what connectivity elements are working well, and what still needs work for optimal performance. This should help customers doing network onboarding to have confidence in choices about networking improvements.

 

We’re starting small and have released a proof of concept tool to begin this project. It runs only a subset of the tests we are planning. It focuses on the network distance between user locations and Office 365 service front door servers. It identifies the following locations:

  • Your location either from your web browser, or that you type in
  • Your network egress location
  • The Office 365 service front door server location you are using
  • The optimal Office 365 service front door location for users in your city or metro area

 

From these locations we can provide advice if the optimal Office 365 service front door location is significantly distant to the one you are using now. We also provide a comparison of your Office 365 performance to other users in your city of metro area.

 

Whilst this work is focused at network onboarding for Office 365, it can also help with troubleshooting and optimization. If you want to improve the performance that your Office 365 users are seeing there may be optimizations you can make in your network connectivity. Also, some Office 365 customers don’t focus on network connectivity with they first start using Office 365. If you’re working with a customer that has performance issues or features in Office 365 that aren’t working, it could be that they haven’t completed network connectivity onboarding.

 

Please try it out and share your feedback as a reply below. We’re looking for feedback and we will be adding tests and guidance to this tool over the coming months.

 

http://aka.ms/netonboard

22 Replies

@dennismaurits Thanks for the report, we'll fix this for the next update. In the mean time you can avoid it by setting your decimal symbol in the control panel to be a period '.'

That works great!

Hello, We run the test and almost no errors but only 1:

 

TCP Connection failed

9
URL needs unblocking:
crl.globalsign.net
Test FQDN(s) used were:
crl.globalsign.net

 

But we can browse to crl.globalsign.net it redirects to globalsign.com. Could this be a certificate issue?? Of something else?

TCP Connection failed
9
URL needs unblocking:
crl.globalsign.net
Test FQDN(s) used were:
crl.globalsign.net

 

@Paul Andrew