DNS geolocation for Office 365, connecting you to your nearest Datacenter for the fastest connectivity
IMPORTANT UPDATE - This method of connectivity for Exchange Online is no longer in effect. Microsoft uses an Anycast DNS model for Exchange Online connectivity which I'll describe in another post. This GeoDNS model is still relevant as it is available as a backup should it be required so I've left the post for reference
One of the main things we need to get right to ensure the most efficient and speedy connectivity to O365 is where in the world your DNS call is being completed. You'd think this wouldn't matter, you do a DNS lookup for your O365 tenant, get the address then connect right? Well, normally yes, but with O365, especially with Outlook, we do some pretty clever stuff to utilise our worldwide array of datacenters to ensure you get connected to your data as efficiently as possible.
Your Outlook connection will do a DNS lookup and we use the location of that lookup to connect you to your nearest Microsoft Datacenter. With Outlook we'll connect to a CAS server there and use our fast Datacenter to datacenter backbone network to connect you to the datacenter where your exchange servers (and data) are located. This generally works much quicker than a direct connection to the datacenter where your tenant is located due to the speed of the interconnecting networks we have.
https://technet.microsoft.com/en-us/library/dn741250.aspx outlines this in more detail but a diagram nicked from this post shows how this works for Outlook/Exchange connectivity when the Exchange mailbox is located in a NA datacenter but the user is physically located in EMEA. Therefore the DNS lookup is performed in EMEA, we connect to the nearest EMEA datacenter, which then routes the connection through to your mailbox over our backbone network, all in the background and your Outlook client knows nothing about this magic going on behind the scenes.
If your environment is making its DNS calls in a location on a different continent to where the user is physically located then you are going to get really bad performance with O365. Take an example where the user and Mailbox is located in EMEA. Your company uses DNS servers located in the USA for all calls, or the user is incorrectly set to use a proxy server in the USA, thus we're given the IP address of a USA based datacenter as that's where we think your user is located. The client will then connect to the USA based datacenter which will route the traffic to the EMEA datacenter which will then send the response back to the USA based datacenter which will then respond to the client back in EMEA. So with this scenario we've got several unnecessary trips across the pond with our data.
It is therefore vitally important to get the DNS lookup right for when you move to Outlook on Office 365.
So how do you check this? Well it could be a bit tricky as although we release a list of IP addresses used for O365, we don't tell you which ones map to where, for many reasons including the fact they change regularly. Thankfully one of my Microsoft colleagues has shown me an easy way to check you're connecting to a local datacenter.
All you need to do is open a command prompt on the client and ping outlook.office365.com and the response will tell you where the datacenter is you'll connect to. So sat here in the UK at home, I get EMEAWEST
If I connect to our Singapore VPN endpoint and turn off split tunnelling and force the DNS call down the VPN link (our Internal IT do a great job of making these things configurable for us techies) then I get directed to apacsouth.
And if I connect via VPN to the mothership in Seattle, my DNS call is completed there and thus I get directed to namnorthwest.
So it's a quick and easy check, just make sure the datacenter returned is in the same region as you're physically located in.
SharePoint is currently directed to the datacenter where your tenant is located so it doesn't matter so much where the call is made for this (although it should still preferably be local to the user for the portal connection). Lync is slightly different and is outlined in this article in more detail.
It's also worth ensuring all your clients are using a proxy in the same region as where they are located, as if not, they could hit the problem outlined above and thus be getting unnecessarily poor O365 performance.
Comments
- Anonymous
January 01, 2003
The comment has been removed - Anonymous
December 30, 2014
Hi,
Good article!
I found that if checking 'outlook.office365.com' from China mainland it gave IP from US 'outlook-apaccentral.office365.com (132.245.160.38)' but 'autodiscover.outlook.com' gave "correct" continent autodiscover-apacsouth.outlook.com (111.221.112.9)
Have this changed since the post have been wrote? - Anonymous
July 13, 2015
Interesting post Paul - does this work the same way for other workloads too (e.g. Skype for Business Online and SharePoint Online)? - Anonymous
July 15, 2015
Hi Mark. SharePoint Online goes direct, so no geo-work is done on this. Skype for business tries to connect you to the nearest pool server but in the region where your tenant resides.https://support.office.com/en-gb/article/Client-connectivity-4232abcf-4ae5-43aa-bfa1-9a078a99c78b?ui=en-US&rs=en-GB&ad=GB covers this in more detail but in essence only Outlook/Exchange really works heavily with this.
Paul - Anonymous
July 29, 2015
I have been getting a lot of questions recently about OneDrive for Business from the field. Therefore - Anonymous
August 17, 2015
Hi,
Is there a plan to change this for Onedrive for Business so that it works through datacenter connections over different regions?
Regards
Olof - Anonymous
December 08, 2015
Great article Paul. What's the options if you have a parent company based in Singapore already on O365 and want the child company in NA to join them on O365. The experience for the NA company was horrendous latency, so NA is still on-premise. Noone from MCS could make it work. - Anonymous
December 09, 2015
The comment has been removed - Anonymous
December 16, 2015
The comment has been removed - Anonymous
December 16, 2015
On my homebased connection if I ping outlook.office365.com it points me to outlook-emeacenter2.office365.com as well but that IP seems to be an entrypoint in the US. Isn't there something wrong wrong with this? This article describes my situation as well : https://stoomkracht.wordpress.com/2014/11/11/office-365-slow-and-unresponsive/ - Anonymous
December 16, 2015
The comment has been removed - Anonymous
December 17, 2015
The comment has been removed - Anonymous
December 17, 2015
The comment has been removed - Anonymous
December 17, 2015
The comment has been removed - Anonymous
January 26, 2016
Thanks Paul. This post was very helpful for one of my clients who have a branch in China. Are you aware of webmail access or (portal.office365.com) makes use of the same geolocation technique? - Anonymous
February 23, 2016
The comment has been removed - Anonymous
February 24, 2016
The comment has been removed - Anonymous
February 26, 2016
The comment has been removed - Anonymous
March 18, 2016
The comment has been removed - Anonymous
March 23, 2016
The comment has been removed - Anonymous
March 22, 2017
Has this behavior changed for SPO recently ? My tenant is in US and if i tracert tenantname.sharepoint.com from Singapore, I can see that it hits ae14-0.sg2-96cbe-1b.ntwk.msn.net [104.44.226.8] first , which seems to be MS Singapore Datacenter IP.- Anonymous
April 26, 2017
Yes, we're moving to an Anycast model for Sharepoint which should improve performance. I'll update the blog post with the detail when I get chance
- Anonymous
- Anonymous
April 03, 2017
The comment has been removed- Anonymous
April 26, 2017
This trace shows peering in Amsterdam and traversal through London to Dublin. The start point cannot be in the USA given the latency, it looks like the Netherlands and is optimal from the Netherlands.
- Anonymous