Forum Discussion
OWA/ECP stop working after update ((
Hello. I have one Exchange server under my control. After installing update KB5019758, the admin console stopped working. I get message ASSERT: HMACProvider.GetCertificates:protectionCertif...
Hi KosmosKami!
OWA/ECP errors after an Exchange Security update is something quite usual.
These errors occur if the security update was manually installed on a server that has User Account Control (UAC) enabled, but without using elevated permissions.
Use elevated permissions to reinstall the security update on the server.
-Select Start, and then type cmd.
-Right-click Command Prompt from the search results, and then select Run as administrator.
-If the User Account Control window appears, select the option to open an elevated Command Prompt window, and then select Continue. If the UAC window doesn’t appear, continue to the next step.
-Type the full path of the .msp file for the security update, and then press Enter.
-After the update installs, restart the server.
If that doesn't fix your issue, you'll probably need to check the ECP Virtual directory. You can find the detailed instructions here: OWA or ECP stops working after you install a security update - Exchange | Microsoft Learn
Hope this helps and please let us know if you finally fix the issue. If not, we'll need to perform further checks.
Good luck 🙂
Many thanks for helping and sharing your knowledge FcoManigrasso . Right now I have half of the problem ESP is working, but OWA is unavailable. I try navigate to C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy and take a copy of the SharedWebConfig.config file. Then Paste a copy of that file into the C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess directory. And then restart the IIS Services (iisreset). Unfortunately, it didn't help I'm also checked the certificate used for https binding, (in IIS.) is the same for the Exchange Front End, and the Exchange Back End web sites.
Hi KosmosKami,
Happy to hear that ECP is working now.
Regarding OWA, I'll need more info... Which error do you get?
Do you get any log in EV? Which ones?
Please check also that the certificate is still valid. You can check it running:
(Get-AuthConfig).CurrentCertificateThumbprint | Get-ExchangeCertificate | Format-ListFcoManigrasso On OWA page I am get an uninformative message after authorization
:-( Something went wrong Unfortunately, we cannot obtain this information right now. Please reply later. If you encounter problems, please contact supportAnd I still can't find the detailed log file that is responsible for OWA. I have seen posts online about what to look for in the IIS logs. Where is it on the right path?
Regarding the certificate, I can say that I checked the state of health with a script HealthChecker.ps1 and it warned that the validity of some certificates was coming to an end. So I used an another script MonitorExchangeAuthCertificate.ps1 to renew the certificates and then point them to IIS.
FcoManigrasso Many thanks for the help. Of course I will try to reinstall the update in the way you indicated. I am interested in figuring out for myself what is the difference between the two methods? In the case of installation by normal startup, a request for privilege escalation appears. Aren't these similar methods?
Hi KosmosKami,
That's a very good question. And unfortunately my answer will not be as clear as desired.
In many security updates Microsoft suggest to install them through an elevated CMD.
Why? Below my personal point of view, ( again, it's my personal interpretation and not confirmed by MS ).
Launching the update through the setup file you'll get a prompt for admin privileges. That prompt "interrupt" the native process asking for the permissions to go ahead. During the whole process privileges are required, ( ad, schema, exchange... ), and I think that those privileges aren't inherited correctly from that mentioned first prompt.
Launching the update from an elevated CMD will not interrupt the process and during the whole time it will identify an admin with the correct roles to install all the required paths. This is why this method causes less issues.
Again, this is my personal point of view got after many years working with Exchange and installing such updates.
Maybe VasilMichev could give you more detailed info about this topic, or tell if I'm wrong with my statement. ( He's one of the best Exchange engineer that I know ).
Anyway give it a try... I solved many problems like your one following that MS suggestion.
