• Use ping outlook.office365.com to see what region the request is resolved in. Microsoft says that the request gets directed to the region where the DNS query is resolved, that is, it is advisable to use local DNS servers (e.g. your local ISP DNS) instead of global DNS servers (e.g. Google Public DNS or OpenDNS).

The servers are named by the regions: ApacSouth and ApacEast for South-East Asia, EmeaWest and EmeaEast for Europe, Middle East and Africa, NAmWest and NAmEast for US etc.

If necessary, as a temp solution configure a conditional forwarder that resolves outlook.office365.com to outlook-your.region.office365.com. You can also use a local public DNS service that correctly resolves outlook.365.com requests.

• Microsoft serves Office 365 customers through Content Delivery Network with entry points along the backbone. These entry points are routers that can be identified by the names ending in NTWK.MSN.NET. The first msn.net router that appears in a tracert report is the entry point to the MS network.

• Ensure Windows Search files are not scanned by file-level anti-virus software since these generate and store Outlook index used by Fast Search.

• Ensure the exclusions are really working – test it using EICAR virus file.

• If you are scanning emails with an SMTP filter and have a file-level anti-virus scanner on clients, consider disabling email scanning and removing the AV add-in from Outlook.

Email Scanning can become redundant depending on your email environment. The On-Access Scanner in VSE scans attachments when running and/or writing to local disk. This happens after Outlook Scan finishes scanning. If email is scanned at the Gateway with McAfee GroupShield / McAfee WebShield, you may want to stop using Outlook Scan because of scan redundancy. (McAfee Technical Articles ID: KB52786)

If your antivirus software includes integration with Outlook, you may experience performance issues in Outlook. In this case, you can disable all Outlook integration within the antivirus software. Or, you can disable any antivirus software add-ins that are installed in Outlook. Be aware that if you are connecting to an Exchange Server mailbox, your mailbox or your email messages are already being scanned by antivirus software on the server. You should check with the Exchange administrator to make sure that this is the case. (Microsoft KBA 2695805)

• Ensure the indexing is not stuck and the index database is not corrupted – rebuild the Outlook index if necessary.

Outlook OST file size guidelines:

• Up to 5 gigabytes (GB): This file size should provide a good user experience on most hardware.

• Between 5 and 10 GB: This file size is typically hardware dependent. Therefore, if you have a fast hard disk and lots of RAM, your experience will be better. However, slower hard disk drives, such as drives that are typically found on portable computers or early-generation solid-state drives (SSDs), experience some application pauses when the drives respond.

• More than 10 GB: When the .ost file reaches this size, short pauses begin to occur on most hardware.

• Very large (25 GB or larger): An .ost file of this size increases the frequency of short pauses, especially while you are downloading new email messages. However, you can use Send/Receive groups to manually sync your mail. For more information about Send/Receive groups, see the "Are you synchronizing many RSS feeds?" section.

Outlook 2013 includes “hybrid mode”, which means that it’s got the ability to switch between cached and online data to display information to the user faster. The gate is 400ms, measured when the user logs on and connects to Exchange and updated when the user switches folders. If the network connection is good enough, Outlook can switch into hybrid mode to fetch data from the server and if not, access the OST.

Under some circumstances, the network adapter speed might not accurately reflect data throughput for users. For example, if a user's computer is connected to a local area network (LAN) for fast access to local file servers, the network adapter speed is reported as fast because the user is connected to a LAN. However, the user's access to other locations on an organization's network that include the Exchange Server computer might use a slow link, such as an ISDN connection. For such a scenario, where users' actual data throughput is slow, even though their network adapters report a fast connection, you can configure an option to change or lock down the behavior of Outlook. You can do this, for example, by disabling automatic switching to downloading only headers by using the Group Policy option, Disallow On Slow Connections Only Download Headers. Similarly, there might be connections that Outlook has determined are slow but which provide high data throughput to users. In this case, you can also disable automatic switching to downloading only headers.

When you add additional mailboxes to your Outlook profile and enable caching of the shared mailbox folders, Outlook individually registers every folder in the cached mailbox. Each of these registered folders counts toward the objtFolder type limit on the Exchange Server. As stated in the 9646 event that is shown in the "Symptoms" section of this article, the default limit for objtFolder objects it 500. If you cache one or more shared folders that contain several hundred folders, this limit can be exhausted. When this occurs, you may experience the problems described in the "Symptoms" section of this article. Additionally, a large number of Public Folder favorites can also contribute to exhausting the objtFolder object limit.

Rather than being transient, Outlook connecting to Exchange (be it on-prem or Cloud based) opens up TCP connections and leaves them open for the length of time the application is open.

Under most circumstances, these connections will see traffic on very regular intervals and thus any idle timeouts won't be an issue. However, it is a fact, and one I've seen occur many times, that Outlook, if not performing any actions, may not send any traffic on an open TCP connection for a long period of time.

We saw this issue regularly when On-Prem was prevalent. Firewalls would kill idle TCP sessions after a period of time, causing disconnect pop-ups in Outlook, hangs or other problems within the application such as password prompts as it reconnected. These were often due to the firewall not informing the client of the disconnect by sending a reset. Thus when the client tried to use the connection again, it would send a packet, get no response, then retransmit five times, exponentially backing off each time until it gave up and fired up a new connection.

This could take up to 30 seconds or more to timeout the TCP retransmits and thus cause hang problems within the application whilst the retransmissions take place.

We used to fix this problem by either setting Windows to send a KeepAlive packet at an interval lower than the Firewall's idle timeout value, or adjust the firewall settings.

In my experience with this behaviour I believe it's likely to cause the following, but not limited to the following problems:

Disconnect pop ups in OutlookUnexpected authentication promptsHangs within Outlook where we get a 'polo mint' especially when switching mailboxes/calendars.Performance problemsMail stuck in outbox for an extended period

• Ensure Outlook is bypassing the proxy server when connecting to Office 365.

Exceptions for Microsoft Office 365 URLs and applications from the authentication proxy:

Allow outbound connections to the following destination: *.microsoftonline.com
Allow outbound connections to the following destination: *.microsoftonline-p.com
Allow outbound connections to the following destination: *.sharepoint.com
Allow outbound connections to the following destination: *.outlook.com
Allow outbound connections to the following destination: *.lync.com
Allow outbound connections to the following destination: osub.microsoft.com

Ports 80/443
Protocols TCP and HTTPS
Rule must apply to all users.
HTTPS/SSL time-out set to 8 hours.