New Office 365 URL categories to help you optimize the traffic which really matters


3rd April 2018

As part of the improvements Microsoft have recently announced to the way the required URLs and IPs for Office 365 are published, we have also changed how the URLs are categorized to help customers deliver best practice in terms of connecting to the required endpoints for the service.

In the current system, URLs are marked "Required" and "Optional" with a very large list of URLs in each category.

Traditionally Microsoft have always advised that customers optimize connectivity to Office 365 for the "required" endpoints. That often means, not using traditional proxy methods at the network edge due to the bottlenecks which commonly occur at this point. This is often due to the load Office 365 puts on these devices. In addition, the work often done at this layer such as SSL inspection for AV scanning or DLP which is often replicated in the application/service itself when it comes to Office 365 endpoints. Proxying traffic also often means Skype must use TCP for voice/media calls as opposed to its preferred method of using UDP directly, with an all too common drop in performance. More on the challenges with using traditional proxies for SaaS services like Office 365 can be found in another of my blog posts.

The difficulty with this categorization of the URLs (Required & Optional) is that applying this advice has become increasingly difficult for customers as the Office 365 service has grown. The number of endpoints in the "Required" list is now considerable, and the fact some do not live on Microsoft infrastructure (eg CDNs) for which we do not provide IPs for, and a customer may understandably want to apply SSL inspection on some of these endpoints due to the number and differing nature of them. It's also hard to correlate which URLs have which security features (such as AV scanning/DLP) applicable to it within the service, and thus don't require it at the network edge. The net result is that often key Office 365 traffic ends up being sent via an unoptimized path and encounters performance issues as a result, or it is a large challenge to optimize the full list of endpoints.

We therefore set about a piece of work to analyze all the URLs for the service and identify those which really require optimization to enable customers to focus on the traffic which really requires special consideration, i.e. those which are either very high volume in terms of bandwidth/transactions/connection count and thus put heavy load on proxies, or those which are particularly latency sensitive and require the direct path with minimal interference, for example Skype voice traffic.

This piece of work showed that a very small number actually require the highest levels of optimization, in the order of around 10 endpoints. This small list however accounts for 75-90% of Office 365 Bandwidth, connection and transaction count. These core endpoints are those which will put massive load on traditional proxy infrastructure and/or require that optimized path a direct egress best provides.

With this small list in mind, we can now work around the problem with traditional egress models in a much more precise manner, by concentrating on optimizing the URLs which both cause the problem (in terms of load) and also are the biggest victims of it in terms of performance.

We have therefore categorized the URLs into the following three categories to help customers deal with the endpoints in specific ways according to the needs of the endpoint and the business.

 

  • Optimize for a small number of endpoints that require low latency unimpeded connectivity which should bypass proxy servers, network SSL break and inspect devices, and network hairpins.
  • Allow for a larger number of endpoints that benefit from low latency unimpeded connectivity. Although not expected to cause failures, we also recommend bypassing proxy servers, network SSL break and inspect devices, and network hairpins. Good connectivity to these endpoints is required for Office 365 to operate normally.
  • Default for other Office 365 endpoints which can be directed to the default internet egress location for the company WAN.

 

Use of these categories, how they simplify connectivity to Office 365, and what actions you can take to make use of them is detailed in Office 365 Network Connectivity Principles.

 

Optimize Category

 

URLs in the Optimize category all have the following characteristics:

 

  • Are Microsoft owned and managed endpoints located on Microsoft infrastructure.
  • Have IPs provided
  • Are routable via ExpressRoute (If the circuit is authorized for this type of route).
  • Are High volume and/or latency sensitive
  • URLs in this list shouldn't change on a regular basis (IPs are likely to)

 

The Optimize list at the time of publishing is outlined below.

 

Endpoint to Optimize

Port/s

Use

https://outlook.office365.com

TCP 443

This is one of the Core URLs Outlook uses to connect to its Exchange Online server and has high volume of bandwidth usage and connection count. Low network latency is required for online features including: Instant search, Other mailbox calendars, Free / busy lookup, manage rules & alerts, Exchange online archive, Emails departing the outbox.

https://outlook.office.com

TCP 443

This is use for Outlook Online web access to connect to its Exchange Online server and network latency. Connectivity is particularly required for large file upload and download with SharePoint Online.

https://<tenant>.sharepoint.com

TCP 443

This is the primary URL for SharePoint Online and has high volume of bandwidth usage.

https://<tenant>-my.sharepoint.com

TCP 443

This is the primary URL for OneDrive for Business and has high volume of bandwidth and possibly high connection count from the OneDrive for Business Sync tool.

Skype for Business Media IPs (no URL)

UDP 3478, 3479, 3480, and 3481

Relay Discovery allocation and real time traffic (3478), Audio (3479), Video (3480), and Video Screen Sharing (3481). These are the endpoints used for Skype for Business and Microsoft Teams Media traffic (Calls, meetings etc). Most endpoints are provided when the Skype for Business client or the Microsoft Teams client establishes a call (and are contained within the required IPs listed for the service). Skype for Business today requires DNS lookup for *.lync.com for this to work. UDP is required for optimal media quality.

  

 

The above (optimize) endpoints will require access to the following IP address ranges:

 

Moving forward, this information will be available from the new provisioning system (currently in preview) and the following scripts will obtain this information for you using the latest data.

  • *Im still ironing out a few kinks in these scripts so please check back shortly.

Remember that the service these scripts pull from is currently in preview and whilst we aim to ensure accuracy of the data, there is no 100% guarantee until the service is in production, so it's worth double checking the IP ranges against the URL & IP page.

For all customers, the advice is that, for the endpoints noted above, where possible:

  • If proxies are in use, send the above URLs direct in the PAC file and allow a direct path through a firewall/NAT which has an allow list for the IPs and Ports listed.
  • Ensure devices and paths handling this traffic can scale to handle the demand in terms of port requirements and bandwidth.
  • Bypass or whitelist these URLs on network devices which do SSL decryption, DPI or content filtering, or any other interference of the traffic which could delay it. Look at applying the security elements your require, for these endpoints, within the service and thus allow the traffic out of the network without hindrance.
  • Egress these endpoints as close as possible to the users so the traffic can hit Microsoft's infrastructure locally.
  • For remote users ensure these endpoints are sent direct via split tunnelling if VPN solutions are used
  • Ensure that DNS resolution for these endpoints is done at the same location as the egress path

The advantage of the above list is we can send a customer's specific, and high-volume OneDrive/SharePoint traffic (tenantname.sharepoint.com & tenantname-my.sharepoint.com) direct, and apply DLP in the service if required, whilst sending any other tenant traffic (*.sharepoint.com) which may be required for sharing/collaboration, via an inspecting proxy.

Whilst most customers do not require it, if strict control of which tenants are accessible then tenant restrictions can be implemented to control which tenants can be accessed from within the corporate network.

By optimizing this list of endpoints, you can ensure that the traffic which is likely to put the most load on your network infrastructure, and/or is latency sensitive is treated in such a way that the service performs at its best, whilst removing the risk of overloading your standard network egress.

 

Allow Category

Access to the URLs marked as 'Allow' are required for Office 365 to function, however they are not as sensitive to network performance and latency as those marked as 'Optimize'. The amount of bandwidth these endpoints will consume is a small proportion of the whole figure and also connection counts will be lower than the optimize category.

Allow endpoints have the following characteristics:

  • Are required for the service to function
  • Are not as highly sensitive to network performance as the optimize category
  • Are not comparatively high bandwidth or connection count endpoints
  • Higher rate of change than the optimize category
  • Not all endpoints in this category will have IPs provided

Whilst these endpoints are required for the services to work and aren't as sensitive as the Optimize URLs, they still are critical to the running of the service. A heavy delay to connectivity to one of these endpoints could cause performance issues for users. As such it is recommended that these URLS are optimized as far as possible.

Recommended advice in an ideal situation is as follows:

  • If possible, bypass or whitelist Allow endpoints on network devices and services that perform traffic interception, SSL decryption, deep packet inspection and content filtering. If it is not possible to bypass these URLs, ensure the work is as light touch as possible, and on optimized, well scaled devices which minimize any delay.
  • If proxying this traffic, ensure proxy authentication for these URLs is disabled to remove any delay that may cause.
  • If possible, prioritize the evaluation of these endpoints as fully trusted by your network infrastructure and perimeter systems.
  • Egress these endpoints as close as possible to the users so the traffic can hit Microsoft's infrastructure locally.
  • Ensure that DNS resolution for these endpoints is done at the same location as the egress path
  • Prioritize these endpoints for SD-WAN integration for direct, minimal latency routing into the nearest Internet peering point of the Microsoft global network.

     

    I'm also working on scripts to display this category in the right way, check back here for updates.

     

    Default Category

     

    This final category represents endpoints for Office 365 services and dependencies that do not require any optimization and can be treated by customer networks as normal Internet bound traffic.

     

    • Some endpoints in this category may not be hosted in Microsoft datacenters.
    • Some endpoints in this category may not have IPs provided for them (so require a proxy or other unrestricted path)

       

    Im also working on scripts to display this category, check back here for updates.

     

    Hopefully this new categorization helps your organisation to simplify the connectivity requirements for the Office 365 service by optimizing the core endpoints which really require it. Please leave your feedback for this feature at the Tech Community site where we have our official information available.

    Paul


Comments (0)

Skip to main content