TLDR || “Cannot Get Mail the connection to the server failed.” in the IPhone email client generally means, reset your password, connection is bad, or something in the made you sad.

I’ve worked a number of customer calls for the IOS error “Cannot Get Mail the connection to the server failed.” Heck, I see the error on a regular basis myself and I was able to capture the screen shot over to the right a few minutes after making up my mind to write this topic. What I’ve not been able to find is a great source of why my phone do this writings out there on the interwebs.

Key / Most Common Causes

The Key / most common causes I’ve researched / run into for the apple error “Cannot Get Mail the connection to the server failed.” Being displayed in the IOS email client are as follows:

1. Phone was not able to connect to Exchange – Connectivity is a transitive error that comes and goes as connection goes sad face or happy face. Not much to do here but attempt to make your connection better // More stable Wi-Fi, network things in the middle (Riverbed, Wan Accelerator, Proxy, Packet Shaper, Carl running a Microwave next to your Access point), change carrier’s, update phone tower data on your phone, make proxies in the middle play better or go away (Good, Mobile Iron, Airwatch, some other Activesync proxy thing)
2. Phone mail client profile is bad – Profile sad face is a persistent issue that does not go away until passwords are updated on the device, or the profile is deleted and added back. Apple topics for the error are generally resolved by entering your password after you changed it. Apple support search populated for you
3. Data in the mailbox is bad. – The Activesync call Foldersync is the most common call at the root of the error for mailbox corruption. The error burninates the village when foldersync times out or barfs on a folder. The folder making the sad face will show up in client logging users can view after enabling in Activesync logging in OWA/ECP. The issue is generally persistent and does not go away until the folder issue has been mitigated or the sync scope has been configured to avoid the sad data in the sad folder; sad.
4. Proxy in the middle – Mobile device proxy servers like Mobile Iron Sentry, Good, Airwatch, ETC could be causing connectivity issues in the middle of the Activesync stream – Solve this one by bypassing the Proxy and or calling the vender and having them take a peak at your issue.
5. IOS update – There have been a few updates to IOS resulting in the IOS email client going sad face. Don’t run daily builds of IOS and you should be able to avoid most updates hurting you.
6. Exchange blocking device – Exchange can block access to a device due to provisioning things. Again, these issues are persistent and do not go away until the underlying issue has been resolved. I’ve seen this one hit when device quarantine with a mobile device management tool like airwatch and Exchange don’t play well with each, resulting in a the managers playing tug-a-war allowing or not allowing the device.

Food for thought – The error “Cannot Get Mail the connection to the server failed.” Is specific to the IOS email client, and is not passed through to the device from Exchange or MDM. In most cases, other email clients, Android, 7mail, Outlook, ETC do not have a similar errors or symptoms.

==========================

I shall document root causes as I come across them below

==========================

451 Exchange Redirect

The error I worked today (8/2016) appears to have been caused by Mobile Iron Sentry mailbox caching. In the Mobile Iron logs we were seeing the following errors all over the place.

(AlertOrigin=Sentry, AlertId=HTTP503) Got exception during device-to-server processing, Sentry reporting error to client: Found recorded 451 redirect from server. Forcing reconnect.

The 451 redirect from Exchange is Exchange telling the client there is a better path / URL / front end server the device should be using to connect to change. Exchange is telling the client to REDIRECT elsewhere. Most Exchange servers are now configured to PROXY the connection else where and the redirect does not happen – but some times redirect is a much better answer vs. proxy and Exchange sends the 451. See blog post here for more data and deeper understanding – https://blogs.technet.microsoft.com/exchange/2015/03/23/exchange-activesync-on-boarding-to-office-365/

Mobile Iron Sentry does not want the client to see this redirect because it could provide the device a path around the Sentry server. Makes sense from the Sentry point of view where the Sentry server should be THE end point for all things Activesync. Sentry then caches the redirect on behalf of the client and moves to the new URL for the end user, if they can. From the best I can tell on the outside looking in, the Cache is only cached / set once, and they cache the redirected URL until you reboot the Sentry server or Manually clear the cache.

They have no setting to expire the cache – if you want to expire from time to time you have to write a KRON job to do it for you.

Manually clear the cache on a Sentry

<from the sentry manual / documentation>

On Sentry 4.7.x and later, you can clear out the redirects yourself.

1. Open a putty session.
2. Type enable and hit enter (then enter your enable password).
3. Type configure terminal (and hit enter).
4. Type debug sentry device-cache clear-redirect-url all (and hit enter).
5. Type debug sentry redirect-url-cache purge all (and hit enter).