Microsoft 365 network connectivity principles
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/microsoft-365-docs · commit 2a3a8af · +11 −11 lines · also on GitHub
⋯ 61 unchanged lines
6262
6363
:::image type="content" source="../media/621aaec9-971d-4f19-907a-1ae2ef6d72fc.png" alt-text="Identify Microsoft 365 traffic.":::
6464
65
−Identifying Microsoft 365 network traffic is the first step in being able to differentiate that traffic from generic Internet-bound network traffic. Microsoft 365 connectivity can be optimized by implementing a combination of approaches like network route optimization, firewall rules, browser proxy settings. Additionally, bypassing of network inspection devices for certain endpoints is also beneficial.
65
+Identifying Microsoft 365 network traffic is the first step in being able to differentiate that traffic from generic internet-bound network traffic. Microsoft 365 connectivity can be optimized by implementing a combination of approaches like network route optimization, firewall rules, browser proxy settings. Additionally, bypassing of network inspection devices for certain endpoints is also beneficial.
6666
6767
For more information on Microsoft 365 optimization methods, see the [optimizing connectivity to Microsoft 365 services](#BKMK_OptmizeConnectivity) section.
6868
⋯ 4 unchanged lines
7373
7474
:::image type="content" source="../media/b42a45be-1ab4-4073-a7dc-fbdfb4aedd24.png" alt-text="Egress network connections locally.":::
7575
76
−Local DNS and Internet egress is of critical importance for reducing connection latency and ensuring that user connections are made to the nearest point of entry to Microsoft 365 services. In a complex network topology, it's important to implement both local DNS and local Internet egress together. For more information about how Microsoft 365 routes client connections to the nearest point of entry, see the article [Client Connectivity](https://support.office.com/article/client-connectivity-4232abcf-4ae5-43aa-bfa1-9a078a99c78b).
76
+Local DNS and internet egress is of critical importance for reducing connection latency and ensuring that user connections are made to the nearest point of entry to Microsoft 365 services. In a complex network topology, it's important to implement both local DNS and local internet egress together. For more information about how Microsoft 365 routes client connections to the nearest point of entry, see [assessing network connectivity](assessing-network-connectivity.md).
7777
78
−Prior to the advent of cloud services such as Microsoft 365, end-user Internet connectivity as a design factor in network architecture was relatively simple. When Internet services and web sites are distributed around the globe, latency between corporate egress points and any given destination endpoint is largely a function of geographical distance.
78
+Prior to the advent of cloud services such as Microsoft 365, end-user internet connectivity as a design factor in network architecture was relatively simple. When internet services and web sites are distributed around the globe, latency between corporate egress points and any given destination endpoint is largely a function of geographical distance.
7979
80
−In a traditional network architecture, all outbound Internet connections traverse the corporate network, and egress from a central location. As Microsoft's cloud offerings have matured, a distributed Internet-facing network architecture has become critical for supporting latency-sensitive cloud services. The Microsoft Global Network was designed to accommodate latency requirements with the Distributed Service Front Door infrastructure, a dynamic fabric of global entry points that routes incoming cloud service connections to the closest entry point. This is intended to reduce the length of the "last mile" for Microsoft cloud customers by effectively shortening the route between the customer and the cloud.
80
+In a traditional network architecture, all outbound internet connections traverse the corporate network, and egress from a central location. As Microsoft's cloud offerings have matured, a distributed internet-facing network architecture has become critical for supporting latency-sensitive cloud services. The Microsoft Global Network was designed to accommodate latency requirements with the Distributed Service Front Door infrastructure, a dynamic fabric of global entry points that routes incoming cloud service connections to the closest entry point. This is intended to reduce the length of the "last mile" for Microsoft cloud customers by effectively shortening the route between the customer and the cloud.
8181
82
−Enterprise WANs are often designed to backhaul network traffic to a central company head office for inspection before egress to the Internet, usually through one or more proxy servers. The following diagram illustrates such a network topology.
82
+Enterprise WANs are often designed to backhaul network traffic to a central company head office for inspection before egress to the internet, usually through one or more proxy servers. The following diagram illustrates such a network topology.
8383
8484
:::image type="content" source="../media/fc87b8fd-a191-47a7-9704-1e445599813a.png" alt-text="Traditional enterprise network model.":::
8585
86
−Because Microsoft 365 runs on the Microsoft Global Network, which includes front-end servers around the world, there's often a front-end server close to the user's location. By providing local Internet egress and by configuring internal DNS servers to provide local name resolution for Microsoft 365 endpoints, network traffic destined for Microsoft 365 can connect to Microsoft 365 front end servers as close as possible to the user. The following diagram shows an example of a network topology that allows users connecting from main office, branch office, and remote locations to follow the shortest route to the closest Microsoft 365 entry point.
86
+Because Microsoft 365 runs on the Microsoft Global Network, which includes front-end servers around the world, there's often a front-end server close to the user's location. By providing local internet egress and by configuring internal DNS servers to provide local name resolution for Microsoft 365 endpoints, network traffic destined for Microsoft 365 can connect to Microsoft 365 front end servers as close as possible to the user. The following diagram shows an example of a network topology that allows users connecting from main office, branch office, and remote locations to follow the shortest route to the closest Microsoft 365 entry point.
8787
8888
:::image type="content" source="../media/4d4c07cc-a928-42b8-9a54-6c3741380a33.png" alt-text="WAN network model with regional egress points.":::
8989
⋯ 20 unchanged lines
110110
111111
As a general rule of thumb, the shortest, most direct route between user and closest Microsoft 365 endpoint offers the best performance. A network hairpin happens when WAN or VPN traffic bound for a particular destination is first directed to another intermediate location (such as security stack, cloud access broker, or cloud-based web gateway), introducing latency and potential redirection to a geographically distant endpoint. Network hairpins are also caused by routing/peering inefficiencies or suboptimal (remote) DNS lookups.
112112
113
−To ensure that Microsoft 365 connectivity isn't subject to network hairpins even in the local egress case, check whether the ISP that is used to provide Internet egress for the user location has a direct peering relationship with the Microsoft Global Network in close proximity to that location. You might also want to configure egress routing to send trusted Microsoft 365 traffic directly. This is as opposed to proxying or tunneling through a third-party cloud or cloud-based network security vendor that processes your Internet-bound traffic. Local DNS name resolution of Microsoft 365 endpoints helps to ensure that in addition to direct routing, the closest Microsoft 365 entry points are being used for user connections.
113
+To ensure that Microsoft 365 connectivity isn't subject to network hairpins even in the local egress case, check whether the ISP that is used to provide internet egress for the user location has a direct peering relationship with the Microsoft Global Network in close proximity to that location. You might also want to configure egress routing to send trusted Microsoft 365 traffic directly. This is as opposed to proxying or tunneling through a third-party cloud or cloud-based network security vendor that processes your internet-bound traffic. Local DNS name resolution of Microsoft 365 endpoints helps to ensure that in addition to direct routing, the closest Microsoft 365 entry points are being used for user connections.
114114
115115
If you use cloud-based network or security services for your Microsoft 365 traffic, ensure that the result of the hairpin is evaluated and its effect on Microsoft 365 performance is understood. This can be done by examining the number and locations of service provider locations through which the traffic is forwarded in relationship to number of your branch offices and Microsoft Global Network peering points, quality of the network peering relationship of the service provider with your ISP and Microsoft, and the performance effect of backhauling in the service provider infrastructure.
116116
⋯ 6 unchanged lines
123123
124124
Enterprise customers should review their network security and risk reduction methods specifically for Microsoft 365 bound traffic and use Microsoft 365 security features to reduce their reliance on intrusive, performance impacting, and expensive network security technologies for Microsoft 365 network traffic.
125125
126
−Most enterprise networks enforce network security for Internet traffic using technologies like proxies, TLS inspection, packet inspection, and data loss prevention systems. These technologies provide important risk mitigation for generic Internet requests but can dramatically reduce performance, scalability, and the quality of end user experience when applied to Microsoft 365 endpoints.
126
+Most enterprise networks enforce network security for internet traffic using technologies like proxies, TLS inspection, packet inspection, and data loss prevention systems. These technologies provide important risk mitigation for generic internet requests but can dramatically reduce performance, scalability, and the quality of end user experience when applied to Microsoft 365 endpoints.
127127
128128
<a name="BKMK_WebSvc"> </a>
129129
#### Microsoft 365 Endpoints web service
130130
131
−Microsoft 365 administrators can use a script or REST call to consume a structured list of endpoints from the Microsoft 365 Endpoints web service and update the configurations of perimeter firewalls and other network devices. This ensures that traffic bound for Microsoft 365 is identified, treated appropriately and managed differently from network traffic bound for generic and often unknown Internet web sites. For more information on how to use the Microsoft 365 Endpoints web service, see the article [Microsoft 365 URLs and IP address ranges](urls-and-ip-address-ranges.md).
131
+Microsoft 365 administrators can use a script or REST call to consume a structured list of endpoints from the Microsoft 365 Endpoints web service and update the configurations of perimeter firewalls and other network devices. This ensures that traffic bound for Microsoft 365 is identified, treated appropriately and managed differently from network traffic bound for generic and often unknown internet web sites. For more information on how to use the Microsoft 365 Endpoints web service, see the article [Microsoft 365 URLs and IP address ranges](urls-and-ip-address-ranges.md).
132132
133133
#### PAC (Proxy Automatic Configuration) scripts
134134
<a name="BKMK_WebSvc"> </a>
135135
136
−Microsoft 365 administrators can create PAC (Proxy Automatic Configuration) scripts that can be delivered to user computers via WPAD or GPO. PAC scripts can be used to bypass proxies for Microsoft 365 requests from WAN or VPN users, allowing Microsoft 365 traffic to use direct Internet connections rather than traversing the corporate network.
136
+Microsoft 365 administrators can create PAC (Proxy Automatic Configuration) scripts that can be delivered to user computers via WPAD or GPO. PAC scripts can be used to bypass proxies for Microsoft 365 requests from WAN or VPN users, allowing Microsoft 365 traffic to use direct internet connections rather than traversing the corporate network.
137137
138138
For more information on using PAC files to optimize network connectivity on client devices, see [Managing Microsoft 365 endpoints](managing-office-365-endpoints.md#use-a-pac-file-for-direct-routing-of-vital-microsoft-365-traffic).
139139
⋯ 92 unchanged lines
232232
233233
| Optimization method | Description | Impact |
234234
|:-----|:-----|:-----|
235
−|Local DNS resolution and Internet egress |Provision local DNS servers in each location and ensure that Microsoft 365 connections egress to the Internet as close as possible to the user's location. | Minimize latency <br/> Improve reliable connectivity to the closest Microsoft 365 entry point |
235
+|Local DNS resolution and internet egress |Provision local DNS servers in each location and ensure that Microsoft 365 connections egress to the internet as close as possible to the user's location. | Minimize latency <br/> Improve reliable connectivity to the closest Microsoft 365 entry point |
236236
|Add regional egress points |If your corporate network has multiple locations but only one egress point, add regional egress points to enable users to connect to the closest Microsoft 365 entry point. | Minimize latency <br/> Improve reliable connectivity to the closest Microsoft 365 entry point |
237237
|Bypass proxies and inspection devices |Configure browsers with PAC files that send Microsoft 365 requests directly to egress points. <br/> Configure edge routers and firewalls to permit Microsoft 365 traffic without inspection. | Minimize latency <br/> Reduce load on network devices |
238238
|Enable direct connection for VPN users |For VPN users, enable Microsoft 365 connections to connect directly from the user's network rather than over the VPN tunnel by implementing split tunneling. | Minimize latency <br/> Improve reliable connectivity to the closest Microsoft 365 entry point |
⋯ 16 unchanged lines
Microsoft's Markdown source from MicrosoftDocs/microsoft-365-docs, © Microsoft Corporation, under CC BY 4.0. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 10 Oct 05:34 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.