Exchange 2019 CU14

In Exchange 2019 CU14, Microsoft enabled Extended Protection by default in an attempt to prevent Man-in-the-Middle attacks. When not prepared or configured properly, enabling Extended Protection can have serious consequences. The worst scenario that I have seen recently is that users were no longer able to logon to Exchange 2019 after applying CU14.

Extended Protection is not new. Microsoft introduced the feature in Windows 2008 R2 Internet Information Server (IIS 7.5). Support for Exchange 2019 came with the August 2022 Exchange Server Security Updates. This Security Update was available for Exchange 2019 CU12 and CU13, for Exchange 2016 CU22 and CU23, and Exchange 2013 CU23. However, these updates did not enable extended protection.

In a previous article, I described how Exchange uses SSL Certificates. Here, I dig deeper into TLS and explain what Extended Protection is, how it works in IIS, and how to configure extended protection for Exchange Server.

Web Servers, TLS, and Extended Protection

Using certificates, a connection between a client and a server is encrypted and authenticated. When a client sets up a connection to a server, the following steps occur:

  1. The client requests the IP address of the server using DNS and opens a TCP connection on port 443.
  2. The client sends a TLS Hello message to the server. This message contains the TLS version it supports, the possible cipher suites for encryption and a random string of bytes called the ‘client random’.
  3. The server responds with a Hello message containing the chosen cipher suite, a ‘server random’, and the SSL certificate.
  4. The client verifies the SSL certificate. It must contain the URL that the client used to access the server and the client checks if the certificate is not expired or revoked by the the certification authority that issued it. This way the client knows that the server really is who it says it is.
  5. The client sends another random string, the ‘premaster secret’. The secret is encrypted using the public key of the SSL certificate and can only be decrypted by this server using the private key of the SSL certificate.
  6. The client and the server both generate session keys from the server random, the client random, and the premaster secret.
  7. The client sends an encrypted ‘finished message’ to the server and the server also responds with an encrypted ‘finished message’.

This process is called the TLS handshake and when finished, an encrypted connection exists between the client and the server (Figure 1).

Extended Protection
Figure 1: A direct connection between a web server and a client

Figure 1 shows a simple representation of a client connecting directly to a server. When using a web farm, or when the client is on the Internet and the web server is on an internal network, a reverse proxy is used to publish the web server(s). A load balancer is often used as a reverse proxy to publish a web server to the Internet.

In this scenario, the steps outlined in the previous example are executed, but the server is now the reverse proxy server and not the web server. When complete, the client has a secured connection with the reverse proxy, and the reverse proxy can decide what to do with the information, like forwarding the request to the web server. Or when a load balancer is used, one of the web servers. The reverse proxy server can use an unencrypted connection with the web server, this is called SSL offloading. The reverse proxy server can set up a secured connection with the web server. The same steps are then executed again, but the client is now the reverse proxy server. This is called re-encryption or SSL bridging and is shown in Figure 2.

Extended Protection
Figure 2: A webserver published using a reverse proxy.

Now let’s compare this to the OSI model. The TCP connection is in Layer 4 (Transport Layer) which takes care of a reliable network connection. Layer 6 (Presentation Layer) is where TLS is acting, and the web server is in Layer 7 (Application Layer). This is shown below in Figure 3.

Extended Protection
Figure 3: The OSI Model with the 7 communication layers

TLS authenticates servers against the SSL certificate, and if a server or device can present the correct certificate, all is good and communication takes place, regardless of any man in the middle. This is where Extended Protection begins to play a role.

Extended Protection uses a token generated when a user is authenticated (in the Application Layer on the server) and binds it to the TLS session setup in Layer 6. This is called the ‘channel binding token’. It binds the user’s authentication session to the device’s TLS session, and it is only valid for that session. A Man in the middle attack cannot take over a session and use the token to set up other sessions. This is why it does not work when SSL offloading is used. Taking over a session by a Main in the Middle attack is called a session relay or authentication relay.

Extended Protection in Exchange Server

IIS in Windows Server supports Extended Protection since IIS version 7.5 in Windows Server 2008 R2. Starting with Exchange 2019 CU14 Extended Protection is enabled by default. Be aware, Microsoft introduced Extended Protection in the August 2022 Security Updates, so it is available for Exchange 2016 CU22/CU23 and Exchange 2013 CU23, even if it is not enabled by default.

So, when is special attention needed when installing CU14 and configuring Extended Protection?

  • You cannot use SSL offloading with Extended Protection since it cannot use the channel binding token. It is possible to use re-encryption on a load balancer (also known as SSL bridging), but only when the same SSL certificate is used on the load balancer and the Exchange servers.
  • When using a load balancer with pre-authentication configured, even with a correct re-encryption configured, it will break and it is not possible to log on to the Exchange servers anymore.
  • Make sure that Extended Protection is enabled on all Exchange servers in your organization and that all SSL certificates on the Exchange servers are identical.
  • Outlook Anywhere has SSL offloading enabled by default, when installing Exchange 2019 the installer will disable SSL offloading. A better solution is to switch from Outlook Anywhere to MAPI/Http.
  • Take care when using Public Folders hosted on an older version of Exchange server when installing Exchange 2019 CU14. Public Folders must be hosted on Exchange 2016 CU23 or Exchange 2019 CU14, or the Public Folder access will break. You can find more information regarding Public Folders and Extended Protection in the Microsoft article Configure Windows Extended Protection in Exchange Server.
  • Extended Protection only works with a classic hybrid environment. When using modern hybrid, Extended Protection cannot be used and must be disabled when installing CU14.

Before installing Exchange 2019 CU14, or before enabling Extended Protection on Exchange 2016 or Exchange 2013, it’s important to run the Microsoft Healthchecker.ps1 script, and to check TLS settings on your Exchange servers. Make sure that TLS 1.2 is enabled on all Exchange servers. I recommend only using TLS 1.2 and disabling TLS 1.0 and TLS 1.1 for all Exchange servers.

Using the healthchecker.ps1 script, check the Extended Protection settings on all Exchange servers in your organization. As shown in Figure 4, Extended Protection is not enabled on my Exchange 2019 servers before installing Exchange 2019 CU14.

Exchange Server Extended Protection
Figure 4: Extended Protection reporting in the healthchecker output.

When installing Exchange 2019 CU14 using the GUI setup application, the setup application automatically enables Extended Protection. It is not possible to avoid this using the GUI. If you need to install Exchange 2019 CU14 without enabling Extended Protection, use the unattended setup with the /DoNotEnableEP_FEEWS switch. Use the following example to install Exchange 2019 CU14 without enabling Extended Protection:

Setup.EXE /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataOn /DoNotEnableEP_FEEWS

When you have installed CU14 and need to disable Extended Protection for some reason, use the ExchangeExtendedProtectionManagement.ps1 script provided by Microsoft.

To show the status of Extended Protection, use the following command. This is shown in Figure 5.

.\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection
Exchange Server Extended Protection
Figure 5: Extended Protection is disabled using the Microsoft script

It is possible to use IIS Manager on an Exchange server to change the Extended Protection session, as shown in Figure 6. It is strongly recommended NOT to change these settings this way and should use the Microsoft script instead.

Exchange Server Extended Protection
Figure 6: Extended Protection settings in the IIS Manager on the Exchange server.


Extended Protection is a Windows feature that mitigates Man-in-the-Middle attacks. It does this by using a ‘channel binding token’ to bind an authentication session to a TLS session. Starting with the August 2022 Security Update for Exchange server 2013/2016/2019 Extended Protection is supported, but not enabled by default. Exchange 2019 CU14 enables Extended Protection by default.

Before installing Exchange 2019 CU14, make sure you have all the prerequisites in place. If you cannot have this in place, you can install CU14 with the /DoNotEnableEP_FEEWS switch to not automatically enable Extended Protection. When you have the prerequisites in place, you can enable Extended Protection using the Microsoft script. Use the Microsoft script and avoid using Windows IIS Manager. It’s the right way to do things.

TEC Talk: Advanced Hypothesis-Based Threat Hunting with Microsoft Azure Solutions

TEC Talk:

Join Dr. Mike Jankowski-Lorek’s Free Webinar on March 14th @ 11 AM EST.

About the Author

Jaap Wesselius

Jaap is an independent consultant based in The Netherlands. Starting with Exchange 5.0 in 1997, he has been working with Exchange for almost half of his life. After leaving Microsoft as an employee, Jaap started as an independent consultant in 2006, continuing to work with Exchange and later on with Exchange Online. Besides consulting work, Jaap is an author of several books (some coauthoring with Michel de Rooij), blogger, presenter, and these days part-time (kids leaving the house) dad. Besides working with Exchange, Jaap is also a motorcycle enthusiast, owning several motorcycles. For his work in the community, Jaap received the MVP award back in 2007, an award that was constantly re-awarded up to this day, something he is very proud of.


  1. Chico

    When running ‘ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection’, what tells you that it is or isn’t enabled please?

    Also, I used the following switch ‘/DoNotEnableEP’ rather than ‘ /DoNotEnableEP_FEEWS’ switch and then ran the healthchecker script and it showed that my 2 node 2019 exchange hybrid Extended Protection was not configured. Is it okay to run this switch rather than the front end one please?

    1. Jaap Wesselius

      Hi Chico,

      It is no problem at all to use the /DoNotEnableEP switch instead of the other one.

      1. Chico

        thank you Jaap,

        When running ‘ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection’, what tells you that it is or isn’t enabled please?

        1. Jaap Wesselius

          Have a look at figure 5 in the article, that’s what you see when it is disabled.

      2. Chico

        thank you Jaap,

        How to tell with your script if it isn’t enabled please?

  2. Ed

    Very good summary, thank you

  3. John

    Hello Jaap,
    We have a scenario with one of our clients where the Exchange is setup in a Classic Hybrid scenario.
    – Exchange server 2019 with CU13 installed.
    Last week, we did a quick change on just enabling Extended Protection. But one test failed which pertains to mailbox migration from on-prem to cloud. But once we Turned Off the Extended Protection in “Windows Authetication” for EWS, the migration worked fine for the test mailbox account.

    In your article, you mentioned that Extended Protection works only in Classic Hybrid Scenario and not in Modern Hybrid. Can you please share your thoughts about why we could have faced this error of mailbox migration? or do you think that it is expected and that we should turn off Extended Protection only for EWS in classic hybrid scenario?


    1. Jaap Wesselius

      Hi John,
      Modern Hybrid works with an agent, that’s why EP is not working there. Without anything between Exchange Online and your Exchange server, even with CU13, it should work. Is it just the mailbox migration that’s not working? Is cross-premises free/busy working? That’s using EWS as well, just like mail tips for example.
      How many servers do you have? Is it possible to EP breaks between two Exchange server, because of a different certificate for example?

  4. Frank

    Thank you so much Jaap. Your explanation saved my day!

  5. Steve

    Thank you for this! It is much appreciated.

Leave a Reply