Office 365 URL categories to help you optimize the network traffic which really matters
Updated 21st May April 2019
As part of the improvements Microsoft announced in 2018 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 old system, URLs are marked "Required" and "Optional" with a very large list of URLs in each category, published via an XML file.
Traditionally Microsoft 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 that in most cases, Skype for Business or Teams uses TCP for voice/media calls as opposed to its preferred method of using UDP directly, with a very likely drop in performance and quality. 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 considerable and in addition, some do not reside on Microsoft infrastructure (eg CDNs) which we therefore do not provide IPs for. A customer may therefore 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 hosted on Microsoft infrastructure.
- Have IPs provided
- Are routable via ExpressRoute (If the circuit is authorized for this type of traffic).
- Expected to remain low in number of URLs
- Are High volume and/or latency sensitive
- Low rate of change to URLs/IPs compare to other two categories
The Optimize list at the time of publishing is outlined below.
Endpoint to Optimize |
Port/s |
Use |
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. |
|
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. |
|
TCP 443 |
This is the primary URL for SharePoint Online and has high volume of bandwidth usage. |
|
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) |
TCP 443 & 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:
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 dedicated to Office 365 and hosted in Microsoft datacenters.
- 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.
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)
The information discussed above is be available from the new Web Service and I have published a script which will obtain this information for you using the latest data. Microsoft official script information can be found here.
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
- Anonymous
January 30, 2019
Good article, Paul. Just wondering though if you have any updates for the 'Allow Category' and 'Default Category' ?- Anonymous
February 06, 2019
Hi, I should have some scripts to query the categories and create PAC files published via here in the next couple of days so check back soon!
- Anonymous