Probably not the best forum but some of you probably do work a lot with O365 connectivity challenges so worthwhile sharinghere too.
We noticed that MS official test webpage https://connectivity.office.com/ results can be very misleading if you are using "split" solution, i.e. proxy or SD WAN controlled bypass for O365 traffic
There's very little technical description of those tests by MS so we were left with no option but to reverse engineer them to understand why we were getting so poor results in South America. It's worth noting here that we are using SD WAN (not Checkpoint) trying to break out O365 as close to the user as possible using pre-defined O365 object, similar to CP Updatable Objects.
These three points were identified and helped us to achieve better results
- Location determination. It's a browser API based solution. I saw that from home, my wifi MAC address was used to determine actual GEO location and it was accurate, but for offices in South America it turned out that in order to get correct results following three URLs had to be excluded from being sent to on-prem proxy and instead routed the same way as O365 traffic.
- inference.location.live.net
- googleapis.com
- dev.virtualearth.net
- Recursive DNS latency. MS test uses whoiami.akamai.net service to work out your recursive DNS location and with our SD WAN box, it followed default path to our on-prem solution. In order to get correct O365 test results, we had to exclude also this FQDN from being sent to on-prem and instead follow direct path just like O365
- Voice / video meeting test results are totally inaccurate. MS is using worldaz.tr.teams.microsoft.com IP resolution in order to perform performance tests like jitter, latency, packet order and packet loss on UDP ports 3478-3481. Problem with that is for example in Argentina this name resolves to an IP in Azure datacentre in USA thus showing nearly 200ms latency! In reality audio meetings in Argentina terminate in Azure datacentre in Sao Paulo and performance is actually acceptable. Not a lot we can do to fix this yourself as MS needs to fix test itself, but make sure that real-time meeting traffic is excluded too from being sent on-prem in your SD WAN device
I just wanted to share these findings and see if there are any other good tips out there for dealing with O365 challanges
