"Important" Update Bound to Break Your Exchange Server. Again.

Hi There,

I've done a routine manual patching of one of the Windows 2012 R2 servers, and, instead of hitting the Install button, as many of us do (they are all "Important" updates after all so why not just install them all, right?), I looked at what is going to be installed.

To my surprise I saw .Net Framework 4.8 on the list:

WHAAAAT??? .Net version upgrade as "Important"?

Yes, Microsoft is doing it again: they are shoving it down the throat without thinking of the consequences. They ruined a couple of Exchange servers about a year ago - more details here.

A word of advice:

• Don't just blindly accept all updates just because they are listed as "Important".
• Have your Exchange patched to the latest CU.
• Consult the Exchange .Net supportability matrix.

The Exchange team has put up this warning on its .Net supportability matrix:

Specific for hybrid deployments, if you want to stay supported, you must run the latest, or the immediately previous release of Cumulative Updates / Update Rollups - see here. If you have, for instance, a Hybrid Exchange 2016 on CU12, hence supported (at the time of this writing), and don't want to update to CU13 just yet, then think again: a routine Windows Update exercise may bring your messaging system to its knees:

Thank you .Net team, yet another not-so-well-done upgrade.

550 5.4.316 Message expired, connection refused (Socket error code 10061)

In a recent engagement of Exchange migration to O365 the client started experiencing random inbound delivery failures. The error in the NDR was that in the title:

Research pointed to a couple of articles that all suggest checking the firewall:

• O365 sources blacklisted/quarantined by an over-zealous Fortigate IPS rule - https://pariswells.com/blog/research/office-365-failed-550-5-4-316-message-expired-connection-refusedsocket-error-code-10061
• Microsoft's own experience and recommendation - https://docs.microsoft.com/en-us/office365/securitycompliance/mail-flow-intelligence-in-office-365

It turned out to be not a firewall, but a case of asymmetric routing. Close enough. A new device has been introduced into the customer's environment to set up a VPN with a sister company at around the same time when the first delivery error reports started to came in. Setting up the VPN affected routing, resulting in egress/ingress SMTP traffic to/from the same source took very different paths.

Once routing has been corrected, email started to flow normally again.

Till next time.