Today, we are announcing the availability of the 2025 H1 Cumulative Update (CU) for Exchange Server 2019 (aka CU15). This is the last CU we will release for Exchange Server 2019.
CU15 includes new ...
Updated Feb 26, 2025
Version 9.0
Blog Post
Nino_Bilic Please see my latest, there still seems to be an issue (I learned after trying the actual tested URL).
More fallout... the clobbering of the web.config file has removed the entire system.webServer/httpProtocol section which removes all prior fixes for:
- Content-Security-Policy
- Strict-Transport-Security (HSTS)
- And all URL Rewrite rules...
Re-adding all the above seems to remedy my internal IP leaks by aborting the connection if the Host header is empty:
Testing empty Host header over SSL/TLS...
Server: redacted.redacted.tld, Port: 443
Sending request:
GET /autodiscover/autodiscover.xml HTTP/1.0
Connection: close
Response Headers & Body:
Error reading response: Exception calling "ReadLine" with "0" argument(s): "Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host."
Completed SSL/TLS empty Host header test.Which I suspect was previously protected with:
<rewrite>
<rules>
<rule name="RequestBlockingRule1" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern=".+" negate="true" />
</conditions>
<action type="AbortRequest" />
</rule>
</rules>
</rewrite>I think this is all boiling down to "don't clobber the existing web.config file" with CU15.
Has anyone else noticed URL Rewrite rules missing after CU15 install?
The_Exchange_Team, Nino_Bilic , at the very least, can you add a known issue to the CU15 release information that indicates that the web.config file will be overwritten?
It seems web.config is overwritten so that this line can be added:
<linkedConfiguration href="file://C:\Program Files\Microsoft\Exchange Server\V15\bin\SharedBindingRedirects.config" />(or at least that's the only addition on my installation from 2019 CU14 Nov24SUv2 to 2019 CU 15).
To double check this, I reviewed a backup prior to CU15 install.
The SharedBindingRedirects.config file DOES NOT exist before I installed CU15 on Feb 12:
web.config was created/last modified in May/June of 2024:
Then, I reviewed a backup after the CU15 install.
The SharedBindingRedirects.config file DOES exist after I installed CU15 on Feb 12:
web.config was created when I started the install at 10:01pm, and modified at 10:18pm when I subsequently re-added the alternateHostName attribute:
Unfortunately, overwriting the web.config file removes all custom headers and URL Rewrite rules (and potentially other things) for Exchange.
(Maybe it's just me, though I'd be surprised because I'm literally diffing web.config and comparing backups before and after the CU15 upgrade. I guess what's more surprising is that more people haven't noticed this or aren't having issues caused by this, which, of course, has me second guessing myself.)
Either way, I believe I've fixed this on my side, but if true, others should be made aware as well.
Thanks, as always!
4ppl3c0r3I can confirm I'm seeing the same on our end. All URL Rewrite rules are gone. Sec Team just came back with the same Nessus findings, and have spent most of the day trying to find a resolution which led me here.
Restoring two URL rewrites from a legacy Exchange 2016 server we haven't completed decommission on got me halfway there, but still need to apply the inbound rule to abort if the Host header is empty.
Bestivus, Nino has since mentioned (and I should have known) that SU's won't replace the web.config file, but CU's will.
The web.config contains the alternatehost, any URL Rewrite rules, etc. So, I assume the guidance is to manually merge any prior web.config changes including any URL Rewrite rules into the new web.config file.
- Nino_Bilic
Microsoft
4ppl3c0r3 FWIW, overwriting of the web.config in CU upgrade has been a thing for years. In CU13, we have added the ability to "back up" some changes made in web.config files (Exchange Server custom configuration preservation | Microsoft Learn) but it has been a long-standing recommendation that customers who have modified web.config back this file up before CU upgrades.
Thant being said - thank you for providing all the detail here; it did bring up some things that we can consider to improve with config preservation process.
