忙/闲状态无法从 Exchange Online 转移到本地 Exchange

最近，用户开始抱怨忙/闲信息不可用，更具体地说，邮箱位于 Exchange Online 中的用户无法从仍在本地 Exchange 2010 中的同事或会议室检索可用性信息。

投诉来自多个国家/地区的多个用户，多个站点拥有多个 Exchange 2010 服务器，并且具有多个 Internet 突破点，因此该问题是一致的，并且实际上与仅一台 Exchange 2010 服务器无关。而且它仅发生在跨界，并且仅从 Exchange Online 到 Exchange 2010。从 Exchange 2010 到 Exchange Online，它运行完美，Exchange 2010 中的邮箱之间也是如此。

在使用 HCW 配置 Exchange 混合配置后，您经常会看到这种情况发生，但就我而言，它已经工作正常相当长一段时间了，因此它必须与我们最近更改的某些内容有关。我们进行了 WLAN 更改（新提供商）、Windows 更新、Exchange 2010 汇总更新、SSL 证书、新的发送和接收连接器，但没有立即指出正确的方向。更糟糕的是，远程连接分析器（故障排除时的第一站）没有发现任何问题，一切正常。自动发现从 Exchange Online 和 Exchange 2010 中的邮箱返回了正确的信息，并且 RCA 中的忙/闲测试运行良好。

注意。很多人不知道此功能，但在远程连接分析器中，您可以检查混合环境中的忙/闲情况。只需选择 Office 365 选项卡下的忙/闲单选按钮，如以下屏幕截图所示：

我的邮箱位于 Exchange Online 中，我也遇到了该问题，但同时我能够跨界打开日历。好的，这是 Outlook Anywhere，而不是 Exchange Web Services（用于忙/闲），但至少它排除了防火墙问题。

运行 Get-OrganizationRelationship 命令时，我可以验证 TargetAutodiscoverEpr 属性，该属性已设置为正确的自动发现 URL。使用 TargetSharingEpr 属性而不是 TargetAutodiscoverEpr 属性没有帮助。

Get-FederationInformation 命令与 -DomainName 开关……一切看起来都不错。
虚拟目录的安全性？运行这些命令通常可以解决意外问题：

Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WSSecurity $true
Get-WebServicesVirtualDirectory -Server WPGREXC01 | Set-WebServicesVirtualDirectory -WSSecurity $True

再次没有成功……是时候进行更深入的故障排除了。此时微软的支持也已经介入......

测试时，我可以在 IIS 日志中看到进入 Exchange 2010 服务器的请求，但服务器返回 500 错误，因此请求中的某些内容导致 Exchange 服务器出现问题：

2019-10-14 06:45:06 192.168.25.119 POST /ews/exchange.asmx/WSSecurity - 443 - 52.97.155.157 ASProxy/CrossForest/Directory/https/15.20.2347.020/MailTips - 500 0 0 31

2019-10-14 06:45:33 192.168.25.119 POST /ews/exchange.asmx/WSSecurity - 443 - 52.97.140.165 ASProxy/CrossForest/Directory/https/15.20.2347.020/MailTips - 500 0 0 31

2019-10-14 06:45:51 192.168.25.119 POST /ews/exchange.asmx/WSSecurity - 443 - 52.97.139.125 ASProxy/CrossForest/Directory/https/15.20.2347.020/Freebusy - 500 0 0 15

2019-10-14 06:45:51 192.168.25.119 POST /ews/exchange.asmx/WSSecurity - 443 - 52.97.158.5 ASProxy/CrossForest/Directory/https/15.20.2347.020/MailTips - 500 0 0 31

2019-10-14 06:45:51 192.168.25.119 POST /ews/exchange.asmx/WSSecurity - 443 - 52.97.139.125 ASProxy/CrossForest/Directory/https/15.20.2347.020/MailTips - 500 0 0 31

下一步尝试是在 IIS 管理器中回收 AutodiscoverAppPool 和 ExchangeServicesAppPool，但不幸的是这没有帮助。
在查看了窗外可能存在的问题后，我再次查看了 Exchange 服务器上的事件日志，发现了以下证书警告：

日志名称：应用
来源：MSExchange Common
日期：2019年10月16日上午9:28:59
事件ID：403
任务类别：配置
级别：错误
关键词：经典
用户：不适用
计算机：Exchange.contoso.com
说明：
联合信任“Microsoft Federation Gateway”中名为“791BC6AD9893AA570DF03452B4F8069C8A743C29”的证书已过期。请检查联合信任属性和服务器证书存储中安装的证书。

这敲响了警钟。错误消息中提到的带有指纹的证书不在 Exchange 服务器上，但在 Microsoft Federation Gateway 中。我之前没有看到这一点，但是在使用 Get-FederationTrust 检查联合时 | FL可以看到证书信息，其中一张证书已经过期了。准确地说是2019年7月。

您还可以在 Exchange 服务器上运行 Test-FederationTrust。如果您遇到此问题，您应该会在 TokenValidation 部分看到一条错误消息，例如无法验证委托令牌。

解决这个问题很简单，只需运行以下命令：

Get-FederationTrust | Set-FederationTrust -RefreshMetadata

运行此命令后，它就像一个魅力。

这种情况仅发生在 Exchange 2010 中（在 Exchange 2013 及更高版本中，它会自动修复），并且查看支持机会，当续订其他证书时，您不再运行 Exchange 2010。您可以定期运行前面提到的命令，也可以使用计划任务定期自动执行此操作。

Schtasks /create /sc Daily /tn FedRefresh /tr “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
-版本 2.0 -命令 Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.E2010;
$fedTrust=Get-FederationTrust;Set-FederationTrust -Identity $fedTrust.Name -RefreshMetadata” /ru System

那么为什么我们一开始没有注意到这一点呢？微软和其他社区博客宣布了证书变更，但当时正值暑假时间。 IT 人员资源的缺乏也无济于事。太糟糕了，但最终它被修复了（在微软支持的帮助下?）

更多信息

• 忙/闲查找在跨界环境或 Exchange 混合部署中停止工作 - https://support.microsoft.com/en-us/help/2928514/free-busy-lookups-stop-working-in-a -跨界混合环境
• 让您的 Exchange Federation Trust 保持最新状态 - http://www.expta.com/2019/07/keep-your-exchange-federation-trust-up.html
• 意识 - 您的联合信任元数据是否已更新？ - https://blogs.technet.microsoft.com/rmilne/2014/09/22/awareness-is-your-federation-trust-metadata-updated/