The best connectivity to Office 365 is achieved with local internet breakout and local DNS egress. This means things like each branch office should connect directly to the internet and not via the Head Office and then to the internet and that DNS lookups are done local as well. The reason for DNS lookups is to do with AnyCast and DNS resolution. Microsoft see where you make your DNS requests from and return responses to Office 365 that are near where the DNS egress point is. So if you lookup DNS from the head office in a different county, but still have local internet breakout, you might connect to the Office 365 endpoints close to the head office and not the endpoints in your country.
To test this, it used to be the case that you could ping outlook.office365.com and see what FQDN was returned and ensure that it was in the same geography to where you are. At the time of writing this is still the case some of the time, but it is changing.
Therefore, lets say you were located in Europe and you ran “ping outlook.office365.com” – it might return something in the URL that looked like EMEA-WEST. If it returned US anything then you had an issue with DNS and maybe internet egress. An example of how it always used to be was:
This was a great test until recently, but in the last few months this DNS lookup has changed to connect to an endpoint called ACDC. For example now it might show:
This is a connection to the ACDC endpoint, which is AnyCast DNS Cafe, where Cafe is the Client Access Front End service, or the Front Door service to Exchange Online. Not the data location, but a service endpoint close to you to do SSL connectivity and work out where your mailbox is and to connect to that endpoint. In the last year by changing to the ACDC endpoint technology, Microsoft have reduced latency to cloud hosted Exchange Online in the region of 100ms.
Unfortunately, this means a simple test for local internet egress has stopped working and you need to investigate further the route taken to reach the Microsoft network. A suggestion simple test for this is tracert. For this you need to run “tracert outlook.office365.com”. This has the risk of being blocked at the firewall, as ICMP is often restricted even though it is used to help modulate TCP window size and other useful network packet adjustments, but an idea can be got from running tracert to the same location as the ping.
For example, ping outlook.office365.com for me was returning an RTT (round trip time) of 13ms. Tracert showed similar:
In my case I was getting the following, where the airport code at the start of the endpoint indicates the location of the Microsoft Front Door – in my case LHR = London Heathrow. Note that it’s the closest airport code, and not the closest international airport – you might not have even heard of the airports that are near datacenters!
Tracing route to lhr-efz.ms-acdc.office.com [40.99.213.18]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms unifi [192.168.5.1]
2 * * * Request timed out.
3 18 ms 12 ms 7 ms 80.255.197.170
4 * * * Request timed out.
5 * * * Request timed out.
6 14 ms 14 ms 11 ms telw.isp.net [62.253.174.186]
7 14 ms 13 ms 13 ms lon32.ntwk.msn.net [104.44.14.51]
8 14 ms 13 ms 15 ms lon22.ntwk.msn.net [51.10.15.212]
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 13 ms 13 ms 11 ms 40.99.213.18
Trace complete.
From this we can see 13ms to the first hop on Microsoft’s network. Full RTT and latency for Outlook can be found on the Connection Status dialog, as this includes the processor time in Exchange Server/Exchange Online and the network RTT to the server that contains the data and not just the Microsoft Front Door CAFE service.
Leave a Reply