TLS 1.2 is coming to Exchange on-premises using hybrid and free/busy might fail

Microsoft

 

This article is intended to help customers and motivate them to check their on-premises TLS settings.

 

This spring, your on-premises users might not be able to do free/busy requests in calendaring from on-premises mailboxes towards Exchange online mailboxes.

 

In addition, your on-premises Exchange servers might start logging events like this:

 

Log Name:      Application

Source:        MSExchange Availability

Date:          17.03.2022 09:45:01

Event ID:      4001

Task Category: Availability Service

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      server01.contoso.com

Description:

Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: <User1@contoso.mail.onmicrosoft.com>SMTP:User1@contoso.mail.onmicrosoft.com failed in application Mailtips. Exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException: Autodiscover failed for email address User1@contoso.mail.onmicrosoft.com with error System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

 

The interesting parts of the event above are the following pieces of information:

AutoDiscoverFailedException: Autodiscover failed

and

The underlying connection was closed: An unexpected error occurred on a send

 

Since Autodiscover fails, let’s test it from the on-prem server and see if it can reach the server in Exchange online via Powershell:

Invoke-WebRequest -Uri "https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc"

 

On a non-working on-prem server, I get the result:

The underlying connection was closed: An unexpected error occurred on a send.

This error is unexpected, whereas this 401 would have been expected:

FrankPlawetzki_0-1647601369983.png

 

This raises some suspicion, if the TLS settings on-premises are ok when the on-prem servers try to reach the servers in Exchange online.

You can verify that your on-prem TLS settings are outdated, by forcing TLS 1.2 for the above test connection trying this Powershell call:

 

[Net.ServicePointManager]::SecurityProtocol += [Net.SecurityProtocolType]::Tls12

Invoke-WebRequest -Uri "https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc"

The result now as expect is:

Invoke-WebRequest : The remote server returned an error: (401) Unauthorized.

 

 

You now have proof that the TLS settings on-premises are outdated and your on-prem server not using TLS 1.2 prevents your server from connecting to the Exchange online servers.

 

Microsoft hast announced in Messager Center Post MC240160 and here:

Disabling TLS 1.0 and 1.1 for Microsoft 365

https://docs.microsoft.com/en-us/microsoft-365/compliance/tls-1.0-and-1.1-deprecation-for-office-365...

that we are enabling TLS 1.2 more and more in Exchange online starting October 2020 and now it affects more and more Exchange customers who so far have not enabled support for TLS 1.2 on-premises.

 

Microsoft has announced the deprecation of TLS 1.0 and TLS 1.1 already in 2018. Those articles also contain detailed information on how you can enable TLS 1.2, which in short is only adding some registry keys and doing a reboot:

Exchange Server TLS guidance, part 1: Getting Ready for TLS 1.2

Exchange Server TLS guidance Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It

Exchange Server TLS guidance Part 3: Turning Off TLS 1.0/1.1

As these articles above explain, you can enable TLS 1.2 in addition to your current usage of older TLS versions and solve your Free/Busy issue.

Later, you can disable TLS 1.0 and 1.1 since they are not secure anymore.

 

To prevent configuration errors like this, Microsoft recommends running the Exchange health checker on your on-premises Exchange servers on a regular basis, e.g. each month:

https://aka.ms/ExchangeHealthChecker

1 Reply
Excellent write-up! My company got bit by this a 2 months ago and it took 5 weeks worth of troubleshooting with MS to find the root cause. Hopefully this saves others!