The "Windows Extended Protection" security feature was introduced with a security update in August 2022 for Exchange Server 2013, 2016 and 2019 and protects against man in the middle (MitM) attacks.
In small organizations where there is only a single Exchange server, without load balancers and web application firewalls, Windows Extended Protection can be activated quite easily. In larger environments with Exchange DAG, load balancers and WAFs, however, a few important things need to be taken into account.
Load balancer / WAF and Windows Extended Protection
As a rule, SSL bridging or SSL offloading is used on load balancers and web application firewalls. Extended Protection only supports SSL Bridging, but not SSL Offloading. The next image shows the behavior of SSL Bridging:
If SSL bridging is used, the WAF, load balancer and Exchange Server must use the same certificate. Different certificates, for example a certificate from an internal PKI on the Exchange Server and load balancer and a public certificate on the WAF, do not work with Windows Extended Protection.
Load balancers usually support 3 different ways of handling https connections. Here is an example using a Kemp load balancer and the Exchange templates:
HTTPs passthrough and HTTPS re-encrypted work with Windows Extended Protection if the load balancer uses the same certificate as the Exchange servers. HTTPS Offload is not supported.
Some AntiVirus / Endpoint Security programs also decrypt HTTPS connections with their own certificate on the client. These programs also work with SSL bridging, similar to load balancers and WAFs, but this is also a MitM method, which is to be prevented by Windows Extended Protection. If such software is used, an exception must be configured here for connections with Exchange.
Supported Exchange versions
As already mentioned at the beginning, Extended Protection was retrofitted with a security update for Exchange Server in August 2022. All Exchange servers in the organization must therefore have at least the August 2022 update installed.
Here are the minimum build numbers that must be present:
| Name | Published | Build (short) | Build (long) |
| Exchange Server 2019 CU12 Aug22SU | August 9, 2022 | 15.2.1118.12 | 15.02.1118.012 |
| Exchange Server 2016 CU23 Aug22SU | August 9, 2022 | 15.1.2507.12 | 15.01.2507.012 |
| Exchange Server 2013 CU23 Aug22SU | August 9, 2022 | 15.0.1497.40 | 15.00.1497.040 |
It is best to update all Exchange servers to the latest patch level before activating Windows Extended Protection. If there are still Exchange 2013 servers with public folders, these must be migrated to Exchange 2016 or Exchange 2019. Extended Protection also does not work with the Modern Hybrid configuration.
TLS settings of the Exchange Server
All Exchange servers in the organization must use the same settings for TLS. Here is the Exchange Health Checker is a great help, as it checks the TLS settings and indicates if TLS 1.2 is not activated for the server.
The required TLS settings can be easily configured with the script from this article:
Activate extended protection
To activate Exended Protection, Microsoft has provided a PowerShell script that makes the necessary settings and also performs a preliminary check of the prerequisites. The script can be downloaded here:
The script can then be executed in the Exchange Shell with administrative privileges:
.\ExchangeExtendedProtectionManagement.ps1
The status of Extended Protection can be checked as follows:
.\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection
If there are any problems, the changes can be undone by the script with the following two commands:
.\ExchangeExtendedProtectionManagement.ps1 -RollbackType "RestoreIISAppConfig"
.\ExchangeExtendedProtectionManagement.ps1 -RollbackType "RestrictTypeEWSBackend"
Further information can be found in the following article: