Route to the Cloud
Blog Office 365 Network

Route to Office 365 best practices: Local egress

In this series of articles on Office 365 connectivity, we are explaining in detail each principle as recommended by Microsoft. In the previous article we had a look at Office 365 traffic optimization. Now let’s have a closer look at the egress point. 

In order to ensure maximum performance for Office 365 applications, the key is to reach the Microsoft Network as fast as you can.  

The goal is to set Office 365 data connections as close to the user as you can with matching DNS in order to leverage the high performance of the Microsoft Global Network.  

This network has about 200 million users; they meet Microsoft at 160 global edge sites that are connected over 130 thousand miles of dark fiber to Azure’s 54 global regions. You cannot beat that.  

Let’s speak a bit about DNS lookup.  

If the DNS lookups are not performed at the same point as the network egress, the user may be directed to a distant Office 365 front door.  And that will cause an end-user experience issue.  

Let’s check how this works in real life.  

For that I need to introduce briefly how we test the end-user experience. As you may know, GSX provides the Office 365 end-to-end service monitoring solution. We use our Robot users that can be installed anywhere and that use Office 365 exactly the way a user does, measuring the user experience and service quality, alerting and reporting on it.  

Below we see a PowerBI report from multiple Robots. For this DNS experiment we will look at the purple robot (Robot user with DNS lookup in Russia) and the yellow witness Robot (perfect configuration of the DNS).  

 

Othe User Experience Quality chart we can see the extreme difference between the yellow (witness on the left) and the purple (bad DNS on the right).  

The Robot with inadequate DNS connects the user to a front door that is much further from Nice than the best possible one (in Marseille) so that we can see the effect on the overall quality of service.  It is interesting to check deeper in Office 365, for example on Exchange, to see how this bad DNS affect the service.  

Here we compare the perfect Robot (yellow) with the bad DNS one (purple) for three different actions performed on Exchange:  

 

You can see that the free/busy check shows about 25% gap in performance, while the search shows almost 33% degradation. The action to create a meeting is less affected. Non-local egress, for example because of a bad DNS, has various serious effects on your end-user satisfaction and productivity.  

To troubleshoot this, in case you don’t know what is going with the DNS, where it looks up and what to do, you can use the Microsoft Connectivity Tool.

When running it from the Robot with latency, it confirms that the traffic is rerouted to Russia and hence has a higher latency.  

 

When you don’t know what is going on at a location, the connectivity tool is handy to test the route to the cloud. We will come back to this later iother blog posts.  

To sum up, we’ve seen how it is important to be able to detect poor end-user experience and service quality through by using the GSX monitoring solution for Office 365. You can then troubleshoot what is going on with the Microsoft Connectivity tool.  

Ithe next blog post we will see how connecting your users directly to the nearest front door after egressing locally is just as important to ensure end-user satisfaction.  

In this series of articles on Office 365 connectivity principles, we discuss: 

GSX Solutions provides the only Office 365 user experience monitoring tool that truly measures the quality of the service delivered to all enterprises’ sites, enabling their IT to take power of the Office 365 performance.

Get started today with Office 365 monitoring and see how you can keep your employees on the path to optimal productivity.

Let's get started.