When certificates needs to be renewed or changed on (on-premise) Exchange server’s, and you have Microsoft 365 hybrid setup though Hybrid Configuration Wizard, a Office 365 connecter is setup as send and receive:
If you try to delete the old certificate, without setting the new cert for the connectors, you will get this in ECP:
“A special Rpc error occurs on server EXCH01: These certificates are tagged with following Send Connectors : Outbound to Office 365. Removing and replacing certificates from Send Connector would break the mail flow. If you still want to proceed then replace or remove these certificates from Send Connector and then try this command.”
So we need to move into Powershell and replace it, because it cannot be done through the ECP:
- Get the thumprint for the new cert:
So here it is, the top level cert, it’s a wildcard cert, thus the “*.” in the subject name, sorry for the maskings, this is from a non-lab environment 🙂
Copy the thumprint to notepad for next command.
- Read the certificate subject and thumprint into a variable:
-Thumbprint<paste the thumbprint in here from previous command>
"<i>$($cert.Issuer)<s>$($cert.Subject)" - Do not change anything here!
- The replace the connectors:
Send Connector –
"Outbound to Office 365"
Receive Connector –
"EXCH01\Default Frontend EXCH01"
Note: replace the word “EXCH01” with the name of your Exchangeserver like
"MY-EXCH01\Default Frontend MY-EXCH01"
- Run IISRESET
IF YOU GET: WARNING: The command completed successfully but no settings of ‘Outbound to Office 365’ have been modified.
This is because the old and new certificate have the same “issuer” and “subject”, the set-sendconnector and set-receiveconenctor, cannot thereforem tell the difference, but solution is easy:
Just add another cert on the servers thumbprint to the first script, then run all commands throgh, after that, do the same again, but now with the real cert’s thumprint, and it works 🙂
Note that if you fail to replace your certificate before it expires (You forgot to), your mailflow between on-prem Excahnge and Exchange Online (365) will stop working and you will see this in the logs:
[Message=451 5.7.3 STARTTLS is required to send mail]
You may run into “You get a blank page after logging in EAC or OWA in Exchange 2013 or Exchange 2016” or:
Read more about the fix: Exchange: An error occurred while using SSL configuration for endpoint 0.0.0.0:444 – martinsblog.dk
Replace SSL Certificate in Send Connector in Exchange Server (azure365pro.com)
Thank you for this Martin, I spent 90 minutes this morning trying to put the issuer and subject CNs into commands as per the instructions on a similar guide, thankfully found yours before I escalated. You are a legend Sir, looking forward to reading through some of your other blog entries for helpul tips.
Thanks a lot Kieran! 🙂
So I spent ages beating my head on a wall before we got ours working. If the cert you replace has the same issuer and subject name, for some reason it’s apparently not clever enough to remove the old and you end up with some hybrid of the two. Doesn’t matter that you did it by thumbprint, anyway. Mail flow never stopped working for us, but even after running the commands it still wouldn’t let me delete the old cert because it thought it was still assigned. There’s a comment on OP’s source link from someone who fixed it by temporarily assigning a random cert to the send connectors, deleting the old cert, then assigning the correct cert. You’ll lose mail flow for a few minutes but I can confirm that doing that works fine.
Hi, I normally assign the selv-signed cert temporarily if that happens, delete the old cert and the assign the new one 🙂
Do you have to run the iisreset command after amending the send and receive connector to delete the old certifcate?
I would always do that after cert replace 🙂
Do you need to run the IISRESET command after changing the thumbprint to the self signed certifate? or should you be able to delete the old certificate just amending the send and receive connectors.
You can delete the cert without restart, but I would always do it, after “job done” and check the setup.
Unbelievable man, you’re the best.
I’ve almost rerun Hybrid Configuration Wizard because we renewed certificate of our on premises server but conectors didnt work anymore. With Strange DNS errors. However stopped in the same day of old expired certificate.
Thanks from Brazil!
Your blog was saved in my Bookmarks.
Unbelievable man, you’re the best.
I’ve almost re-run Hybrid Configuration Wizard because we renewed certificate of our on premises server but conectors didnt work anymore. With Strange DNS errors. However stopped in the same day of old expired certificate.
Thanks from Brazil!
Your blog was saved in my Bookmarks.
Thanks for this Jurandir 🙂
Best regards Martin
For anyone having issues getting the thumbprint of a new cert because the name is the same you can run this command to get the full details:
get-exchangecertificate | format-list
The last cmdlet misses an “e”: $tlscertificatenam
Updated, thanks for pointing it out 🙂
Absolutely fantastic blog – Thank you
I was able to remove an expired certificate from ECP using your Powershell commands. Good explained.
Could the incorrect send connector outbound to office 365 for an on-prem exchange server cause problems with the calendar for Microsoft teams?
I’ve been investigating an issue for a company whose entire organisation has lost the calendar and the timings between a certificate being renewed and the calendar being lost seems beyond coincidence.
Yes maybe the OAUTH Token issue?
Better put people with Exchange ONline license, gives the best experience for them. no matter what. But I guess there are reasons for not doing so? 🙂
I’m glad I found your blog. I have an issue that occured in my Exchange 2016/MS365 hybrid-environment after the SSL certificate was renewed. The consequences where the following:
1) the mail flow stopped (no inbound mail to clients)
2) the ECP and OWA became inaccessible.
The first issue was corrected quickly by finding the thumbprint of the new SSL wildcard/SAN cert and fixing it like described here. Reset IIS and mailflow back on again after a matter of minutes.
However, the access for ECP/OWA is still broken (for the accounts that still only resides on the on-prem server, I should point out. They have not been migrated yet because of various reasons).
The issue/error is presented like this:
The OWA and ECP sites are up and running, looking fine. But when trying to log in with verified credentials, the site only seem to “blink”/refresh.
It is not presenting any error code, change of URL or similar.
Logs in Windows/Exchange/IIS shows nothing that indicates an error.
If I enter the wrong password intentionally for an account, it correctly says the password is wrong. So authentication is working, and this confuses and stressed me out, as this has been going on for a few days now.
What I have tried the following to no avail:
* Using multiple computers and browsers
* Cleaning local browser caches
* Updating the configurations for ECP/OWA Default web sites and back end sites (after finding this suggestion on another forum with similar issues)
* Restarting services
* Restarting server
* Checked logs
* Validated the Authentication settings in IIS
* Validated bindings for the sites
* Ran Exchange health check with nothing indicating related issues.
I’m am totally out of ideas and both our on-prem server supplier (have updated our certificates many times over the years) and Microsoft 365-support have not figured it out and are blaming each other over this.
If you or anyone else reading this have any suggestions or direct solutions you would be life savers.
Many thanks in advance,
have you checked:
Yes, that was one of the first inputs I stumbled across in my search for an answer. Even though it doesn’t reflect my issue (as I am not getting a blank screen, the screen just refreshes) I looked at the suggestions and tried them out, resulting in no change :/
OK, what about the event logs?
The logs does not contain anything remotely related to any errors that could be the result of the issue at hand, unfortunately.
However, the problem has now been resolved. The issue was that there was a sneaky Auth certificate that had expired some 40 days ago. When we earlier replaced the third party Oauth certificate and ran the HCW (as we are in hybrid mode) it must have “locked” this already expired Auth certificate, thus blocking any login attempts for OWA/ECP.
The solution was to create a new certificate, connect it to the right service (SMTP), restart IIS and then finally run the HCW again and voilá!
Thanks for taking the time and I hope this might help others with the same frustrating issue
Thanks for the follow up Jonas – glad you got it resolved anyway:-)
I have run into the issue:-
“The command completed successfully but no settings of ‘Outbound to Office 365’ have been modified.”
But I dont understand what is meant by “Just add another cert on the servers thumbprint to the first script, then run all commands throgh, after that, do the same again, but now with the real cert’s thumbprint, and it works”
Do I temporally add another cert that is listed as being on the server, like one of the internal ones, then that will free up the expiring ext. cert.. then delete the expiring cert, then rerun and add the new ext. cert?
Just use any other thumprint, that is installed on the server, and then, right after, use the “right” one, it makes the server “swap” the cert 🙂
It cannot handle to get the same thumbprint twice, right after each other. 🙂
Thanks Martin, all sorted now. 🙂
We are running Exchange Server 2016 and followed these excellent directions. Thank you. One question though is when I run Get-HybridConfiguration the tlscertificate is not updated to the new cert. Is this normal following the update of the connectors without running the HCW?
You need to run the HCW again after cert upgrade 🙂
I have multiple Exchange servers in my environment, one of which is the Hybrid. Can you confirm if it’s necessary to update the receive connector on all servers, or just on the Hybrid server?
The server that is exchanging email between on-prem and the cloud 🙂
Thanks v much! I was able to identify this (I actually had two) with:
Get-ExchangeServer | Get-ReceiveConnector | ft Name, Server, TlsCertificateName
I’m also in the position of having to round-trip through a temporary certificate, and I’ve found that for the send connector, I need to first assign the temporary cert to all of my servers, then iisreset and remove the old cert from all of them, then finally I can reassign the new cert to them all. If I do one server at a time I need to round-trip the send connector separately for each server.
Glad to hear 🙂
Thanks for the feedback 🙂
Great writeup. We have a strange issue in our Hybrid with 2013 environment. The certificates are updated and it show good in Shell and ECP however users are getting prompts in Outlook telling them that your owa certificate is expired, same goes with Autodiscover. Found out that somehow users are still receiving old certificate that expired few days ago.
Any ideas? Thanks.
Did you do a IISRESET and server restart?
Sorry for late reply….
Have you a load balancer in front of your autodiscover seever(s)? Clients may be getting their cert from that, and you’ll need to update it there too.
Ok question how can I check if the send and receive connector are using the renewed SSL Cert? Our SSL was renewed back in Nov 2022 and currently mail flow is working fine but when we go to delete this expired SSL we get the same error message as in this post.
Now I dont know what process was followed back in Nov as the tech that did the work has left the company. Is it ok for me to run commands from this post, even if the send connectors are already using the new SSL certificate, this wont break anything? Or because mail flow is working between On-Prem and O365 it is safe to just go ahead and delete the expired SSL without running the commands
I would change the cert back and forth, as when the thumbprint is the same, reboot the server to make sure things got in place, and the server is using the right certificate.