Slow Outlook 2016

TL;DR: Blacklisting some domains from Microsoft may result in a much faster Outlook 2016 startup time.

Ben John
3 min readSep 11, 2018
Sloth waiting for Outlook 2016 so start…!

Problem

Outlook starts very slow when being online, but if you disconnect from the internet, the startup is blazingly fast.

Initial thoughts

My initial thoughts were that some requests may be very slow and run on main thread (or at least the main thread waits for the requests to finish).

The next step would be to analyse the incoming and outgoing connections from Outlook. Hence, I used “Microsoft Network Monitor” to capture the traffic.

Findings

First, I have noticed that there is a significant delay (and also the only delay in the whole log) with about 22 seconds related to the connection to “europe.odcsm1.live.com.akadns.net” (abbreviated as odcsm1), so I filtered by via Source == "odcsm1" or Destination == "odcsm1" .

About 22 seconds delay regarding the connection to “odcsm1”.

Second, the previous frame regarding this connection contains the message “Client finished (needs reassembly)” which basically means: the connection is closed.

Client finished (needs reassembly).

Short testing the URL via Terminal on my Mac resulted in:

~> curl -v https://europe.odcsm1.live.com.akadns.net
* Rebuilt URL to: https://europe.odcsm1.live.com.akadns.net/
* Trying 52.109.88.5...
* TCP_NODELAY set
* Connected to europe.odcsm1.live.com.akadns.net (52.109.88.5) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=odc.officeapps.live.com
* start date: Dec 18 21:45:20 2017 GMT
* expire date: Dec 18 21:45:20 2019 GMT
* subjectAltName does not match europe.odcsm1.live.com.akadns.net
* SSL: no alternative certificate subject name matches target host name 'europe.odcsm1.live.com.akadns.net'
* stopped the pause stream!
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (51) SSL: no alternative certificate subject name matches target host name 'europe.odcsm1.live.com.akadns.net'

Hence, it is clear that something went horribly wrong. The connection is finally established after about 30 seconds. I assume that the there exists an internal reply pattern with some backoff resulting in Outlook 2016 to “hang” for about that time period. It could also be the case, that the server needs too much time to fulfil the request. I believe that the abbreviation “odc” and “odcsm” is linked to the OneDrive cloud service from Microsoft.

Temporary solution

The deactivation / delinking of OneDrive to the account / Outlook did not improve the startup time significantly. The requests to “odcsm1” are still initiated on startup.

The “final” solution is to blacklist the addresses of “odcsm1” (there are a lot due to GeoDNS) via Windows-Firewall which resulted in a much better user experience: no delay at all.

Of course, I do not know if there are any drawbacks, but the rule can be disabled easily. Hopefully the issue gets fixed by Microsoft, but as only a few others experience this slow startup issue, it may stay in the wild for some time As of now, this problem exists for roughly over a year.

--

--