Planning and Optimizing Network Connectivity for Office 365

Office 365 being a cloud hosted SaaS platform that is accessed through the Internet, requires an optimal network design to ensure acceptable performance.  In addition, with O365 services handling critical corporate applications such as E-mail (Exchange Online), Content (SharePoint Online), Communications (Skype for Business) etc., it is important for network administrators to create a “O365 Network Connectivity/Optimization Plan”. The focus of the plan is to evaluate the existing network infrastructure and recommend updates to optimize network connectivity between critical O365 services and corporate users. Some of the key factors worth considering during network planning for Office 365 are

  1. Network Connectivity and Routing of Office 365 services
  2. Network Latency
  3. Network egress model for connecting Office 365 within corporate network

In SaaS applications such as Office 365, application performance is heavily dependent on latency of the network connection.  Network Latency is defined as the observed time delay, as data transmits from one point to another.

In this blog, I illustrate some of the factors that affect network latency and need to be considered when planning networking for Office 365.

Microsoft’s Global Network:

Over the years, Microsoft has built one of the largest network of data centers and WAN backbones in the world. The resulting network is capable of high bandwidth (multi-Terabit) and low latency connections between thousands of miles of privately owned dark fiber connecting the data centers and the data centers with the edge nodes.

Figure 1: Microsoft’s Global Network (Courtesy: Microsoft)

This network is designed to allow the different Office 365 services to achieve acceptable performance and scalability from anywhere in the world irrespective of the region where the data is located.

Suggestion: When planning an Office 365 implementation, IT managers need to focus on ensuring that the corporate’s Office 365 traffic spends the least amount of time on the internet before the ISP hands it to Microsoft’s network. In addition, reducing the number of network hops required to reach Microsoft’s network also helps in improving network latency. In addition, I also recommend reading the blog by Paul Collinge that explains the importance of a Localized Network Egress  and it effect on application performance.

The two most common egress models for connecting machines from inside the corporate network to Office 365 services are

  1. Proxied Access
  2. Direct Routing

Proxied Access

It involves the use of a proxy server as an intermediary between clients within the corporate network and external resources. Today, most companies use web proxies to facilitate access to content on the Internet. The advantages of using a proxy server to handle external web requests is that it simplifies the connectivity process and enables centralized management of internet access within the corporate network.

The Proxy server is generally located at the egress and connects the internal machine to external sources on behalf of the requestor. The connection is managed established as two TCP connections

  1. Client to Proxy
  2. Proxy to Endpoint

This allows the proxy server to

  1. Intercept  network traffic for additional processing
  2. Inspect traffic for malicious code
  3. Change or deny requests

Proxied connections offer many advantages such as ease of configuration, monitoring, restricts traffic to small number of IP addresses and ports for easy firewall traversal etc.

However, when using a SaaS platform such as O365, there are some downsides to using Proxied connections

  1. Proxies generally do not handle UDP traffic. (affects call quality in Skype)
  2. As the proxy is a “man in the middle”, it could lead to potential SSL issues
  3. Issues with scalability and performance as proxy servers are generally not designed /configured with SaaS services in mind.

In case a proxy server absolutely needs to be used, suggest doing the following

  1. Ensure the configuration of the proxy devices are reviewed and fine-tuned to support SaaS services.
  2. Avoid using centralized proxies as they tend to increase latency
  3. Ensure that the point of local ingress with Microsoft’s network is located in the same region where the client is located
  4. Avoid routing Skype for Business traffic through these devices even when optimized

Direct Routing:

Clients connect with Office 365 services directly through a dynamic Network/Port Address Translation (NAT/ PAT) devices located at the egress of the corporate network. The NAT/PAT changes the internal IP and/or port to a public one. The Office 365 endpoint receives the public IP address used for NAT/PAT.

The advantages of using direct routing are as follows

  1. Supports the handling of direct UDP traffic, optimizing it for use with Skype
  2. Improves latency as it allows for local egress
  3. Optimizing connectivity with Office 365 services as there is either no or minimal interference with payload at egress

Some of the disadvantages of using direct routing when compared to Proxied routing is as follows

  1. Routing to the appropriate egress needs to be managed internally
  2. Need to authorize all Office 365 endpoints and ports on all firewalls
  3. Continuously monitor any changes to IP ranges, Urls or ports used by Office 365 (they rarely change). However, failure to update the firewall settings with any IP/ ports changes can result in connectivity issues. This could be a challenge to larger organizations.

ExpressRoute  is another option for connecting with Office 365 services. It is essentially direct routing via another path involves private peering with Microsoft network. The current guidance from Microsoft is that “ExpressRoute is not required or recommended for Office 365 except in a small number of situations”. If you plan on leveraging Azure ExpressRoute for your Office 365 implementation,  a review by Microsoft is required before it can be approved.  Additional details on leveraging ExpressRoute for Office 365 can be found here.

I would also recommend reading Paul’s blog post on the importance of unhindered access to endpoints for O365 services