Top 10 Tips for Optimising & Troubleshooting your Office 365 Network Connectivity
Having performed numerous Office 365 Network assessments and reactive visits to resolve issues for customers, its apparent that the vast majority of issues are seen time and time again. So from this experience, here are my top 10 tips for you to optimise your O365 network performance and prevent issues occurring in future.
Some of these issues, if occurring, will cost you seconds, others more, but by eliminating them all and getting your proverbial network ducks in a row, you'll ensure you are providing the best possible Office 365 experience for your users.
As some of these issues are complex, rather than provide a detailed explanation for each scenario in this blog post, I've linked to separate blog posts which cover each in detail as and when you need them.
1. TCP Window Scaling
This tops my list of things to check due to the impact it can have on performance and the amount of times I see it disabled on legacy network equipment. Unfortunately there is no simple way of checking this from a client without taking a network trace but I've outlined how to do this, and the setting in much more detail in a separate blog post here
If you check only one thing on your O365 network link, then I'd advise it's this!
2. TCP Idle time settings
This issue is another very common one and is caused by settings on egress points of corporate networks not being adjusted for Outlook running through it. Problems caused by this can include hangs within Outlook, especially when switching mailboxes/calendars and unexpected auth prompts. It's relatively easy to fix and I've outlined the problem, and solution in much more detail here.
3. Latency/Round Trip Time (RTT)
Network latency has the ability to cause real issues with O365 and it's usability. Checking your RTT to O365 is a worthwhile task regardless of whether you're having issues as it provides you with a great baseline should performance issues occur in future allowing you to isolate where the delay is occurring.
The detailed guide on how to do this is here
4. Proxy Authentication
On numerous occasions I've run into unnecessary delays on connecting to O365 caused by proxy authentication. With Outlook this can cause a delay on start up, when switching mailboxes/calendars etc, anything that requires a new TCP connection to be spun up. With SharePoint this will manifest itself as slow initial page loads.
The detailed guide on how to check this is here
5. DNS performance
A simple one but often forgotten. DNS performance should be checked to ensure it isn't adding additional delays to your Office 365 connections. A detailed guide to checking DNS performance can be found here.
6. Proxy Scalability
This issue can effect both performance and cause issues further down the line when you least expect it. Proxies are invariably in place before the move to Office 365 and are often used without much reconfiguration for the Office 365 traffic. It's worth checking your numbers here as you may find you're sailing closer to the wind than you realise.
The more detailed description of the problem and guidance can be found here
7. TCP Max Segment size
A simple one to check but worth a look none the less. To ensure maximum throughput on the link between yourself and Office 365 we should be using as close to as possible the maximum TCP segment size for transferring data.
More detail on how to check this is here
8. Selective Acknowledgement
Whilst you're digging around in the TCP Options in your 3-way handshake, it's worth checking Selective Acknowledgement (SACK) is enabled. This feature enables your TCP stack to deal with dropped packets more efficiently.
A slightly more detailed explanation of SACK and how to check it can be found here.
9. DNS Geo location
One of the most important checks you can make, and one that can make a big difference in the performance of O365 is ensuring your DNS call are made in the same geographic location as the user is actually in. Getting this wrong means that the routing of your traffic to O365 could be sub optimal and thus affect performance. It's thankfully an easy one to check though and outlined further here.
10. Application Level troubleshooting
My final tip isn't so much with network troubleshooting but application layer. This blog post will give you some tips on how to look at Outlook and SharePoint in conjunction with network tracing to both baseline and troubleshoot application level issues even when the traffic is encrypted in an SSL session.
The blog post is here
I'll add more as and when I find them/get time, hope the first ten are of help!
Comments
- Anonymous
July 09, 2014
This is absolutely brilliant Paul. Thank you for putting this together. - Anonymous
July 10, 2014
Great post Paul !!! - Anonymous
February 25, 2015
test - Anonymous
April 10, 2015
Tästä on pitänyt kirjoittaa jo pidemmän aikaa, mutta parempi myöhään - Anonymous
April 20, 2015
Amazingly well written! Thank you so much Paul - Anonymous
May 19, 2015
Awesome blog...thank you very much. - Anonymous
October 01, 2015
Unbelievable.... Your article is practical and always based on Network....
Thank you so much. - Anonymous
November 12, 2015
Just Perfect Paul --- concise, direct and a useful resource - Anonymous
January 24, 2016
Thank you for sharing your tips and methodology. Just what we were looking for. Your TechNet 2014 talk was very useful too.
I like how this is generalised to networking, so it's very applicable to any SaaS application. - Anonymous
March 12, 2016
Paul this is critical info, and appreciate your efforts to put these details together. Thanks, Great Job! - Anonymous
October 26, 2016
The comment has been removed - Anonymous
April 21, 2017
Thanks for sharing - Anonymous
May 16, 2017
Very Detailed and too good.Thanks