High performance network architecture for Office 365

High performance network architecture for Office 365

Microsoft recommends Direct Internet Access for Office 365

Microsoft’s cloud-based Office 365 has been embraced with open arms by organizations that want to get out of hosting and caring for the popular suite of productivity products.  As of March this year, the company reported it had more than 180 million commercial monthly active users.  Office 365 commercial revenue grew by 30% in that quarter while revenue for traditional Office commercial products declined by 19%.


But while the shift is on, a common gripe about the SaaS version of the product concerns application performance.  Migrating Office services and data from the data center to the cloud changes the planning and ongoing management calculus in ways that many organizations are not prepared for. 


“One of the most significant architectural features of Office 365 (that is often missed or misinterpreted by network planners),” Microsoft says, “is that it is a truly global distributed service, in the context of how users connect to it.”


In fact, Microsoft devotes plenty of resources to help organizations plan and deploy Office 365, so much so it gives you a sense of the effort involved and what can go wrong.  It isn’t as easy as updating clients and letting them rip.


Specifically, Microsoft recommends:

  • Routing all Office 365 traffic to the closest access point on the company’s global backbone.  While traditionally branch office traffic is backhauled to Head Quarters for various Web control and security functions, that adds too much latency for Office 365, especially in geographically distributed organizations.

  • Avoiding network hairpins for other packet inspection services, such as cloud access brokers, and “inadvertent connections to geographically distant endpoints,” all of which can bog down the network and increase latency.

To do either you need to be able to identify traffic to Office 365 endpoints, most of which are in Microsoft data centers.  As the company points out, “Office 365 endpoints represent a varied set of network addresses and subnets. Endpoints may be URLs, IP addresses or IP ranges, and some endpoints are listed with specific TCP/UDP ports. URLs can either be a FQDN like account.office.net , or a wildcard URL like *.office365.com.”  Microsoft offers a complete list here, and a REST-based Web service of IP addresses and FQDN entries here.

Microsoft Connectivity Principles.png

It's also important to note that Microsoft now categorizes the various types of endpoints into three buckets (it used to be two), some of which are more important to optimize for: 

  •  Optimize endpoints.  As the name implies, the items in this bucket are the most important to care for because they are the ones “most sensitive to network performance, latency and availability.”  And even though the number of them is relatively small – 10 or so -- they account for the most bandwidth: 75%. The good news: they don’t change much. Traffic to these endpoints should never be backhauled, should bypass proxy services, and given preferential treatment on the network. Optimize endpoints are dedicated to core Office 365 workloads such as Exchange Online, SharePoint Online, Skype for Business Online and Microsoft Teams. 

  •  Allow endpoints. Like Optimize endpoints, Allow items are all hosted in Microsoft data centers and are specific to certain Office 365 micro-services, “but are not as sensitive to network performance and latency as those in the Optimize category,” the company says. There are more of them – around 100 URLs – and they change more often.  Traffic to these endpoints can be backhauled, but it is not preferred, and should avoid deep packet inspection. 

  •  Default endpoints.  Only some of these are in Microsoft data centers and “do not require any optimization,” Microsoft says, “and can be treated by customer networks as normal Internet bound traffic” and even be backhauled if desired.


Given the obvious importance of handling Office 365 traffic to achieve adequate performance, you’re going to need tools that provide visibility into what is happening at HQ and each branch egress.  When help desk calls come in complaining about application performance, how do you tell if it is your instance of Office 365, a backbone access issue, a branch issue, a user issue, etc?


You’re also going to need a way to ensure Office 365 is routed correctly to safeguard against the problems Microsoft points out.  And, what’s more, you’ll need to ensure your finite network resources are allocated right to deliver optimal Office 365 user experiences.  The latter will involve the ability to shape bandwidth to ensure:

  • Office 365 gets the minimum resources required, even when other branch office traffic is ramping (large downloads and other bandwidth intensive services).

  • And keep Office 365 from becoming a bandwidth hog that impacts the performance of other critical business applications.  While Microsoft doesn’t talk about this concern, it is a real problem that enterprise shops have identified. Office 365 isn’t, after all, the only important application riding the network, and not the only popular SaaS tool, either.  The more organizations adopt cloud-based solutions, the more important it will be to have third party controls to manage the new ecosystem.


Finally, recognize the fact that all of Microsoft’s Office 365 recommendations are designed to help optimize the performance of the platform, but how success is actually measured is in user experience.  Avoiding the classic “all the lights are green but calls are flooding in” scenario requires being able to gauge that experience in a meaningful way and get out in front of issues before they escalate. Care should be taken when moving to Direct Internet Access to ensure you don't lose visibility into user experience and application performance.


Delivering on the performance promise of SD-WAN and Hybrid Networks