- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: O365 official connectivity test discussion
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
O365 official connectivity test discussion
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some of our users RDP'd in using teams reports being disconnected from Teams meeting periodically. Users with VMware horizon client on VPC don't report that. It may be happening during a rule push.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How is your Connection Persistence currently set?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Rematch Connections
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please see sk103598 and test the "keep all" option to see if it helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Will do if need thanks-its a balance.
