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:
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
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:
