对 Exchange 混合环境中的忙/闲信息问题进行故障排除


该指南是做什么用的?

该指南介绍了如何对内部部署 Microsoft Exchange Server 与 Office 365 这一混合部署环境中所发生的忙/闲信息问题进行故障排除。

适用对象是哪些人?

租户管理员。 要执行其中的很多步骤都需要拥有高级访问权限。

它是如何工作的?

首先,我们要询问你遇到的问题。 然后,我们将为你介绍一系列针对你特定情况的故障排除步骤。

预计完成时间:

30-60 分钟。

选择最能确切描述你所面临的问题的选项:

注意: 如果你想要查看混合部署中忙/闲信息的工作方式,请单击“我想要更好地了解混合环境中忙/闲信息的工作方式”选项。

选择最能确切描述你所面临的问题的选项:

注意: 如果你想要查看混合部署中忙/闲信息的工作方式,请单击“我想要更好地了解混合环境中忙/闲信息的工作方式”选项。

要更好地了解混合环境中忙/闲信息的工作方式,请查看下面的流程图。 选择与你的环境相匹配的内部部署 Exchange 服务器的版本:

下图显示了 Exchange 2010/2013 忙/闲信息工作流:

P3_ExchangeWorkFlow
 


该方法是否解决了你的问题?

下图显示了 Exchange 2007 忙/闲信息工作流:

P4_ExchangeWorkFlow
 


该方法是否解决了你的问题?

下图显示了 Exchange 2003 忙/闲信息工作流:

P5_ExchangeWorkFlow
 


该方法是否解决了你的问题?

登录到内部部署用户的邮箱,然后尝试查看另一内部部署用户的忙/闲信息。 此测试用于验证你的内部部署环境中是否不存在任何可用性信息检索的问题。


你能够看到忙/闲信息吗?

此疑难解答程序用于诊断混合环境中的忙/闲信息问题。 这似乎不是刚刚发生的问题。 在解决了内部部署的忙/闲信息问题后,请重新启动此疑难解答程序。

有关如何解决一些常见内部部署忙/闲信息问题的信息,请参见 Outlook 2007 忙/闲信息疑难解答

若要确定 OWA 发来的错误消息,请执行以下步骤:

  1. 使用受影响的云用户的帐户登录到门户网站,网址为:http://portal.MicrosoftOnline.com
  2. 单击页面顶部的 Outlook。 打开 Outlook Web App。
  3. 创建新的会议请求,并将内部部署用户添加到会议中。
  4. 返回哈希标记时,将指针停留在标记上以显示错误消息。 请注意错误消息中的错误代码编号。

P8_FreeBusyStutas
 


要缩小你必须遵循的疑难解答的步骤,请在以下列表中选择相应的错误代码:

使用下面的方法来验证是否可通过外部源解析自动发现,且防火墙处于打开状态。

方法一: 验证自动发现是否被解析为内部部署 Exchange CAS 服务器

  1. 通过一台外部计算机,打开“命令提示符”,键入下面的命令并在每个命令后按 Enter 键:
    • NSLookup
    • autodiscover.<Your_Domain.com>
  2. 在命令的响应中,“Address”值应为内部部署 Exchange CAS 服务器的外部 IP。 例如: 名称:autodiscover.contoso.com 地址: 38.96.29.10

方法二: 验证你是否可以向潜在的自动发现 URL 发送自动发现 POST 请求

  1. 转到 https://www.testexchangeconnectivity.com
  2. 在“Microsoft Office Outlook 连接测试”上,选择“Outlook 自动发现”,然后单击“下一个”
  3. 填写“Outlook 自动发现”窗体(电子邮件地址、用户名和密码),然后单击“执行测试”

如果 Exchange 连接测试未能完成自动发现,请检查内部部署自动发现的 Internet 访问配置。 有关具体操作的更多信息,请参见 Microsoft TechNet 主题:配置自动发现服务的 Internet 访问


该方法是否解决了你的问题?

验证自动发现的终结点是否指向内部部署的 Exchange 混合服务器。

检查 Exchange 混合服务器上的 IIS 日志,验证此服务器是否接收了自动发现 POST 请求:

  1. 在 Exchange 混合服务器上,单击“开始”>“运行”,键入 %SystemDrive%\inetpub\logs\LogFiles,然后按 Enter 键。
  2. 打开 W3SVC1 文件夹,然后打开最新的 IIS 日志文件
  3. 搜索“Autodiscover”
  4. 下面的屏幕快照显示了一个 IIS 日志中自动发现 POST 请求的示例: 

P10_error5039
 


如果你在内部部署的 Exchange 混合部署服务器中没有看到任何条目,则防火墙可能指向了错误的 CAS 服务器。


该方法是否解决了你的问题?

组织关系中会显示域名吗?

要验证组织关系中是否含有域名值,请执行以下步骤:

  1. 使用 Windows PowerShell 连接到 Exchange Online。 有关具体操作的更多信息,请参见使用远程 PowerShell 连接到 Exchange Online
  2. 在 Windows PowerShell 中,运行以下命令: Get-OrganizationRelationship -Identity "Exchange Online to On Premises Organization Relationship" | FL
  3. 检查 DomainName 的值。 应该存在虚域 (yourdomain.com)。
  4. 如果 DomainName 的值缺少虚域,则运行以下命令: Set-OrganizationRelationship -Identity "Exchange Online to On Premises Organization Relationship" –DomainName yourdomain.com

该方法是否解决了你的问题?

是否缺少 IIS 处理程序映射?

确定 Internet Information Services (IIS) 配置是否缺少自动发现终结点的 svc 集成处理程序映射。

  1. 在内部部署的 Exchange 2010 混合部署服务器上,打开 Internet Information Services (IIS) 管理器
  2. 展开“服务器名称”->“站点”->“默认网站”,然后单击“自动发现”
  3. 在 IIS 部分,打开“处理程序映射”。 下面的屏幕快照显示了一个 IIS 中 svc 集成处理程序映射的示例:
    P12_HandlerMapping
     

如果 IIS 缺少 svc 集成的处理程序映射,请参见主题Office 365 和内部部署环境的混合部署中的“目标引发异常”错误


该方法是否解决了你的问题?

请按照以下步骤验证 EWS 是否有外部 URL 的集合:

  1. 在内部部署的 Exchange 混合部署服务器上,打开“Exchange 命令行管理程序”,然后运行以下 cmdlet: Get-WebServicesVirtualDirectory | FL Name,Server,externalURL
  2. 如果在 Exchange 混合部署服务器上没有 ExternalURL,则运行以下 cmdlet: Set-WebServicesVirtualDirectory -Identity "ServerName\EWS (Default Web Site)" -ExternalUrl https://mail.contoso.com/ews/exchange.asmx

该方法是否解决了你的问题?

验证 Microsoft Exchange Web 服务 (EWS) 是否可解析,并且没有任何防火墙问题。

检查 Exchange 2010/2013 CAS 服务器上的 IIS 日志,确定此服务器已经收到了 Web 服务请求。 为此,请按照下列步骤操作:

  1. 在 Exchange 2010/2013 CAS 服务器上,依次单击“开始”和“运行”,键入 %SystemDrive%\inetpub\logs\LogFiles,然后按 Enter
  2. 打开 W3SVC1 文件夹,然后打开最新的 IIS 日志文件。
  3. 在最新的 IIS 日志文件中,搜索“exchange.asmx/wssecurity”。 下面的屏幕快照显示了一个有关 IIS 日志中的请求的示例:
    P15_error5016
     
  4. 如果你在内部部署的 Exchange 2010/2013 混合部署服务器中没有看到任何“exchange.asmx/wssecurity”条目,则防火墙可能指向了错误的 CAS 服务器,或者你可能在防火墙上配置了预身份验证功能。 有关如何绕过防火墙预身份验证的详细信息,请参见如何为 Office 365 (Exchange) 混合部署配置 TMG

该方法是否解决了你的问题?

EWS 上是否缺少 IIS 处理程序映射?

确定 Internet Information Services (IIS) 配置是否缺少 EWS 终结点的 svc 集成处理程序映射。

  1. 在内部部署的 Exchange 混合部署服务器上,打开 Internet Information Services (IIS) 管理器。
  2. 展开“服务器名称”->“站点”->“默认网站”,然后单击 EWS
  3. IIS 区域中,打开“处理程序映射”。 下面的屏幕快照显示了一个 IIS 中 svc 集成处理程序映射的示例:
    P17_HandlerMapping
     
  4. 如果 IIS 缺少 svc 集成的处理程序映射,请参见支持文章 Office 365 和内部部署环境的混合部署中的“目标引发异常”错误。

该方法是否解决了你的问题?

WSSecurity 是否作为一种身份验证方法启用?

在内部部署的 Exchange 混合部署服务器上,在“Exchange 命令行管理程序”中运行以下命令: Get-WebServicesVirtualDirectory | fl name,server,externalURL,ExternalAuthenticationMethods

如果 ExternalAuthenticationMethods 缺少 WSSecurity,则在 Exchange 混合部署服务器上运行以下命令: Set-WebServicesVirtualDirectory -Identity "ServerName\EWS (Default Web Site)" –WSSecurityAuthentication $true


该方法是否解决了你的问题?

验证组织关系设置是否正确配置,以便为用户启用忙/闲信息。

对于联机设置

  1. 使用 Windows PowerShell 连接到 Exchange Online。 有关具体操作的更多信息,请参见使用远程 PowerShell 连接到 Exchange Online
  2. 在 Windows PowerShell 中,运行以下命令: Get-OrganizationRelationship -Identity "Exchange Online to On Premises Organization Relationship" | FL

输出类似于以下内容:

  • TargetApplicatioURI: FYDIBOHF25SPDLT.Contoso.com
  • TargetAutodiscoverURI: https://autodiscover.contoso.com/autodiscover/autodiscover.svc/wssecurity
  • DomainNames: {Contoso.com}
  • FreeBusyAccessEnabled: True
  • FreeBusyAccessLevel: LimitedDetails

如果必须更改一个值,请使用 "set-OrganizationRelationship" cmdlet 来修复属性。 有关语法和选项的详细信息,请参见 Set-OrganizationRelationship

对于内部部署设置

  1. 在 Exchange 2010/2013 CAS 中,在“Exchange 命令行管理程序”中运行以下命令: Get-OrganizationReationship -Identity "On Premises to Exchange Online Organization Relationship"

输出类似于以下内容:

  • TargetApplicatioURI: outlook.com
  • TargetAutodiscoverURI: https://podxxx.outlook.com/autodiscover/autodiscover.svc/wssecurity
  • DomainNames: {xxxx.mail.onmicrosoft.com,contoso.com}
  • FreeBusyAccessEnabled: True
  • FreeBusyAccessLevel: LimitedDetails

如果必须更改一个值,请使用 "set-OrganizationRelationship" cmdlet 来修复属性。 有关语法和选项的详细信息,请参见 Set-OrganizationRelationship


该方法是否解决了你的问题?

内部部署用户的邮箱位于哪个版本的 Exchange 上?

你可以通过使用内部部署的 Exchange 2010 邮箱重现这个问题吗?

  1. 作为拥有 Exchange 2010 内部部署邮箱的用户登录到 Outlook 或 OWA 客户端。
  2. 创建新的会议请求并将云用户添加到会议请求中。
  3. 当你查看计划助理时,你能看到云用户的哈希标记吗?

验证是否没有硬编码公用文件夹路由会阻止旧的忙/闲请求成功。

注意: 这不是一个常见的问题。

验证 Exchange Server 2003 属性上的 ms-Exch-Folder-Affinity-List 属性是否拥有 Exchange 2010 ObjectGUID 且成本最低(属性的格式为: {guid of server},cost)。

  1. 在域控制器上,单击“开始”>“运行”,键入 adsiedit.msc,然后单击“确定”
  2. 右键单击“ADSI 编辑”,然后单击“连接到”
  3. 在“选择已知名称上下文”上,选择“配置”,然后单击“确定”
  4. 展开“配置”->“服务”-> Microsoft Exchange ->“第一个组织”->“Exchange 管理组 (FYDIBOHF23SPDLT)”->“服务器”
  5. 右键单击“Exchange 2010 服务器”,然后单击“属性”
  6. 复制 objectGUID 值,然后将其粘贴到记事本的文本文件中。
  7. 移动到“配置”->“服务”-> Microsoft Exchange ->“第一个组织”->“Exchange 管理组”->“服务器”
  8. 右键单击 Exchange Server 2003,然后选择“属性”
  9. 请验证 ms-Exch-Folder-Affinity-List 值是否设置有 Exchange 2010 objectGUID。 如果 Exchange 2010 objectGUID 未包含在 ms-Exch-Folder-Affinity-List 上,你可以使用下面的格式来添加: {guid of server},cost。

该方法是否解决了你的问题?

外部忙/闲信息是否能够正确显示和复制?

添加 OU=EXTERNAL (FYDIBOHF25SPDLT) 公用文件夹。 为此,请按照下列步骤操作:

  1. 连接到内部部署的 Exchange 2010 SP1 或更高版本的公用文件夹服务器。
  2. 打开 Windows PowerShell。
  3. 运行下面的 cmdlet: Add-PsSnapin Microsoft.Exchange.Management.Powershell.Setup
  4. 运行下面的 cmdlet: Install-FreeBusyFolder

注意: OU=EXTERNAL (FYDIBOHF25SPDLT) 公用文件夹只能显示在 Exchange 2010 服务器上,不可复制到 Exchange 2003 或 Exchange 2007 上。


该方法是否解决了你的问题?

验证内部部署服务器上的收件人对象是否已正确配置了 LegacyExchangeDN。

  1. 每个云邮箱将具有一个相应的启用邮件的对象,该对象为内部部署。 对于此类忙/闲信息查询,我们使用 LegacyExchangeDN 来路由我们对适当公用文件夹服务器的请求。 若要确保此值的精确度,请执行以下操作:
  2. 在 Exchange 2010 服务器上,在“Exchange 命令行管理程序”中运行以下命令: Get-RemoteMailbox Username |fl LegacyExchangeDN,其中的用户名是你尝试查看其忙/闲信息的云用户的用户名。
  3. 在结果中,请验证外部 (FYDIBOHF25SPDLT) 是否在路径中。 例如,结果应按以下方式显示路径: 
    P24_CannotSeeBusyFree
     

该方法是否解决了你的问题?

验证公用文件夹上的权限。

要使用 Exchange 2010 公用文件夹管理控制台更改查看外部 (FYDIBOHF25SPDLT) 忙/闲信息副本的客户端权限,请遵循以下步骤:

  1. 启动 Exchange 2010 公用文件夹管理控制台。
  2. 在控制台树中,单击“工具箱”
  3. 在结果窗格中,单击“公用文件夹管理控制台”,然后在操作窗格中,单击“打开工具”。 随即显示“公用文件夹管理控制台”。
  4. 在“公用文件夹管理控制台”中,在操作窗格中,单击“连接到服务器”
  5. 在“连接到服务器”上,单击“浏览”,查看包含公用文件夹数据库的可用邮箱服务器的列表。
  6. 在“选择公用文件夹服务器”中,选择 Exchange 2010 服务器。 单击“确定”,然后再单击“确定”
  7. 在“公用文件夹”树中,移动到“系统公用文件夹”-> SCHEDULE+ FREE/BUSY
  8. 在“结果”窗格中,右键单击 EX:/O=FIRST ORGANIZATION/OU=EXTERNAL (FYDIBOHF25SPDLT),然后单击“属性”
  9. 在“权限”选项卡上,确认为“默认用户”选择了“编辑所有权限级别”: 
    P25_CannotSeeBusyFree
     

该方法是否解决了你的问题?

仲裁邮箱是丢失还是被损坏?

可以通过使用ADSIEdit 来编辑仲裁邮箱。 federated.email 帐户应位于 Exchange 2010 域的 Active Directory 的默认用户容器内。

使用下面的任一选项:

  1. 使用 adsiedit。
    1. 连接到 Active Directory 中的默认命名上下文。
    2. 浏览到用户容器,然后查看 federatedemail 帐户的属性。
    3. 将该帐户的 proxyaddress 属性更改为已通过联合身份验证的 SMTP 地址中的任一地址,或在联合身份验证信任中添加已存在的代理地址命名空间。
  2. 从 Exchange Server 2003 中,打开“Active Directory 用户和计算机”。
    1. 移动到用户容器,右键单击 FederatedEmail 帐户,然后单击“属性”。
    2. 如果你转到电子邮件地址选项卡,你可以添加另一个代理地址,以匹配已经配置的联合身份验证命名空间,或向联合身份验证信任添加已经存在的主 SMTP 命名空间。

该方法是否解决了你的问题?

你是否可以重现内部部署 Exchange 2010 或 2013 邮箱?

  1. 作为拥有 Exchange 2010 或 2013 内部部署邮箱的用户登录到 Outlook 或 OWA 客户端。
  2. 创建新的会议请求并将云用户添加到会议请求中。
  3. 当你查看计划助理时,你能看到云用户的哈希标记吗?

检查可用性地址空间,以确保它已正确设置。 此问题可能是由于 AvailabilityAddressSpace 的配置不正确造成的。 检查 AvailabilityAddressSpace 配置的 ProxyURL 值是否匹配 Exchange 2010/2013 CAS Web 服务虚拟目录的 InternalURL。 为此,请按照下列步骤操作:

  1. 在内部部署服务器上,在“Exchange 命令行管理程序”中运行以下命令:
    Get-AvailabilityAddressSpace | FL ProxyUrl
    Get-WebServicesVirtualDirectory | FL Server,InternalUrl
  2. 如果 ProxyURL 与 InternalURL 的值不匹配,则运行以下命令:
    Remove-AvailabilityAddressSpace -Identity ‘contoso.mail.onmicrosoft.com'
    Add-AvailabilityAddressSpace -ForestName contoso.mail.onmicrosoft.com' -AccessMethod 'InternalProxy' -UseServiceAccount
    'True' -ProxyUrl https://cas2010.contoso.com/ews/exchange.asmx
  3. 如果 ProxyURL 与 InternalURL 的值匹配,则应确保你可以通过 Exchange 2007 CAS 服务器访问 URL。 若要执行此操作,请从 CAS 2007 转移到 AvailabilityAddressSpace from 的 ProxyURL。 对 Exchange 2007 源邮箱凭据进行身份验证。 期望的结果如下: 
    P28_CannotAccessBusyFree
     

注意: Exchange 2010/2013 CAS Web 服务虚拟目录的 InternalURL 应与 Exchange 2007 CAS Web 服务虚拟目录的 InternalURL 不同。


该方法是否解决了你的问题?

登录到内部部署用户的邮箱,然后尝试查看另一内部部署用户的忙/闲信息。 此测试用于验证你的内部部署环境中是否不存在任何可用性信息检索的问题。 


你能够看到忙/闲信息吗?

确定你从 OWA 收到的错误消息。

  1. 使用受影响的用户帐户登录到内部部署的 OWA。
  2. 创建新的会议请求,并将内部部署用户添加到会议中。
  3. 返回哈希标记时,将指针停留在标记上以显示错误消息。 请注意该错误消息中的错误代码编号。
    P30_OnPremisesCannotSeeBusyFree
     

要帮助缩小你必须遵循的疑难解答的步骤,请在以下列表中选择相应的错误消息:

如果你的环境中必须设置 web 代理,请验证内部部署 Exchange 2010 和 Exchange 2013 服务器是否设置为使用代理。

在内部部署的 Exchange 2010 和 Exchange 2013 服务器上,在“Exchange 命令行管理程序”中运行以下命令: "Get-ExchangeServer | fl InternetWebProxy."

在大多数环境中,结果将为空。 但是,如果在你的内部部署环境中设置了传出代理,则你需要配置正确的代理设置。

要解决此问题,可以运行以下命令,其中地址和端口号 http://192.168.5.56:8080 将换为你服务器的地址和端口号:

Set-ExchangeServer -InternetWebProxy http://192.168.5.56:8080


该方法是否解决了你的问题?

验证组织关系设置是否正确配置,以便允许用户查看忙/闲信息。

对于联机设置

  1. 使用 Windows PowerShell 连接到 Exchange Online。 有关具体操作的更多信息,请参见使用远程 PowerShell 连接到 Exchange Online
  2. 在 Windows PowerShell 中,运行以下命令: Get-OrganizationRelationship -Identity "Exchange Online to On Premises Organization Relationship" | FL

输出类似于以下内容:

  • TargetApplicatioURI: FYDIBOHF25SPDLT.Contoso.com
  • TargetAutodiscoverURI: https://autodiscover.contoso.com/autodiscover/autodiscover.svc/wssecurity
  • DomainNames: {Contoso.com}
  • FreeBusyAccessEnabled: True
  • FreeBusyAccessLevel: LimitedDetails

如果必须更改一个值,请使用 "set-OrganizationRelationship" cmdlet 来修复属性。 有关执行此操作的语法和选项的详细信息,请参见 Set-OrganizationRelationship

对于内部部署设置

从 Exchange 2010/2013 CAS 中,在“Exchange 命令行管理程序”中运行以下命令:

Get-OrganizationReationship -Identity "On Premises to Exchange Online Organization Relationship"

输出类似于以下内容:

  • TargetApplicatioURI: outlook.com
  • TargetAutodiscoverURI: https://podxxx.outlook.com/autodiscover/autodiscover.svc/wssecurity
  • DomainNames: {xxxx.mail.onmicrosoft.com,contoso.com}
  • FreeBusyAccessEnabled: True
  • FreeBusyAccessLevel: LimitedDetails

如果必须更改某个值,则应使用“set-OrganizationRelationship”cmdlet 来修复属性。有关执行此操作的语法和选项的详细信息,请参见 Set-OrganizationRelationship


该方法是否解决了你的问题?

请确保在你服务器上设置的时间的误差不要超过 5 分钟。 如果服务器上的时间与实际时间相差 5 分钟以上,则与 federation gateway 之间的通信将变为无效。 这将导致忙/闲信息失败。

有关如何修复服务器时间问题的信息,请参见如何在 Windows 服务器上配置权威时间服务器


该方法是否解决了你的问题?

确定是否在 MEU 内部部署上指定了正确的目标地址。 每个云邮箱都将有一个相应的内部部署对象。 此对象必须指定了正确的远程路由地址(也称为目标地址)。 该远程路由地址应包含类似于 TenantName.Mail.OnMicrosoft.com 这样的域名。

要验证远程路由地址是否已配置,请执行以下步骤:

  1. 在 Exchange 2010 服务器或 Exchange 2013 服务器上,在“Exchange 命令行管理程序”中运行以下命令: Get-RemoteMailbox Username |fl RemoteRoutingAddress,其中的用户名是你尝试查看其忙/闲信息的云用户的用户名。
  2. 验证该地址是否包含 TenantName.Mail.OnMicrosoft.com
    P34_CannotSeeBusyFree
     

注意: 如果你未使用混合配置向导,则域名应反映出你所选择的远程路由域。


该方法是否解决了你的问题?

验证组织关系设置是否正确配置,以便为用户启用忙/闲信息。

对于联机设置

使用 Windows PowerShell 连接到 Exchange Online。 有关具体操作的详细信息,请参见连接 Windows PowerShell 与服务

在 Windows PowerShell 中,运行以下命令: Get-OrganizationRelationship -Identity "Exchange Online to On Premises Organization Relationship" | FL

输出类似于以下内容:

  • TargetApplicatioURI: FYDIBOHF25SPDLT.Contoso.com
  • TargetAutodiscoverURI: https://autodiscover.contoso.com/autodiscover/autodiscover.svc/wssecurity
  • DomainNames: {Contoso.com}
  • FreeBusyAccessEnabled: True
  • FreeBusyAccessLevel: LimitedDetails

如果必须更改一个值,请使用 "set-OrganizationRelationship" cmdlet 来修复属性。 有关执行此操作的语法和选项的详细信息,请参见 Set-OrganizationRelationship

对于内部部署设置

从 Exchange 2010/2013 CAS 中,在“Exchange 命令行管理程序”中运行以下命令: Get-OrganizationReationship -Identity "On Premises to Exchange Online Organization Relationship"

输出类似于以下内容:

  • TargetApplicatioURI: outlook.com
  • TargetAutodiscoverURI: https://podxxx.outlook.com/autodiscover/autodiscover.svc/wssecurity
  • DomainNames: {xxxx.mail.onmicrosoft.com,contoso.com}
  • FreeBusyAccessEnabled: True
  • FreeBusyAccessLevel: LimitedDetails

如果必须更改一个值,请使用 "set-OrganizationRelationship" cmdlet 来修复属性。 有关执行此操作的语法和选项的详细信息,请参见 Set-OrganizationRelationship


该方法是否解决了你的问题?

验证是否可以创建一个含有测试联合身份验证信任的令牌。

从内部部署环境中,验证你是否可以检索将用于忙/闲授权的委派令牌。 为此,请按照下列步骤操作:

  1. 从内部部署的 Exchange 2010 或 2013 服务器上,打开“Exchange 命令行管理程序”。
  2. 运行以下命令: Test-FederationTrust –UserIdentity User@company.com –verbose,其中 User 是看不到云用户忙/闲信息的内部部署用户。
  3. 输出应显示为每个测试都成功。 如果出现故障,应再次使用混合配置向导,尝试重置此联合身份验证信任。
    P36_CannotSeeBusyFree
     

该方法是否解决了你的问题?

如果服务器上的时间与实际时间相差 5 分钟以上,则与 federation gateway 之间的通信将变为无效。 这将导致忙/闲信息失败。

有关如何修复服务器时间问题的信息,请参见如何在 Windows 服务器上配置权威时间服务器


该方法是否解决了你的问题?

本演练用于对混合环境中出现的忙/闲信息问题进行疑难解答。 根据你的回答,你存在内部部署问题。 有关如何解决一些常见内部部署忙/闲信息问题的信息,请参见 Outlook 2007 忙/闲信息疑难解答

本忙/闲信息指导性演练并不能解决公用文件夹的问题。 有关公用文件夹问题的疑难解答的详细信息,请参见如何解决 Exchange 2000 服务器和 Exchange Server 2003 中公用文件夹的复制问题

感谢你使用忙/闲信息指南。

很抱歉,我们无法通过使用此指南解决该问题。