解决 Teams 与 Exchange Server 之间的交互问题

• 适用于:

  Microsoft Teams

首先，检查有关如何Microsoft Exchange Server和 Microsoft Teams 交互以验证其版本和环境在部署中的兼容性的信息。

症状

问题 1：代理人无法代表委派人安排 Teams 会议

其邮箱托管在 Exchange Server 的用户将另一个用户添加为管理 Microsoft Outlook 日历的代理人。 使用适用于 Outlook 的 Teams 加载项的代理人无法代表委托人安排 Teams 会议，Outlook 返回以下错误消息：

看起来你没有权限为此帐户安排会议。 请与所有者联系以获得权限，然后重试。

问题 2：尝试使用 Teams 日历应用时遇到问题

出现以下任一问题：

• 日历图标没有显示在 Teams 客户端中。
• 当你使用 Teams 桌面客户端或 Web 客户端时，Teams 日历应用会显示“抱歉，我们无法获取你的会议详细信息”错误消息。

Teams 日历应用需要通过 Exchange Web Services (EWS) 访问 Exchange 邮箱。 Exchange 邮箱可以在 Exchange 混合部署范围内联机或本地。

问题 3：当用户参加 Outlook 日历会议时，Teams 中的状态停滞在外出或未显示“正在开会”

其邮箱托管在本地 Exchange 服务器上的用户已关闭 Outlook 客户端中的自动答复功能，但对同一组织中的所有 Teams 客户端显示“外出”Teams 状态。 这可能持续好几天。

注意

对于内部托管邮箱的用户，预计存在最长一小时的延迟。

用户正在参加 Outlook 日历会议，但 Teams 状态没有更新为“在会议中”。

先决条件

若要将 Teams 服务与安装Exchange Server集成，请确保本地Exchange Server环境满足以下要求：

• Microsoft Teams 必须知道邮箱是托管在Exchange Online、本地还是混合 Exchange 服务器部署中。 Teams 服务通过 REST API 调用Exchange Online服务，该 API 会根据混合配置重定向到托管邮箱（如果适用）的本地服务器。

• Exchange Online 与内部部署 Exchange 服务器环境相集成，如什么是 OAuth 身份验证？中所述。 最好通过运行 Exchange 混合向导对其进行配置，但可以手动实现相同的结果，如在 Exchange 与 Exchange Online 组织之间配置 OAuth 身份验证中所述。 Exchange Online 由应用程序 ID 00000002-0000-0ff1-ce00-000000000000表示。

• 此外，Teams 服务需要代表用户进行身份验证，才能使用 OAuth 访问本地托管的邮箱。 在这种情况下，Teams 计划服务使用 Skype for Business Online 00000004-0000-0ff1-ce00-000000000000 的应用程序 ID，以及配置 Skype for Business Online 与 Exchange Server 之间的集成和 OAuth 中引用的 MailUser：

  • 该帐户从 Exchange 通讯簿中隐藏。 最佳做法是在通讯簿中隐藏帐户，因为它是禁用的用户帐户。
  • 该帐户的 Exchange 管理角色分配为 UserApplication。
  • 对于保留和存档，需要 分配 ArchiveApplication 的角色。
  • 必须为整个 Teams 和 Exchange 服务器内部部署执行文中说明的所有步骤。

注意

此处提供了 Microsoft 标识平台和 OAuth 2.0 的使用示例

• 你应将面向 Internet 的防火墙或反向代理服务器配置为允许 Microsoft Teams 访问运行 Exchange Server 的服务器，方法是将 Skype for Business Online 和 Microsoft Teams 的 URL 和 IP 地址范围添加到允许列表中。 有关详细信息，请参阅 Microsoft 365 URL 和 IP 地址范围的“Skype for Business Online 和 Microsoft Teams”部分。

• 需要 Exchange 自动发现 V2 来允许 Teams 服务对位于 Exchange Server 中的用户邮箱执行未经身份验证的发现。 Exchange Server 2013 累积更新 19 或更高版本完全支持自动发现 V2。 这足以使 Teams 委派正常工作。 但是，Teams 日历应用需要安装 Exchange Server 2016 累积更新 3 或更高版本。 因此，对于完整功能支持，需要 Exchange Server 2016 累积更新 3 或更高版本。

常见故障排除步骤

注意

这些故障排除步骤适用于上面列出的所有问题。

步骤 1：验证自动发现服务是否正常工作

Teams 服务使用 Exchange 自动发现服务查找由运行 Exchange Server 的服务器发布的 EWS URL。 若要验证自动发现过程是否正常工作，请使用以下步骤：

1. 要求用户导航到 Microsoft Remote Connectivity Analyzer。 远程连接分析器工具使用一组特定的 IP 地址来查找 EWS URL。 有关 Microsoft 365 的这些 IP 地址的列表，请参阅 Microsoft 365 URL 和 IP 地址范围中的 ID 46 的信息。

2. 选中“使用自动发现检测服务器设置检查”框。

3. 输入请求的信息。

4. 选择“执行测试”按钮开始自动发现测试。

如果测试失败，你必须首先解决自动发现问题。

注意

对于 Teams 委派问题，请测试委托人的邮箱。 对于 Teams 日历应用和 Teams 状态问题，请测试受影响的用户的邮箱。

第 2 步：验证自动发现服务能否将自动发现请求路由到本地

在 Windows PowerShell 中，运行以下命令：

Invoke-RestMethod -Uri "https://outlook.office365.com/autodiscover/autodiscover.json?Email=onpremisemailbox@contoso.com&Protocol=EWS&RedirectCount=5" -UserAgent Teams

注意

对于 Teams 委派问题，请测试委托人的邮箱。 对于 Teams 日历应用和 Teams 状态问题，请测试受影响的用户的邮箱。

对于本地托管的邮箱，EWS URL 应指向本地外部 EWS。 输出类似于以下内容：

协议 URL

-------- ---

EWS <https://mail.contoso.com/EWS/Exchange.asmx>

如果此测试失败，或者 EWS URL 不正确，请查看“先决条件”部分。 这是因为问题可能是由 Exchange 混合配置问题或阻止外部请求的防火墙或逆代理引起的。

第 3 步：验证 Exchange OAuth 身份验证协议是否已启用并正常工作

若要验证 Exchange OAuth 身份验证是否已启用并正常工作，请运行 Test-OAuthCOnnectivity 命令，如配置 Exchange 和 Exchange Online 组织之间的 OAuth 身份验证中所述。

此外，运行 Microsoft 远程连接分析器中提供的忙/闲连接测试。 为此，请按照下列步骤操作：

1. 导航到 Microsoft 远程连接分析器。

2. 选择 “忙/闲 ”测试，验证 Microsoft 365 邮箱是否可以访问本地邮箱的忙/闲信息，反之亦然。

   你必须通过将源邮箱电子邮件地址与目标邮箱电子邮件地址交换来运行此测试两次。 这是因为每次运行都是单向的。 此测试不一定必须使用受影响的帐户来运行。 可以使用任意一对本地邮箱和 Microsoft 365 邮箱来运行测试。

   若要详细了解如何在 Microsoft 365 中排查本地和Exchange Online的混合部署中的忙/闲问题，请参阅此文。

解决 Teams 委派问题

注意

这些故障排除步骤仅适用于 问题 1。

第 1 步：验证委托是否已被授予“编辑器”权限以访问委派人日历

在一台基于 Exchange 的服务器上打开 Exchange 命令行管理程序，然后运行以下 Exchange PowerShell 命令，以验证是否已将“编辑器”访问权限授予代理：

Get-MailboxFolderPermission -Identity <delegator's UserPrincipalName>:\calendar  | Format-List

检查 AccessRights 参数是否包含编辑器的值。 如果没有，请运行以下命令以授予权限：

Add-MailboxFolderPermission -Identity <delegator's UserPrincipalName>:\Calendar -User <delegate's UserPrincipalName> -AccessRights Editor

或者，要求委托人按照本文中的步骤重新配置 Outlook 客户端中的委派。

第 2 步：验证代理是否已由委托人授予“GrantSendOnBehalfto”

运行以下命令以验证是否向代理授予了 GrantSendOnBehalfTo 权限：

Get-Mailbox -Identity <delegator's UserPrincipalName> | Format-List *grant*

验证 GrantSendOnBehalfTo 参数是否包含代理的别名。 如果没有，请运行以下命令以授予权限：

Set-Mailbox <delegator's UserPrincipalName> -Grantsendonbehalfto @{add="<delegate's UserPrincipalName>"}

或者，要求委托人按照本文中的步骤重新配置 Outlook 客户端中的委派。

第 3 步：验证 Teams 未被阻止访问整个组织的 EWS

运行以下 Exchange PowerShell 命令，以检查整个组织的 EwsApplicationAccessPolicy 参数是否已设置为 EnforceAllowList：

Get-OrganizationConfig | Select-Object Ews*

如果参数设置为 EnforceAllowList，则意味着只允许 EwsAllowList 中列出的客户端访问 EWS。 空值 EwsAllowList (EwsAllowList={}) 阻止所有用户访问 EWS。

注意

阻止 EWS 也会导致 Teams 日历应用问题。 请参阅验证 Teams 日历应用是否已启用。

确保 *SchedulingService* 作为 EwsAllowList 参数的数组成员列出。 如果没有，请运行以下命令添加它：

Set-OrganizationConfig -EwsApplicationAccessPolicy EnforceAllowList -EwsAllowList @{Add="*SchedulingService*"}

如果 EwsEnabled 参数设置为 False，则必须将其设置为 True 或 Null（空白）。 否则，Teams 服务也将被阻止访问 EWS。

第 4 步：验证 Teams 没有被阻止访问委派人邮箱的 EWS

运行以下 Exchange PowerShell 命令，以检查委托人邮箱的 EwsApplicationAccessPolicy 参数是否已设置为 EnforceAllowList：

Get-CasMailbox <delegator's UserPrincipalName> | Select-Object Ews*

如果参数设置为 EnforceAllowList，则意味着只允许 EwsAllowList 中列出的客户端访问 EWS。

确保 *SchedulingService* 作为 EwsAllowList 参数的数组成员列出。 如果没有，请运行以下 Exchange PowerShell 命令以添加它：

Set-CASMailbox <delegator's UserPrincipalName> -EwsApplicationAccessPolicy EnforceAllowList -EwsAllowList @{Add="*SchedulingService*"}

如果 EwsEnabled 参数设置为 False，则必须将其设置为 True。 否则，Teams 服务也将被阻止访问 EWS。

步骤 5：升级问题

如果你验证了本文中提到的先决条件或配置没有问题，请向 Microsoft 支持提交服务请求，并提供以下信息：

• 委托人和代理的 UserPrincipalName。
• 文件夹 %appdata%\\microsoft\\teams\\meeting-addin 下的 Teams 会议加载项日志。
• 重现问题时的 UTC 时间。
• 从代理的计算机上收集的 Teams 客户端调试日志。 有关如何收集这些日志的详细信息，请参阅在对 Microsoft Teams 进行故障排除时使用日志文件。

解决 Teams 日历应用问题

注意

这些故障排除步骤仅适用于 问题 2。

第 1 步：验证 Teams 日历应用是否已启用

1. 打开 Microsoft Teams 管理中心，转到“用户”并为受影响的用户选择“查看策略”。

   

2. 选择为该用户分配的“应用设置策略”。 在上面的示例中，正在使用全局（组织范围的默认）策略。 确认显示日历应用 (ID ef56c0de-36fc-4ef8-b417-3d82ba9d073c)。

   

   如果日历应用丢失，请还原它。 有关更多信息，请参阅在 Microsoft Teams 中管理应用设置策略。

第 2 步：验证 Teams 的“升级共存”模式允许 Teams 会议

1. 打开 Microsoft Teams 管理中心。

2. 转到“用户”，并选择受影响的用户。

3. 验证“共存模式”设置的值是否不是仅 Skype for Business 或 Skype for Business 与 Teams 协作。

   

4. 如果用户共存模式设置为“使用组织范围的设置”，这意味着将使用默认租户共存模式。

5. 转到“组织范围的设置”，然后选择“Teams 升级”。

6. 验证默认“共存模式”设置是否为“仅 Skype for Business”或“Skype for Business 与 Teams 协作”以外的值。

   

第 3 步：验证 Teams 未被阻止访问整个组织的 EWS

运行以下 Exchange PowerShell 命令，以检查整个组织的 EwsApplicationAccessPolicy 参数是否已设置为 EnforceAllowList：

Get-OrganizationConfig | Select-Object Ews*

如果参数设置为 EnforceAllowList，则意味着只允许 EwsAllowList 中列出的客户端访问 EWS。

确保 MicrosoftNinja/*、 *Teams/*和 SkypeSpaces/* 列为 EwsAllowList 参数的数组成员。 如果不是，请运行以下命令以添加它们：

Set-OrganizationConfig -EwsApplicationAccessPolicy EnforceAllowList -EwsAllowList @{Add="MicrosoftNinja/*","*Teams/*","SkypeSpaces/*"}

如果 EwsEnabled 参数设置为 False，则必须将其设置为 True 或 Null（空白）。 否则，Teams 服务也将被阻止访问 EWS。

第 4 步：验证 Teams 未被阻止访问受影响用户的 EWS

运行以下 Exchange PowerShell 命令，以检查用户邮箱的 EwsApplicationAccessPolicy 参数是否已设置为 EnforceAllowList：

Get-CASMailbox <UserPincipalName> | Select-Object Ews*

如果参数设置为 EnforceAllowList，则意味着只允许 EwsAllowList 中列出的客户端访问 EWS。

确保 MicrosoftNinja/*、 *Teams/*和 SkypeSpaces/* 列为 EwsAllowList 参数的数组成员。 如果不是，请运行以下 Exchange PowerShell 命令来添加它们：

Set-CASMailbox <UserPincipalName> -EwsApplicationAccessPolicy EnforceAllowList -EwsAllowList @{Add="MicrosoftNinja/*","*Teams/*","SkypeSpaces/*"}

如果 EwsEnabled 参数设置为 False，则必须将其设置为 True。 否则，Teams 服务也将被阻止访问 EWS。

第 5 步：验证 Microsoft Teams 日历应用测试是否成功

1. 请求用户转到 Microsoft Remote Connectivity Analyzer。
2. 输入请求的信息。
3. 选择“执行测试”按钮开始 Microsoft Teams 日历应用测试。

如果测试失败，应尝试解决问题并重新运行测试。

步骤 6：升级问题

如果:你验证本文中提到的先决条件和配置没有问题，请向 Microsoft 支持提交服务请求，并提供有关以下信息：

• 受影响用户的 UserPrincipalName。
• 重现问题时的 UTC 时间。
• Teams 客户端调试日志。 有关如何收集这些日志的详细信息，请参阅在对 Microsoft Teams 进行故障排除时使用日志文件。

解决 Teams 状态问题

注意

这些故障排除步骤仅适用于 问题 3。

第 1 步：验证本地 Exchange REST API 的 URL 是否已在公共网络上发布

使用用户的邮箱查找本地 Exchange EWS URL 并更改 URL 格式，运行“常见故障排除步骤”部分中的步骤 2 。 例如，将 https://mail.contoso.com/EWS/Exchange.asmx 更改为 https://mail.contoso.com/api。

尝试从外部网络中的浏览器访问 REST API URL。 如果从本地 Exchange 环境收到 401 响应，则表示 REST API URL 已发布。 否则，请与本地网络团队联系以发布 URL。

注意

如果对 Exchange REST API 的访问失败，则表明 Teams 状态服务不支持对 EWS URL 的回退。

步骤 2：验证 Teams 状态基于日历事件测试是否成功

1. 要求用户导航到 Microsoft 远程连接分析器的“基于日历事件的 Teams 状态”部分。 远程连接分析器工具使用一组特定的 IP 地址来查找 EWS URL。 有关 Microsoft 365 的这些 IP 地址的列表，请参阅 Microsoft 365 URL 和 IP 地址范围中的 ID 46 的信息。
2. 输入请求的信息。
3. 选择“ 执行测试 ”按钮，启动 Teams 状态基于日历事件测试。

如果测试失败，应尝试解决问题并重新运行测试。

第 3 步：验证 Teams 未被阻止访问整个组织的 EWS

运行以下 Exchange PowerShell 命令，以检查整个组织的 EwsApplicationAccessPolicy 参数是否已设置为 EnforceAllowList：

Get-OrganizationConfig | Select-Object Ews*

如果参数设置为 EnforceAllowList，则意味着只允许 EwsAllowList 中列出的客户端访问 EWS。 空值 EwsAllowList (EwsAllowList={}) 阻止所有客户端访问 EWS。

确保 *Microsoft.Skype.Presence.App/* 作为 EwsAllowList 参数的数组成员列出。 如果没有，请运行以下命令添加它：

Set-OrganizationConfig -EwsApplicationAccessPolicy EnforceAllowList -EwsAllowList @{Add="*Microsoft.Skype.Presence.App/*"}

如果 EwsEnabled 参数设置为 False，则必须将其设置为 True 或 Null（空白）。 否则，Teams 服务也将被阻止访问 EWS。

步骤 4：验证是否未阻止 Teams 访问用户邮箱的 EWS

运行以下 Exchange PowerShell 命令，以检查用户邮箱的 EwsApplicationAccessPolicy 参数是否已设置为 EnforceAllowList：

Get-CasMailbox <user's UserPrincipalName> | Select-Object Ews*

如果参数设置为 EnforceAllowList，则意味着只允许 EwsAllowList 中列出的客户端访问 EWS。

确保 *Microsoft.Skype.Presence.App/* 作为 EwsAllowList 参数的数组成员列出。 如果没有，请运行以下 Exchange PowerShell 命令以添加它：

Set-CASMailbox <user's UserPrincipalName> -EwsApplicationAccessPolicy EnforceAllowList -EwsAllowList @{Add="* Microsoft.Skype.Presence.App/*"}

如果 EwsEnabled 参数设置为 False，则必须将其设置为 True。 否则，Teams 服务也将被阻止访问 EWS。

步骤 5：升级问题

如果你验证了本文中提到的先决条件和配置没有问题，请向 Microsoft 支持提交服务请求，并提供以下信息：

• 受影响用户的 UserPrincipalName。
• 重现问题时的 UTC 时间。
• Teams 客户端调试日志。 有关如何收集这些日志的详细信息，请参阅在对 Microsoft Teams 进行故障排除时使用日志文件。