Certificate for Hybrid Connector

Steel Contributor

Hey Jeff,

Hope you are having a good morning. I will do my best to address all your questions ><

1. Yes, I have found that is the easiest way to do it most times, just re-run the HCW, insert the new cert, and you should be good to go.

2. So your question to me really comes off about exchange connectors. When you go there you have the option. I can say for connectors I always recommend my clients use the cert (when possible), as then you are confident everything is securely transmitted, and done so using the cert you control. IPs can work, and realistically are there as sometimes you are going to be setting up a connector to another organization that all you have to go on is an IP (think a third party service that you need to send directly too). But when you are talking hybrid, it is a more secure organizational relationship, which is why the HCW is defaulting into the cert method.

3. So I have done this a number of times, both for clients on-prem, as well as clients that have servers in things like azure. Its actually kind of nice, as with the TLS connector, you dont get limited by allot of the pretty restrictive things that O365 SMTP sending does. In short, they only really care if you are sending spam.

I have always created a new connector based on IP to do this. Since the reason I was creating this connector was to send external mail, I essentially had one connector on-prem that sent mail to O365 based on my internal domain, and one connector on-prem that followed the path described in option 3 of you article. That connector was set to get everything else. They both sent to O365, but since I had it setup as such, it would send mail to O365 then externally.

Adam

Adam Ochs
Steel Contributor
Oct 16, 2018
Hey Dale,

Sorry for the delay, I had a pretty busy monday :0

So some background first. I came from a managed services provider. Allot of times my clients had a Hybrid exchange server because they needed it for O365. As such they typically had 1, maybe in a stretch 2 exchange servers that were never really used for anything other than metadata edits, the normal Active Directory work, and some SMTP traffic. For them, the HCW re-run was almost always the easiest to understand, and simplest to execute, as they had done it before and we only had one server to hit (often a 2016 that did everything).

1. I would actually in your case update the SSL certs on your legacy servers manually, rather than re-running the HCW over and over. https://docs.microsoft.com/en-us/Exchange/architecture/client-access/renew-certificates?view=exchserver-2019 . I believe the SSL cert is just needed on the CAS servers, but to be honest its been a bit since ive done this on 2010, so someone may know better than me. With that said, if you setup a secure connector in the past (which the HCW would have done by default) you have to look there too.
- If you want the communication between O365 and your server to be secure/use the cert, you would also need to update the connector that handles communication from your server and O365. I would recommend rather than messing with this to just re-run the HCW on one of the servers (likely the one you ran it on last time). But instead of running this twice (or 4 times) based on your CAS servers, just update it manually once or twice, and run the HCW once.

2. I think I addressed this in the above subpoint if I understood your question. If you are talking about SMTP traffic with O365, then the connector will need to be updated, which the HCW should do. If you are talking about SMTP traffic with the outside work, you likely need to update the SSL cert on those servers the same way discussed in the first part of the previous question (which again if you know your way around your servers *which you do* manually is quicker).

Hope this helps!
Adam
- Deleted
  Nov 18, 2018
  Thank you very much for your reply Adam, I thought I'd share the steps I took so that it may help someone on here in the future...
  
  Implementation steps:
  Assign the new SSL certificate to IIS, POP, IMAP services as normal.
  Assign the new SSL certificate to SMTP service, when prompted to replace the default SMTP certificate click no. If the new SSL certificate is not a renewal, or signed by a new CA, this will break mail flow until the HCW has been re-run.
  I only had to re-run the HCW once on one of the CAS servers. I did try updating to the latest HCW but didn't work as I required .NET 4.6.2 so just ignored that bit and ran whichever version was released November 2017.
  I clicked through all the settings as the state engine filled in the existing configuration. I did notice a bug with the version of the HCW I was running but I'm sure this has been resolved with newer versions. The "Enable centralized mail transport" option was unchecked even though this was configured. I selected this option again and continued.
  At the Transport Certificate section I selected the new SSL certificate from the drop down.
  I then carried onto the end of the wizard and clicked Update to make the SSL certificate change.
  Once completed, no other changes were required and mail flow was still working and using the new SSL certificate! Nice and easy to be honest.
  Few things I checked post change:
  The HCW logs are always interesting to check and you can see the commands used to configure the new SSL certificate:
  %AppData%\Roaming\Microsoft\Exchange Hybrid Configuration
  
  Send test emails and check Message Trace in Security & Compliance Center for SUCCESSFUL events to see emails delivered from Exchange Online to the on-premise hub transport servers.
  Using Exchange Online PowerShell confirm the attribute "TlsSenderCertificateName" has been updated on the Inbound Connector "Inbound from xxx-xxx-xxx-xxx":
  Get-InboundConnector | Select TlsSenderCertificateName
  
  From an on-premise Exchange server check the "SecureMailCertificateThumbprint" has been updated:
  Get-HybridConfiguration | Select SecureMailCertificateThumbprint
  
  Thanks,
  
  Dale

Forum Discussion

Share

Resources