Export (0) Print
Expand All

Plan networking and naming services for Office 365


Applies to: Office 365 Enterprise

Topic Last Modified: 2015-04-27

We're listening to your feedback and consolidating all our Office 365 deployment content. On July 1st, 2015, all information in this guide will be moved to https://support.office.com/, and these pages will be removed from TechNet. As you review the content still on TechNet, you'll notice many have links pointing to the new content already on https://support.office.com/.

To explore content available on https://support.office.com/, start with the Office 365 for business - Admin Help page.

This article is moving, please update your bookmarks to Network planning and performance tuning for Office 365

This section of the Deployment Guide presents key planning considerations about Office 365 domain and DNS records configuration, network bandwidth and latency, network ports and protocols, and Secure Socket Layer (SSL) certificates.

Your organization must plan in advance for:

  • Configuration of internal and external (Internet-facing) DNS records

  • Testing name resolution to ensure that it’s functioning properly

  • Provide the appropriate Internet bandwidth for the services you select when you migrate data to the Office 365 data centers

Office 365 requires that specific ports and protocols be accessible to support the use of online services and migration tools. Use of third-party SSL certificates is required to secure your organization’s Office 365 deployment.

These network considerations come from feedback and lessons learned during many Office 365 deployments. Evaluate these considerations independently against your network environment to see if they apply:

  • Proxy server and firewall devices need to be properly sized. Many of these devices that customers have aren’t sized for the additional traffic that Office 365 creates. Verify that the Internet traffic and the additional overhead to protect that traffic are included in the sizing calculation. Ensure the overhead for the following traffic protection mechanisms are included in your calculations:

    • Increased intrusion/virus detection on these devices creates overhead.

    • Increased SSL traffic on these devices creates overhead.

    For more information and useful tools, see Plan for network devices that connect to Office 365 services and Plan for Internet bandwidth usage for Office 365.

  • Turn off user authentication on the Internet proxy or firewall. Authentication can slow or block connections. When using a hybrid server, Forefront Threat Management Gateway (TMG) has known issues when preauthorization is enabled. For more information, see How to Configure TMG for Office 365 (Exchange) Hybrid deployments.

  • Evaluate the customer’s network to determine if all the network devices between client computers and Office 365 are configured properly. Is the Maximum Transmission Unit (MTU) size correct for all their network devices? Search for black hole routers.

  • Check the network ports on your firewalls and routers for autonegotiation or autodetection of network speeds. Occasionally, network ports that use autonegotiation or autodetection of network speeds causes a mismatch on one end of the network link. This results in communication errors.

  • You can capture network packet traces to determine if there are lots of packet retransmissions, packet fragmentation, and so on.

  • Is network address translation (NAT) being used? A large NAT pool of clients could be flooding code access security (CAS) with requests. For more information, see NAT support with Office 365.

  • Ensure that your proxy or firewall is configured for Office 365 IP address and URL requirements. For more information, see Office 365 URLs and IP address ranges. Be aware that some firewalls cannot accommodate Classless Interdomain Routing (CIDR) notation or Fully Qualified Domain Names (FDQNs) on either the include list or the exclude list. For these devices, adding the IP addresses or ranges directly is still an option.

  • We strongly recommend that you enable routing to the root domain names (such as *.outlook.com, *.microsoftonline.com, *.lync.com, and *.sharepoint.com) instead of routing to specific IP address subnets. IP addresses can change without prior notice. This might cause outages for your users if you’re relying on IP address subnets being manually entered into your firewall or proxy. For more information, see Office 365 URLs and IP address ranges.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft