The forgotten part of an Office 365 migration: Network Connectivity

Migrating an on premise email infrastructure to Office 365 is pretty straightforward; whether you have Exchange 2003 (even!), 2007, 2010 or 2013, lots of documentation and migration scenarios are available on the Web to make it a successful migration project. After popping the champagne when the first mailboxes moved successfully, the first complaints reach the service desk: the (Outlook) performance is getting slower and slower. What went wrong? Did we not follow all the procedures in the “Deployment Guides”?

The slow performance is probably related to Network Connectivity. But how can we solve this? The answer is not simple; it contains several important steps to optimize the network performance.

1. TCP Window Scaling:

To use a high bandwidth link efficiently, the connection must be filled with as much data as possible as quickly as possible. With a TCP Window Size limited to 64k when Window Scaling is disabled, not all the available bandwidth is used.

Increasing the Window Size beyond 64k, the sending machine can push more data onto the network before having to stop and wait for an acknowledgement from the receiver.

Check this setting on your network perimeter devices.

2. TCP Idle time settings:

Network Perimeter Devices (like firewalls) are normally designed for internet access to Web Pages. This means TCP Sessions were not expected to be idle for a long time. If there were any idle TCP Sessions, the firewall simply closed them. Users were not affected by this using web pages only, but now the situation is different: we’re using Outlook to connect to our Office 365 Mailbox. Outlook leaves TCP Sessions open for a period of time (as long as Outlook is open) and when the firewall kills the “idle” TCP connection, Outlook hangs, causes disconnect pop-ups or even prompts the user for a password.

Solving this problem, make sure the perimeter devices are configured consistently; keep the SSL/TCP idle Session Timeouts for “normal” traffic around 2-3 minutes, but create a separate group for Office 365 traffic and make sure the timeout for this group is higher than 2 hours (as Windows will send a keep alive by default after 2 hours).

3. Latency:

Latency is the time it takes for content to get from a server or service to your device and is measure in milliseconds. Faster is better. It can be caused by a number of factors, like low bandwidth, a sparse connection or transmission time.

Outlook connects to a Client Access Server in Exchange Online which redirects your request to the server where your mailbox is located. These datacenters are on high speed backbones, but you have to make sure your connection is taking the traffic as fast as possible to that datacenters with as low latency as possible at your site.

4. Proxy Authentication:

To ensure your Office 365 connections complete quickly is to check proxy authentication is completing quickly. Better is not to use a proxy at all!

If Proxy Authentication is required, at least make an exception for the Office 365 URL’s and applications:

  • Allow outbound connections to the following destination: *.microsoftonline.com
  • Allow outbound connections to the following destination: *.microsoftonline-p.com
  • Allow outbound connections to the following destination: *.sharepoint.com
  • Allow outbound connections to the following destination: *.outlook.com
  • Allow outbound connections to the following destination: *.lync.com
  • Allow outbound connections to the following destination: osub.microsoft.com
  • Ports 80/443
  • Protocols TCP and HTTPS
  • Rule must apply to all users.

5. DNS Performance:

If name resolution takes time, it results in a poorly performing Office 365 Infrastructure. Make sure your DNS servers are in the same region; for example, if you use “8.8.8.8” as your (external) DNS server, you might get the “wrong” result. Your request is pointed at the US servers first, which causes delays in the connection to the servers in your region.

office-365-migration-blog
office-365-migration-blog

6. TCP Max Segment Size:

Maximum Segment Size is a TCP level value which is the largest segment which can be sent on the link minus the headers. To obtain this value, take the IP level Maximum Transmission Unit (MTU) and subtract the IP and header size. A standard Ethernet Connection uses a packet size of 1500 bytes leaving us with an MSS of 1460 bytes. Ensure your TCP packets are able to contain the maximum amount of data possible. Low values will affect network performance.

7. Selective Acknowledgement:

TCP is a reliable protocol which ensure delivery of all data. It does this by the ACK’s indicating it’s received up to a certain point in the data stream. With SACK enabled, we’re able to tell the sender we’re missing a packet and which packets we already got. The sender can just retransmit the missing packet without sending the successive packets. This greatly increases the efficiency of the TCP protocol (it is enable by default in Windows). Check you network devices whether it is enabled or not.

Optimizing Network Connectivity is highly recommended to ensure to fully utilize the available network bandwidth and have the best performance possible for network traffic. If any of those resources are performing badly then the end customer is likely to experience poor performance.

By eliminating the above described topics in a random order, you'll ensure you are providing the best possible Office 365 experience for your users.