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 (13)

  1. Michelle Devon says:

    This is absolutely brilliant Paul. Thank you for putting this together.

  2. Shakthiravi says:

    Great post Paul !!!

  3. Anonymous says:

    Tästä on pitänyt kirjoittaa jo pidemmän aikaa, mutta parempi myöhään

  4. G says:

    Amazingly well written! Thank you so much Paul

  5. Martin Ferguson says:

    Awesome blog…thank you very much.

  6. Huy Phạm says:

    Unbelievable…. Your article is practical and always based on Network….

    Thank you so much.

  7. Terrie Zimmerman says:

    Just Perfect Paul — concise, direct and a useful resource

  8. JRPritchard says:

    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.

  9. a3bplus says:

    Paul this is critical info, and appreciate your efforts to put these details together. Thanks, Great Job!

  10. Parm says:

    This sorted our Office 365 Speed issue out as it was down to DNS Geo Location.

    Thanks!!

  11. Vinod says:

    Very Detailed and too good.

    Thanks

Skip to main content