What
The issue was that the clients Exchange 2003 Server (32bit, on Windows Server 2003) was no longer receiving emails from Office 365 (Exchange Online) accounts. It would take days to be aware of the issue as TLS connections would “hang/time out” but Exchange Online would continue to try and deliver the message until the delivery timeline expired. I.e. NDR’s came after *days* and very disruptive to business email delivery.
Side note: if someone has SBS 2003 kicking around, I bet they could have similar issues.
So What
There were a few issues at play here:
- The cert was newer (G2 from GoDaddy) and IIS/Windows 2003 didn’t have the Intermediate Cert in its intermediate store
- The cert needed to be applied in Exchange (it was still referencing the older cert)
- Exchange TLS support was out of date and needed a hotfix to support it
Diagnosing
- When troubleshooting, the first two issues above were easily identified by looking in the event logs as there were errors every time the SMTP service was stopped/started that correlated to a mismatched SSL (TLS) cert
- The TLS “stalling” errors were harder to diagnose, however, the two clues were:
In the Transport Queues, I found dozens of everlasting connections to protection.outlook.com servers – running hours – connections just never closed - In the SMTP logs, I would see a session open, but the conversation would never conclude (see below for an example):
To contrast, this is what a normal connection would look like (TLS as well, with Gmail – notice there was data sent and it actually quit/closed)…
Now What
In the end, the magic answer was addressing three things for this client:
- As it was a new (renewed but new root CA) cert involved, it was also from GoDaddy’s G2 (newer) cert provider, using a stronger (newer) cypher that wasn’t supported by Office 365/Exchange Online for connectivity anymore so this meant we needed to download the GoDaddy G2 Intermediate Cert and place it in the computers Intermediate Cert Store
- The cert needed to be applied to the SMTP Service in Exchange Admin in the Transport settings (it was still trying to connect with the older/expired cert)
- As it was a new/higher cypher cert, TLS was now unable to connect happily. This required applying the following hotfix (I was hesitant at first as this hotfix is from 2008!!! – I eventually applied it because this hotfix is post Exchange 2003 Service Pack 2 – so they didn’t have it already and no future fix addressed it either – the hotfix is here (had to make sure we downloaded the 32bit version as the hotfix site insisted I download the 64bit, being on a 64 bit desktop when I browsed the site): https://support.microsoft.com/en-us/kb/957047 (note the hotfix and related article you might find refers to trouble SENDING to Office 365 but in this case, SMTP is a two way street and totally applies).
Hope that helps someone.
Thanks very much – the KB fixed the issue for us
The problem is that applying that hot fix prevents mail from being sent from Gmail and Comcast.
That’s interesting Fred. That has not been my experience. Have you checked the logs since applying the fix?
Sean,
Thank You very much for this post. I wish I had read it before I spent countless hours trying to isolate why we could not receive email from 365 on Exchange server 2003.
No wonder they fast tracked eol for 2003 so they could publish their new ciphers.
But Thanks for patching this up for us, so we don’t have to slam dunk Exchange 2013!
Jim
Happy to help Jim
Sorry Michael, I didn’t have any gmail issues but I imagine if you follow the path of my post and review your logs, you should get some clues there In regards to what it was getting as a response.
Thanks very much!
I applied the hot-fix and it fixed the issue for us.
THank you, the hotfix fixed my issue as well !