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).
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 “22.214.171.124” 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.