☰

通过混合 O365 从外部到本地 Exchange 的邮件流仍处于待处理状态

tag-icon • tag-icon exchange-2010 exchangeonline
通过混合 O365 从外部到本地 Exchange 的邮件流仍处于待处理状态

为这件事我真是绞尽脑汁。

今天使用混合配置向导设置了 2010-O365 混合设置，但邮件已经等待了好几个小时，试图找出延迟的原因。

所有错误均为：

Reason: [{LED=450 4.7.320 Certificate validation failed [Message=SubjectMismatch] [LastAttemptedServerName=mail.<companyname>.com] [LastAttemptedIP=40.97.231.242:25] [BN3NAM04FT016.eop-NAM04.prod.protection.outlook.com]};{MSG=SubjectMismatch};{FQDN=mail.<companyname>.com};{IP=40.97.231.242};{LRT=1/27/2019 6:51:39 AM}]. OutboundProxyTargetIP: 40.97.231.242. OutboundProxyTargetHostName: mail.<companyname>.com

我有：

  • Enable-ExchangeCertificate -thumbprint <hash> -services:SMTP在 Exchange 服务器上，然后重新启动传输中心（无法使用 get-receiveconnector，因为 Exchange 2010 版本的此 cmdlet 没有名为 -TlsCertificateName 的属性；仅限 2013+）
  • 尝试关闭“始终使用传输层安全性（TLS）来保护连接（推荐）”（以及 Exchange 2010 端接收连接器上的相应设置）
  • 尝试使用“任何数字证书，包括自签名证书”而不是“由受信任的证书颁发机构 (CA) 颁发：mail.<companyname>.com” （以及 Exchange 2010 端接收连接器上的相应设置）
  • 尝试打开“启用域安全（相互认证 TLS）”

就邮件流而言，有效和无效的情况如下：

Mail to O365 mailbox from external - Working
Mail from O365 mailbox to external - Working
Mail to on-prem mailbox from O365 mailbox - NOT
Mail from on-prem mailbox to O365 mailbox - Working
Mail to on-prem mailbox from external - NOT
Mail from on-prem mailbox to extenal - Working

有一个 GoDaddy 证书，其有效期为 7 个月，适用于 *.< companyname >.com，并且 Exchange 管理控制台中的服务器配置下显示有一个联合证书

我已经通过 Google 寻找了所有可能的解决方案，所以我希望这个社区中的某个人今天能够帮助我重新恢复入站邮件的流动。

答案1

我当然希望这可以帮助其他遇到同样问题的人不必花这么长时间来解决这个愚蠢的问题！

当使用 O365 混合配置向导并且有一个打算用于 O365 - 本地交换通信的通配符第三方证书时，一定要确保放入证书的主题（包括通配符，当匹配本地服务器提供的证书主题时，它似乎是按字面意思处理的，而不是通配符）。

在图 1 所示的混合配置向导步骤中放置证书的确切主题，似乎将该设置放在图 2 中的最后一个文本框中（可通过登录 O365 Exchange 管理员 -> 邮件流 -> 连接器 -> 选择连接器 -> 下一步到达此屏幕）。

图片1： 混合配置工具 TLS 配置

图片2： O365 连接器 TLS 配置

答案2

您可以尝试使用以下命令为默认前端接收连接器添加 TlsCertificateName 来解决此问题：

$tlscert=Get-ExchangeCertificate 4C0FA622D0D66E777AA123B1AF123456F001AE23
$tlscertname="<I>$($TLScert.Issuer)<S>$($TLSCert.Subject)"
Get-ReceiveConnector "SERVER1\Default Frontend SERVER1" | Set-ReceiveConnector -TlsCertificateName $tlscertname

然后重新启动传输服务，问题就解决了。

相关内容