In this blog, I will review a Free/Busy issue between Exchange 2019 and Exchange 2013/2016 during the co-existence/migration process.

Background

Exchange’s support with TLS 1.2

TLS protocol is an industry standard designed to protect the privacy of information communicated over the Internet.
The TLS protocol allows client/server applications to detect the following security risks:

• Message tampering
• Message interception
• Message forgery

The next exchange versions support TLS 1.2:

• Exchange Server 2019 is using TLS 1.2 out of the box.
• Exchange Server 2016 supports TLS 1.2 since Cumulative Update (CU) 8
• Exchange Server 2013 supports TLS 1.2 since Cumulative Update (CU) 19

TLS protocol is a way to encrypt the communication between web applications and servers, such as web browsers loading a website.
TLS can also be used to encrypt other communications such as email, messaging, and voice over IP (VOIP).
This means that “Messaging” between servers is NOT only emails….

Problem Statement

Even though you are running Exchange 2013 CU19+ or Exchange 2016 CU8+, it doesn’t necessarily say that your servers are communicating with each other with TLS 1.2, it just enables the option to work that way.

So in case you have installed Exchange 2019 into an existing Exchange 2013/2016 environment for migration in an example, you are having a co-existence with Exchange 2019 version that “speaks” only TLS 1.2 and
Exchange 2013/2016 that “speaks” only TLS 1.0/1.1, but not TLS 1.2.

This is why we are having a problem.
One of the problems and I think that most critical one for users is the Free/Busy issue, where users/mailboxes from Exchange 2013/2016 and users/mailboxes from Exchange 2019, unable to share or view their peers from the other version’s calendar.

for example, when users from Exchange 2013/2016 are trying to invite a user from Exchange 2019 (or vice versa), they will get the “Cross lines” instead of his calendar.

This is how it looks via Outlook client:

And this is how it looks via OWA client:

Again, this user experience is identical for both sides, users with a mailbox on Exchange 2013/2016 and users who are having a mailbox on Exchange 2019.

Solution

Actually, the solution is relatively very easy with merging few registry keys.
There are basically 2 ways to solve the issue, the first one is the most recommended and highly secured, the second one is NOT recommended and of course less secured.

1. Set the Exchange 2013/2016 servers to work with TLS 1.2 using registry keys.
2. Set the Exchange 2019 servers to work with TLS 1.0/1.1 by running a script within Exchange 2019.

Since Microsoft does NOT recommend to reduce the security and work with TLS 1.0/1.1, we will review only the first option, by increasing the secure communication between the servers to TLS 1.2.

The registry values that should be set on the Exchange 2013/2016 servers are:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
“Enabled”=dword:00000001
“DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
“Enabled”=dword:00000001
“DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
“SystemDefaultTlsVersions”=dword:00000001

Those values MUST be imported and set on ALL Exchange 2013/2016 servers, while Exchange 2019 is installed on the environment.
Please notice that those values should already set during the Exchange 2019 installation, on all Exchange 2019 servers, so there is nothing to set on the Exchange 2019 servers, only on Exchange 2013/2016.

In case you would like to merge all the registry values at one on the Exchange 2013/2016 servers, you can download the reg file and merge it on all Exchange 2013/2016 servers:

• Please notice that you will have to reboot every server after you merge those registry values, in order to changes take effect.

After setting the registry values and rebooting the Exchange 2013/2016 servers, let’s see how it looks like:

Using Outlook Client:

Using OWA:

By the way, using Message Header Analyzer (MHA) we will be able to see that email communication is working with TLS 1.2:

More information regarding Exchange and TLS guidance from the Exchange Team’s blog:
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Exchange-Server-TLS-guidance-part-1-Getting-Ready-for-TLS-1-2/ba-p/607649

HTH 🙂