Microsoft has released security updates (SUs) that resolve vulnerabilities found in:
Exchange Server 2013
Exchange Server 2016
Exchange Server 2019
IMPORTANT: When manually installing SUs...
Updated Mar 16, 2022
Version 6.0
Blog Post
The required workaround to get this patch installed is quite frankly a ridiculous requirement! This should not be needed on production systems to remediate critical CVE's. Microsoft should have not released the update in this state, it's clearly not been adequately tested. What is the ETA on a working fix?
Q: Does this only apply to certificates that have Exchange services tied to them, or is it any certificate in the personal store?
A: If the certificate is returned via 'Get-ExchangeCertificate', it might cause the service to crash because we then generate the async notifications as described in the KB5013118.
Get-ExchangeCertifcate, returns any certificate in the personal store of a server where Exchange Server is installed. This means our 'MS-Organization-P2P-Access' is listed when I run that command!
Q: Should this workaround be applied before or after the installation of March's update?
A: Please check the 'Cause' section. It shows a clear order of the steps:
Q: I've read the Cause sections, so if I'm not running different Exchange versions or co-existence mode, will I be unaffected by this issue?
Q: Is it possible to check for these async notification, prior to updating?
Q: Is this workaround just to get the service running again, will the crashing symptoms continue following a reboot if expiring certs are still installed?
A: The workaround disables the functionality which generates async notifications to avoid these notifications are generated on different Exchange server builds (servers that have installed the SU and servers that have not). If you run a single Exchange Server version (for example, only Exchange 2019) within your environment without co-existence, you can safely remove the registry value after all servers are updated.
Q: I don't follow, how can you safely remove the registry value again if the expiring certificate is still present on the server, the remove expiry notification script is just clearing out the notification. Has the underlying issue causing the crash in relation to async notifications been fixed, or will this occur again? I ask this as I won't be performing the optional step 5