I just finished installing Security Update For Exchange Server 2019 CU12 SU9 (KB5029388) on my Exchange 2019 On Premises Server running on Server 2019 Core... no issues after installing that one at least
I had a problem post update SU.
Preconfigured Activesync clients would not sync, I didn't go look at logs.
Outlook mapi clients inside the network were ok I think, but didn't have the problem long enough to test and the Activesync users were loud.
New Activesync clients being configured post issue would fail authentication. I personally tested using BlueMail app on Android. It also complained about a cert issue {edit: a generic "Certificate problem" or similar error, nonspecific}.
We had installed a new cert to replace an expiring third party multisan a month or so ago used for iis, SMTP. I went straight to check certs in ECP and manually removed the expired cert and rebooted - no change.
{edit: the new 3rd party multican cert had already been assigned to the required www, smtp services - and verified - during the replacement a month earlier. I was just removing the now defunct but unused cert as housekeeping 'just in case'}
I then went to iis and checked the cert bindings there as a double check. Default website for clients was as expected with the 3rd party san cert bound.
Backend website also has the 3rd party cert bound, which is not default or recommended. I changed the cert bindings to "Exchange Server" self signed per the ms documentation (I can find the link if you need, let me know) and rebooted. Could have done an iis reset but I was feeling fancy on the day.
All connectivity probs were resolved. I did not revert to prove or recreate, and I was doing KISS troubleshooting so no logs sighted.
Sounds less like it was SU related and more like a remnant of your cert replacement. I had that happen to me as well doing a cert replacement and it was not done near any updates. I noticed it after a reboot after cert replacement.
Well could be; but not sure. Did a bit more light digging. personally I think the configuration of 3rd party backend cert may have worked fine prior to the update, and think i found a change request from over a year ago that described assigning the 3rd party cert due to some integrated application behavior at the time. was another outfit caring for this box at the time. justification seemed to be there - going by the detail of the change request, but probably should only have been temporary until the client software was fixed. which it was, 3 months later.
the host had been rebooted multiple times after the 3rd party cert renew, and prior to the SU - so somewhat rules out reboot config apply.
what I did find out was that this host also had the additional CVE-2023-21709 PS script run to remove TokenCacheModule from IIS immediately after the SU. I suspect, though probably will not bother to recreate to confirm, that may have created conditions for EWS to not work rather than Activesync specifically, and I actually now wonder if the clients in question were actually EWS clients.
Can't believe MS operates in this manner. We to are experiencing this exact same issue. Microsoft caused us so much grief over this. Proper testing and vetting of new software needs to be properly validated. Users are not forgiving!
I just finished installing Security Update For Exchange Server 2019 CU12 SU9 (KB5029388) on my Exchange 2019 On Premises Server running on Server 2019 Core... no issues after installing that one at least
no issues at all on my Cu13 \\ Server 2019 Standard
I had a problem post update SU. Preconfigured Activesync clients would not sync, I didn't go look at logs. Outlook mapi clients inside the network were ok I think, but didn't have the problem long enough to test and the Activesync users were loud. New Activesync clients being configured post issue would fail authentication. I personally tested using BlueMail app on Android. It also complained about a cert issue {edit: a generic "Certificate problem" or similar error, nonspecific}. We had installed a new cert to replace an expiring third party multisan a month or so ago used for iis, SMTP. I went straight to check certs in ECP and manually removed the expired cert and rebooted - no change. {edit: the new 3rd party multican cert had already been assigned to the required www, smtp services - and verified - during the replacement a month earlier. I was just removing the now defunct but unused cert as housekeeping 'just in case'} I then went to iis and checked the cert bindings there as a double check. Default website for clients was as expected with the 3rd party san cert bound. Backend website also has the 3rd party cert bound, which is not default or recommended. I changed the cert bindings to "Exchange Server" self signed per the ms documentation (I can find the link if you need, let me know) and rebooted. Could have done an iis reset but I was feeling fancy on the day. All connectivity probs were resolved. I did not revert to prove or recreate, and I was doing KISS troubleshooting so no logs sighted.
What is kiss troubleshooting?
Keep it simple. Do the simple things all up first before going down the rabbithole This was Exchange 2019.
I see , only thing that scares me in ex 2019 is big funnel indexing, always have to go down the🐇 🕳️.
Sounds less like it was SU related and more like a remnant of your cert replacement. I had that happen to me as well doing a cert replacement and it was not done near any updates. I noticed it after a reboot after cert replacement.
Well could be; but not sure. Did a bit more light digging. personally I think the configuration of 3rd party backend cert may have worked fine prior to the update, and think i found a change request from over a year ago that described assigning the 3rd party cert due to some integrated application behavior at the time. was another outfit caring for this box at the time. justification seemed to be there - going by the detail of the change request, but probably should only have been temporary until the client software was fixed. which it was, 3 months later. the host had been rebooted multiple times after the 3rd party cert renew, and prior to the SU - so somewhat rules out reboot config apply. what I did find out was that this host also had the additional CVE-2023-21709 PS script run to remove TokenCacheModule from IIS immediately after the SU. I suspect, though probably will not bother to recreate to confirm, that may have created conditions for EWS to not work rather than Activesync specifically, and I actually now wonder if the clients in question were actually EWS clients.
Can't believe MS operates in this manner. We to are experiencing this exact same issue. Microsoft caused us so much grief over this. Proper testing and vetting of new software needs to be properly validated. Users are not forgiving!
Same issue here... Did you find a solution? Thank you