Of course, you can derive this name from X509 certificate object in PowerShell where you identify this certificate by its thumbprint, but only two property will be used to bind the certificate to the connector. No information about certificate thumbprint stores here. Only two of this properties forms TlsCertificateName value in format “ Certificate.Issuer Certificate.Subject”. This property can contain only “SmtpX509Identifier” object class that has only three properties: CertificateIssuer, CertificateSubject and CertificateCommonName. When you enable “TLS required” end set X509 certificate to the connector for mutual authentication, the only way to bind the X509 certificate to the connector is the “TlsCertificateName” property. It’s not Office 365 issue, but the peculiarity of certificate binding method to SMTP connector object in Microsoft Exchange Server. Maybe this will be useful for readers of this blog. And exactly at the time of expiration, my mail flow was stopped. I faced a similar issue after replacement certificate that near to expire. Hopefully, we will see this change in the future update to Office 365. It’s uncertain why Office 365 does not attempt to match the thumbprint rather than just the common name. Click Yes to confirm.Īs soon as we removed the incorrect duplicate certificate from the problem server (and retried the messages in the queue) mail started to flow. Right click on the duplicate and select Delete from the context menu. Your duplicate is most likely here.ĭetermine which certificate is incorrect from the thumbprint. Click Ok.īack on the console expand Certificates (Local Computer) > Personal > and select Certificates. Outbound to Office 365, Local computer > Finish. From face value, everything on the certificate looked correct. This indicated an issue with our certificate. However, this was quickly followed with the error TLS negotiation failed with error NoCredentials. By line 14 we could see our server was transmitting its SSL certificate. Once we re-tried a few of the messages in our queue we examined the SMTP logs. Like our telnet test, we could see Exchange was making the initial connection to Office 365. Second that this server could resolve and reach Office 365 servers. First that this server was not being blocked on outbound port 25. For this task, we confirmed that we could telnet over port 25 to Office 365 and send an email message. While we waited for logging to generate some entries we also confirmed that we could successfully make a connection from the problem server to Office 365. The default location for SMTP send logs in Exchange 2016 is %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend. Keep in mind this will disrupt mail flow on that server while the service restarts. You can jump-start this process by restarting the Microsoft Exchange Transport service. Note: Protocol logging can take some time before it starts creating log files. C:\> Set-SendConnector -Identity "Outbound to Office 365" -ProtocolLoggingLevel Verbose To perform this same action through the Exchange Management Shell (EMS) type the following command. Double click the send connector named Outbound to Office 365 and select Verbose under the General tab. To enable logging on a send connector, log into the Exchange Admin Center (EAC) and select the Mail Flow tab and Send Connectors sub-tab. Turn up logging on the SMTP Send Connector For that level of detail, we need to enable logging on the SMTP send connector used to send mail to Office 365. Unfortunately, it does not give us much detail beyond that. This message tells us that the server was unable to connect to Office 365. Either there are no alternate hosts, or deliver failed to all alternate hosts. 451 4.4.0 Primary target IP address responded with: "421 4.2.1 Unable to connect." Attempted failover to alternate host, but that did not succeed. The queues were filled with retries such as these. On the problem server, messages would get stuck in the queue and eventually time out. What made this situation particularly strange is that other Exchange servers in the environment had no problem sending messages over the hybrid connection. Ran into a strange problem recently where an Exchange 2016 server could not send mail to Office 365 via hybrid mail flow.
0 Comments
Leave a Reply. |