This chapter covers Microsoft 365 network connectivity principles, a core topic in the MS-900 exam under Cloud Concepts (Objective 1.2). Understanding how Microsoft 365 optimizes network traffic is critical because connectivity issues are among the most common deployment problems. Expect 5-10% of exam questions to touch on network principles, including optimization, endpoints, and split tunneling. This chapter provides the technical depth to answer scenario-based questions correctly.
Jump to a section
Imagine Microsoft 365 as a massive corporate headquarters with thousands of employees, each needing to send and receive mail. Your local office (your network) has a single mailroom (your internet connection) that handles all outgoing and incoming parcels. When an employee sends a letter to headquarters, the mailroom puts it in a company envelope (encapsulates the packet) and writes the return address as the mailroom's address (source NAT). The letter travels through various postal sorting centers (ISP networks) to reach headquarters. At headquarters, a giant mailroom (Microsoft's network edge) receives the letter, opens the company envelope, and delivers it to the correct employee (service). For the reply, the process reverses: headquarters puts the response in an envelope addressed to your mailroom, which then opens it and delivers to your employee. If your mailroom is slow or the address is wrong (poor connectivity or DNS), letters get lost or delayed. Just as a postal service relies on clear addresses, efficient sorting, and sufficient capacity, Microsoft 365 connectivity depends on proper DNS resolution, optimized routing, and adequate bandwidth. The analogy breaks if you think of the mailroom as a 'traffic cop' — it doesn't direct traffic; it encapsulates and translates.
What Are Microsoft 365 Network Connectivity Principles?
Microsoft 365 is a cloud-based productivity suite that includes Exchange Online, SharePoint Online, Teams, and more. Unlike traditional on-premises applications where traffic stays within a corporate LAN, Microsoft 365 traffic must traverse the internet to reach Microsoft's datacenters. The network connectivity principles define how to optimize this traffic for performance, reliability, and security.
Microsoft's network is one of the largest in the world, with over 200 edge points of presence (PoPs) in more than 100 cities, interconnected via a high-capacity private WAN. The goal is to get traffic from your network to Microsoft's network as quickly as possible, then onto Microsoft's private backbone.
Why Connectivity Principles Matter
Poor connectivity to Microsoft 365 leads to slow email, choppy Teams calls, and failed file uploads. The exam tests your understanding of how to optimize this connectivity without overcomplicating the network. The core principles are:
Identify and differentiate Office 365 traffic from general internet traffic.
Allow connectivity to all required endpoints (URLs and IP ranges) — no proxy intercept or SSL inspection for critical traffic.
Avoid hairpinning traffic through a central proxy or VPN — use direct egress from the user's location.
Optimize DNS resolution to direct users to the nearest Microsoft datacenter.
Provide sufficient bandwidth — but bandwidth is rarely the bottleneck; latency and packet loss matter more.
How Microsoft 365 Traffic Is Classified
Microsoft categorizes Office 365 traffic into three categories based on criticality and network sensitivity:
Optimize: Traffic that is most sensitive to network latency and packet loss. This includes Teams media (audio, video, screen sharing) and signaling. This traffic must bypass proxies and VPNs and be routed directly from the user's location to Microsoft's network. It is marked with DSCP values (46 for audio, 34 for video) to prioritize in QoS.
Allow: Traffic that is less sensitive but still critical for functionality. This includes Exchange Online, SharePoint Online, and some Teams traffic (e.g., file downloads). It should also bypass proxies and VPNs but can tolerate some delay.
Default: Traffic that can traverse the internet like any other. This includes portal pages, help content, and some non-critical services. This traffic can go through proxies and VPNs.
Key Endpoints and How They Are Published
Microsoft publishes the list of Office 365 URLs and IP ranges in the Office 365 IP Address and URL web service. This is a RESTful web service at https://endpoints.office.com. It returns JSON data that includes:
id: Unique identifier for the endpoint set.
serviceArea: The Microsoft 365 service (Exchange, SharePoint, Skype, Common, etc.).
urls: List of URLs/FQDNs.
ips: List of IP subnets (CIDR notation).
tcpPorts and udpPorts: Required ports.
category: Optimize, Allow, or Default.
expressRoute: Whether the endpoint supports ExpressRoute (some do, some don't).
Example request:
https://endpoints.office.com/endpoints/worldwide?clientrequestid=<guid>This web service updates monthly, and organizations should automate pulling updates to ensure firewall and proxy rules stay current.
Network Optimization Principles in Detail
#### 1. Egress from the User's Location
The most important principle is to egress Office 365 traffic from the user's location directly to the internet, not backhaul it to a central datacenter. For example, if a remote user in Singapore connects to a corporate VPN that terminates in the US, their Teams traffic goes Singapore -> US -> Microsoft datacenter (likely in Asia) -> US -> Singapore. This adds 200-300ms of latency, causing poor call quality. Instead, the user should egress directly from Singapore to the nearest Microsoft edge.
#### 2. Bypass Proxies and SSL Inspection
Proxies add latency and can break Office 365 traffic, especially Teams media. SSL inspection (decrypting and re-encrypting) adds significant latency and can cause certificate pinning issues. Microsoft recommends bypassing proxies for Optimize and Allow traffic. For Default traffic, proxy is acceptable.
#### 3. Use Split Tunneling for VPNs
When users connect via VPN, configure split tunneling so that Office 365 traffic goes directly to the internet, not through the VPN tunnel. This reduces latency and bandwidth load on the VPN concentrator.
#### 4. Optimize DNS Resolution
DNS resolves Office 365 hostnames to IP addresses. Microsoft uses DNS to direct users to the nearest datacenter based on the source IP of the DNS query. Therefore, DNS queries must come from the user's actual location, not from a centralized DNS server in another region. Use local recursive DNS resolvers or forwarders that are close to users.
#### 5. Provide Sufficient Bandwidth
Microsoft publishes bandwidth calculators for Exchange Online, SharePoint Online, and Teams. For Teams, the required bandwidth per call is:
Audio: 30-100 kbps (codec-dependent)
Video (720p): 500-800 kbps
Video (1080p): 1.2-1.5 Mbps
Screen sharing: 200-400 kbps
But bandwidth is rarely the issue; latency and packet loss (especially jitter) degrade Teams quality. Aim for <150ms round-trip latency and <1% packet loss.
ExpressRoute for Office 365
Azure ExpressRoute provides a private, dedicated connection to Microsoft's network, bypassing the public internet. However, for Office 365, ExpressRoute is optional and only recommended for specific scenarios (e.g., regulatory compliance, large data transfers). Most Office 365 traffic is designed to work well over the internet. ExpressRoute does not improve performance for users who are far from the ExpressRoute peering point. Also, not all Office 365 endpoints are available over ExpressRoute — only those with expressRoute: true in the endpoint data.
Network Ports and Protocols
Office 365 uses standard ports:
HTTPS (TCP 443) for most web traffic.
IMAP4 (TCP 143/993), SMTP (TCP 25/587), POP3 (TCP 110/995) for email clients.
SIP (TCP 443/5061) for Teams signaling.
UDP 3478-3481 for Teams media (audio/video).
UDP 50000-59999 for Teams media in some scenarios.
Verification and Troubleshooting
Microsoft provides tools to test connectivity: - Microsoft 365 Network Connectivity Test (https://connectivity.office.com): A browser-based tool that runs tests from the user's browser. - Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com): Tests mail flow, autodiscover, etc. - Microsoft 365 Admin Center > Health > Network connectivity: Shows aggregated network performance data from your tenant.
Common PowerShell commands for network testing:
Test-NetConnection -ComputerName outlook.office365.com -Port 443
Resolve-DnsName outlook.office365.comInteraction with Related Technologies
Azure AD Connect: Requires connectivity to Azure AD endpoints. Use the same optimization principles.
Microsoft Teams: Heavily dependent on UDP for media. Ensure UDP ports are open and not blocked.
Exchange Online: Uses HTTPS and SMTP. Autodiscover relies on DNS.
SharePoint Online: Uses HTTPS. File sync uses WebDAV or the OneDrive sync engine.
Common Misconfigurations
Blocking required endpoints due to overly restrictive firewall rules.
SSL inspection on Teams media traffic, causing certificate errors and high latency.
Centralized egress for remote users, adding unnecessary latency.
Incorrect DNS resolution that sends users to distant datacenters.
User Initiates Connection to Office 365
A user opens Outlook or Teams, which attempts to connect to its service. The client performs a DNS lookup for the FQDN (e.g., outlook.office365.com or teams.microsoft.com). The DNS resolver sends a query to the configured DNS server. If using a local recursive resolver, the query goes to the nearest Microsoft DNS server, which responds with the IP address of the closest datacenter based on the resolver's source IP. This is the first critical step: if DNS queries are forwarded to a remote server, the client may be directed to a distant datacenter, increasing latency.
Client Sends TCP Handshake to Microsoft Edge
The client initiates a TCP three-way handshake to the IP address returned by DNS, typically on port 443. The SYN packet travels through the local network, out the default gateway, and across the internet to Microsoft's nearest edge point of presence (PoP). Microsoft's edge routers accept the connection. The handshake completes with SYN-ACK and ACK. If the client is behind a NAT, the source IP is translated to the public IP of the firewall. This public IP determines which datacenter the traffic reaches — another reason to avoid central NAT.
TLS Handshake for Encrypted Communication
After TCP is established, the client and server perform a TLS handshake. The client presents the server name (SNI) to indicate which service it wants. Microsoft's edge terminates TLS at the PoP, not at the backend server. This allows the edge to inspect the SNI and route the request to the appropriate service. The client verifies the server certificate (issued by Microsoft). If an SSL inspection proxy is in use, it intercepts this handshake, presenting its own certificate. This can cause delays and certificate pinning failures. Microsoft recommends against SSL inspection for Optimize and Allow traffic.
Application Data Flow via HTTP/2 or WebSockets
Once TLS is established, the client sends application data. For Exchange Online, this is MAPI over HTTP or Outlook Anywhere (RPC over HTTP). For Teams, after initial signaling via HTTPS, the client negotiates a UDP media session. The client sends a SIP INVITE over HTTPS to the Teams service, which then provides the IP/port of the media relay (if needed). The client then sends UDP packets to that relay. The media path is optimized to be as direct as possible (peer-to-peer or through a Microsoft relay). Packet loss, jitter, and latency are monitored; if quality degrades, the client may switch codecs or route through a different relay.
Continuous Monitoring and Reconnection
During the session, both the client and Microsoft's services continuously monitor network quality. For Teams, the client reports metrics (packet loss, round-trip time, jitter) to the service every 30 seconds. If quality drops below thresholds (e.g., >10% packet loss for audio), the client may adjust codec bitrate, switch to a lower resolution video, or even drop the call. The service can also trigger a reconnection to a different datacenter if needed. For Exchange, if the connection drops, the client retries with exponential backoff (starting at 1 second, doubling up to 30 seconds). The client also performs periodic keep-alives (every 4 minutes by default) to maintain NAT bindings.
Enterprise Scenario 1: Global Company with Remote Workers
A multinational company with 10,000 employees spread across Europe, Asia, and North America deploys Microsoft 365. Initially, they forced all traffic through a central VPN hub in the US for security. Users in Asia experienced 300ms latency for Teams calls, causing frequent dropouts. The network team implemented split tunneling for Office 365 traffic (using the published endpoint list) and configured local DNS forwarders in each region. They also upgraded their internet circuits from 100 Mbps to 500 Mbps at each major office. After these changes, Teams call quality improved significantly, with latency dropping to 50-80ms. The key lesson: egress from the user's location is more impactful than bandwidth.
Enterprise Scenario 2: Financial Institution with Strict Security
A bank required all traffic to go through a proxy for inspection. Teams calls were failing with 'poor network quality' warnings. The proxy was performing SSL inspection on Teams media, adding 50ms of latency and causing certificate errors. The network team excluded Office 365 Optimize and Allow traffic from the proxy using WPAD (Web Proxy Auto-Discovery) PAC files. They also configured QoS on their WAN to mark Teams audio with DSCP 46. After these changes, call quality improved. The bank still inspected Default traffic through the proxy. This shows that security and performance can coexist with proper traffic classification.
Enterprise Scenario 3: Merger of Two Companies
After a merger, Company A and Company B had different network designs. Company A used ExpressRoute for Office 365, while Company B used internet. The merged entity had users in both legacy networks. They discovered that ExpressRoute did not improve performance for users far from the peering point. They also found that some SharePoint URLs were not available over ExpressRoute, causing failures for users on that path. They standardized on internet-based connectivity with optimized egress, saving costs and simplifying management. They retained ExpressRoute only for Azure IaaS workloads. This highlights that ExpressRoute is not a silver bullet for Office 365.
What MS-900 Tests on Network Connectivity Principles
The MS-900 exam (Objective 1.2: Describe cloud concepts) includes network connectivity principles under the broader topic of Microsoft 365 services and concepts. You will not be asked to configure network devices, but you must understand the principles and best practices. Expect 1-2 questions on:
Traffic categories (Optimize, Allow, Default)
Split tunneling and VPN recommendations
DNS optimization
ExpressRoute for Office 365 (when to use, limitations)
Required endpoints and ports (generic knowledge, not memorization)
Common Wrong Answers and Why Candidates Choose Them
'Use ExpressRoute for all Office 365 traffic to improve performance.' This is wrong because ExpressRoute does not improve performance for most users and is not recommended for all traffic. Candidates think 'private connection = faster', but the internet is already optimized for Office 365.
'Centralize all traffic through a corporate proxy for security.' This is wrong because proxies add latency and can break Teams media. Candidates prioritize security over performance, but Microsoft recommends bypassing proxies for critical traffic.
'Bandwidth is the most important factor for Teams quality.' This is wrong because latency and packet loss matter more. Candidates assume 'more bandwidth = better', but Teams can work well on low bandwidth if latency is low.
'SSL inspection is required for compliance.' This is wrong for Office 365 traffic because Microsoft's certificates are trusted and inspection adds complexity. Candidates think inspection is always necessary, but Microsoft advises against it for Optimize and Allow traffic.
Specific Numbers and Terms Appearing on the Exam
DSCP values: Audio = 46, Video = 34
Ports: UDP 3478-3481 for Teams media
Latency target: <150ms round-trip
Packet loss target: <1%
Endpoint categories: Optimize, Allow, Default
ExpressRoute: optional, not all endpoints supported
DNS: use local resolvers
Edge Cases and Exceptions
ExpressRoute and Office 365: Some endpoints are not available over ExpressRoute (e.g., some CDN URLs). Always check the endpoint web service.
Government clouds: For GCC, GCC High, and DoD, endpoints are different and ExpressRoute may be required.
Teams live events: Use different endpoints and may require higher bandwidth.
Guest users: Their connectivity depends on their own network, not your corporate network.
How to Eliminate Wrong Answers
If an answer suggests 'centralize all traffic', eliminate it.
If an answer says 'ExpressRoute is required', eliminate it.
If an answer mentions 'bandwidth as the sole factor', eliminate it.
Look for answers that mention 'direct egress', 'bypass proxy', 'split tunneling', 'local DNS'.
Office 365 traffic is categorized as Optimize, Allow, or Default based on sensitivity.
Optimize traffic (Teams media) must bypass proxies and VPNs to avoid latency.
Split tunneling is recommended for VPN users to egress Office 365 traffic directly.
DNS queries should originate from the user's location to reach the nearest datacenter.
ExpressRoute is optional for Office 365 and not all endpoints are supported.
Teams media uses UDP ports 3478-3481; audio DSCP 46, video DSCP 34.
Latency should be <150ms and packet loss <1% for good Teams quality.
The Office 365 IP and URL web service provides current endpoint lists.
SSL inspection of Optimize/Allow traffic is not recommended.
Bandwidth is less critical than latency for real-time communications.
These come up on the exam all the time. Here's how to tell them apart.
Optimize Traffic
Includes Teams media and signaling
Most sensitive to latency and packet loss
Must bypass proxies and VPNs
Marked with DSCP values (46, 34)
Recommended to egress directly from user location
Default Traffic
Includes portal pages and help content
Tolerant of higher latency
Can go through proxies and VPNs
No specific DSCP marking
Can be backhauled if necessary
Mistake
ExpressRoute is required for Office 365 to work well.
Correct
ExpressRoute is optional and not recommended for most Office 365 scenarios. Office 365 is designed to work over the internet. ExpressRoute adds cost and complexity without performance benefits for typical users. Only use it for specific compliance or large data transfer needs.
Mistake
SSL inspection of Office 365 traffic improves security.
Correct
SSL inspection adds latency and can break certificate pinning. Microsoft's certificates are already trusted. For Optimize and Allow traffic, bypass SSL inspection. Only Default traffic may be inspected if needed.
Mistake
All Office 365 traffic should go through a corporate VPN for security.
Correct
VPN backhaul adds latency and reduces performance. Use split tunneling to let Office 365 traffic egress directly from the user's location. The traffic is already encrypted with TLS. VPN is only needed for on-premises resources.
Mistake
Bandwidth is the most important factor for Teams call quality.
Correct
Latency and packet loss are more critical. Teams can handle low bandwidth (e.g., 100 kbps for audio) but degrades with high latency (>150ms) or packet loss (>1%). Prioritize low latency and jitter.
Mistake
You must memorize all Office 365 IP ranges and URLs for the exam.
Correct
The exam does not require memorization. You need to know that the list exists, how to access it (web service), and that it updates regularly. Focus on principles, not specific addresses.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The three categories are Optimize, Allow, and Default. Optimize includes Teams media and signaling – most sensitive to network issues. Allow includes Exchange and SharePoint traffic – less sensitive but still critical. Default includes portal and help content – can tolerate standard internet connectivity. The exam tests which traffic should bypass proxies (Optimize and Allow).
Only if you have specific compliance or performance requirements that cannot be met over the internet. For most organizations, internet-based connectivity is sufficient and recommended. ExpressRoute does not improve performance for users far from the peering point. Also, not all Office 365 endpoints are available over ExpressRoute. Check the endpoint web service for the 'expressRoute' field.
Split tunneling prevents Office 365 traffic from being backhauled through the VPN concentrator, which adds latency. By allowing direct egress from the user's location, latency is minimized and bandwidth on the VPN is preserved. This is especially important for Teams media, which is sensitive to delay. Configure split tunneling using the published endpoint list.
Teams media (audio, video, screen sharing) uses UDP ports 3478 through 3481. These must be open on firewalls for peer-to-peer and relay connections. Additionally, TCP 443 is used for signaling. Ensure these ports are not blocked or throttled. UDP is preferred for real-time media because it avoids TCP retransmission delays.
Use the Office 365 IP Address and URL web service at https://endpoints.office.com. You can query it programmatically with a REST GET request. The data is in JSON format and includes IDs, service areas, URLs, IPs, ports, categories, and ExpressRoute support. Microsoft updates it regularly, so automate your firewall rules to pull from this source.
Optimize traffic is most sensitive to latency and packet loss (e.g., Teams media) and must bypass proxies and VPNs. Allow traffic is less sensitive (e.g., email, SharePoint) but still critical; it should also bypass proxies but can tolerate some delay. Default traffic (e.g., portal pages) can go through proxies. The exam tests this distinction.
No, not for Optimize and Allow traffic. Proxies add latency and can break Teams media due to SSL inspection and buffering. Microsoft recommends bypassing proxies for these categories. Default traffic can go through a proxy. Use PAC files or firewall rules to exclude Optimize and Allow traffic from the proxy.
You've just covered Microsoft 365 Network Connectivity Principles — now see how well it sticks with free MS-900 practice questions. Full explanations included, no account needed.
Done with this chapter?