Released: 2024 H1 Cumulative Update for Exchange Server

dengyidaohaolang1985 I'm not sure why this is. I can run the commands as documented on my Windows Server 2016 machine. You can try to run the command manually. For example:

Run (Get-TLSCipherSuite).Name to get a list of all TLS cipher suites.

Run Disable-TlsCipherSuite -Name "Cipher_Suite_Name" to disable all of them, except the cipher suites which you've already enabled as described in the documentation.

CorinaB from a technical perspective, this should work. However, to maximize availability, it is recommended to install them one after the other.

GirtsG using those switch parameters together makes no sense. If you want to install EP, but not on the EWS front end vDir, use: /DoNotEnableEP_FEEWS. If you don't want to enable EP at all, use: /DoNotEnableEP. Enabling EP by the help of the script doesn't require a reboot of the machine or IIS reset. The new setting will be immediately used.

/PrepareAD should be sufficient here. If you don't specify this switch parameter, Exchange setup will try to run this automatically and setup will fail immediately if Exchange setup can't perform the necessary changes (e.g., due to insufficient permissions).

It's recommended to upgrade all machines within a DAG as soon as possible, but yes, CU13 and CU14 can coexist.

Zafer1030 I need to check this internally.

Marc4056 ESmlatic it belongs on how the WAF works. Does it decrypt the traffic for inspection and re-encrypt the connection to Exchange then? If yes, that scenario is SSL bridging and would fail if the certificates are different (because this is considered as man-in-the-middle scenario, because the Channel Binding Token (CBT) is different in this case, which is prevented by EP). I assume that it works if you disable EP on the EAS vDir. However, this would leave the vDir unprotected. We've also not tested this scenario.