解决 Teams 与 Exchange Server 之间的交互问题
现象
遇到以下一个或多个问题。
问题 1:代理人无法代表委派人安排 Teams 会议
在 Exchange Server 上托管邮箱的委派程序会添加一个委托来管理其Microsoft Outlook 日历。 但是,使用适用于 Outlook 的 Teams 加载项的委托无法代表委派人安排 Teams 会议,Outlook 将返回以下错误消息:
看起来你没有权限为此帐户安排会议。 请与所有者联系以获得权限,然后重试。
问题 2:尝试使用 Teams 日历应用时遇到问题
出现以下任一问题:
- 日历图标没有显示在 Teams 客户端中。
- 使用 Teams 桌面或 Web 客户端时,Teams 日历应用会显示“抱歉,我们无法获取会议详细信息”错误消息。
Teams 日历应用需要通过 Exchange Web 服务(EWS)访问 Exchange 邮箱。 Exchange 邮箱可以在 Exchange 混合部署的范围内联机或本地。
问题 3:当正在参加 Outlook 日历会议时,Teams 中的状态停滞在外出或未显示“会议中”
出现以下任一问题:
邮箱托管在本地 Exchange 服务器上,并且已在 Outlook 客户端中关闭了自动答复功能。 但是,Teams 状态向同一组织中的所有 Teams 客户端显示“外出”。 此状态可能持续几天。
注意:对于邮箱托管在本地的用户,预计状态延迟最长为一小时。
你正在参加 Outlook 日历会议,但 Teams 状态不会更新为“在会议中”。
Teams 和 Exchange Server 集成先决条件
若要将 Teams 服务与 Exchange Server 的安装集成,请确保本地 Exchange Server 环境满足以下要求:
验证部署中 Microsoft Exchange Server 和 Microsoft Teams 的版本和环境兼容性。
Microsoft Teams 必须知道邮箱是托管在 Exchange Online、本地还是混合 Exchange 服务器部署中。 Teams 服务通过自动发现 V2 调用来调用 Exchange Online 服务,该呼叫重定向到托管混合配置中邮箱的本地服务器。
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 服务器内部部署执行文中说明的所有步骤。
应将面向 Internet 的防火墙或反向代理服务器配置为允许 Microsoft Teams 访问运行 Exchange Server 的服务器,方法是将 Skype for Business Online 的 URL 和 IP 地址范围和Microsoft Teams 添加到允许列表中。 有关详细信息,请参阅 Microsoft 365 个 URL 和 IP 地址范围 - Microsoft Teams。
需要 Exchange 自动发现 V2 来允许 Teams 服务对位于 Exchange Server 中的用户邮箱执行未经身份验证的发现。 Exchange Server 2013 累积更新 19 或更高版本完全支持自动发现 V2。 这足以使 Teams 委派正常工作。 但是,Teams 日历应用需要安装 Exchange Server 2016 累积更新 3 或更高版本。 因此,对于完整功能支持,需要 Exchange Server 2016 累积更新 3 或更高版本。
常见故障排除步骤
注意
这些故障排除步骤适用于上面列出的所有问题。
运行 Teams Exchange 集成连接测试
管理员和非管理员可以在Microsoft远程连接分析器工具中运行 Teams Exchange 集成 连接测试。 此工具用于排查影响 Teams 的连接问题。 连接测试验证 Teams 与 Exchange 交互的能力。 对于 Exchange 混合环境,请使用 Microsoft 365 邮箱和一次本地邮箱运行此测试两次。
注意
Microsoft远程连接分析器工具不适用于 GCC 和 GCC High Microsoft 365 政府版环境。
若要运行连接测试,请执行以下步骤:
- 打开 Web 浏览器并导航到 Teams Exchange 集成 连接测试。
- 使用受影响用户帐户的凭据登录。
- 输入显示的验证码,然后选择“ 验证”。
- 选中复选框以接受协议条款,然后选择“ 执行测试”。
测试完成后,屏幕会显示有关已执行的检查的详细信息,以及测试是成功、失败还是成功,但显示一些警告。 选择提供的链接,了解有关警告和故障的详细信息以及如何解决它们。
附加步骤
运行 Teams Exchange 集成连接测试后,请按照以下步骤操作。
步骤 1:验证自动发现服务是否正常工作
Teams 服务使用 Exchange 自动发现服务来查找由运行 Exchange Server 的服务器发布的 EWS URL。 若要验证自动发现过程是否正常工作,请在 Microsoft 远程连接分析器工具中运行 Outlook 连接 测试。 远程连接分析器工具使用一组特定的 IP 地址来查找 EWS URL。 有关 Microsoft 365 的这些 IP 地址的列表,请参阅 Microsoft 365 URL 和 IP 地址范围中 ID 46 的信息。
注意
Microsoft远程连接分析器工具不适用于 GCC 和 GCC High Microsoft 365 政府版环境。
若要运行连接测试,请执行以下步骤:
打开 Web 浏览器并导航到 Outlook 连接 测试。
在 “电子邮件地址 ”字段中,输入受影响邮箱的电子邮件地址。
注意:对于 Teams 委派问题,请输入委派者的邮箱。 对于 Teams 日历应用和 Teams 状态问题,请输入受影响的用户的邮箱。
在“域\用户名”(或 UPN)字段中,输入有权以域\用户()格式或 UPN 格式
contoso.com\user
user@contoso.com
运行此测试的帐户名。在 “密码 ”字段中,输入步骤 3 中指定的帐户的密码。
在“自动发现”选择下,选择“使用自动发现”检测服务器设置。
输入显示的验证码,然后选择“ 验证”。
选中复选框以接受协议条款,然后选择“ 执行测试”。
测试完成后,屏幕会显示有关已执行的检查的详细信息,以及测试是成功、失败还是成功,但显示一些警告。 选择提供的链接,了解有关警告和故障的详细信息以及如何解决它们。
第 2 步:验证自动发现服务能否将自动发现请求路由到本地
在 Windows PowerShell 中,运行以下命令:
Invoke-RestMethod -Uri "https://outlook.office365.com/autodiscover/autodiscover.json?Email=<Email address of the affected mailbox>&Protocol=EWS" -UserAgent Teams
注意
对于 Teams 委派问题,请测试委派者的邮箱。 对于 Teams 日历应用和 Teams 状态问题,请测试受影响的用户的邮箱。
对于托管在本地的邮箱,EWS URL 应指向本地外部 EWS。 输出应与下面的示例类似:
协议 URL
-------- ---
EWS <
https://mail.contoso.com/EWS/Exchange.asmx
>
如果此测试失败,或者 EWS URL 不正确,请查看 Teams 和 Exchange Server 部分集成的先决条件。 此问题可能是由 Exchange 混合配置问题或阻止外部请求的防火墙或反向代理引起的。
第 3 步:验证 Exchange OAuth 身份验证协议是否已启用并正常工作
若要验证 Exchange OAuth 身份验证是否已启用且正常运行,请运行 Test-OAuthCOnnectivity
Exchange 和 Exchange Online 组织之间的配置 OAuth 身份验证中所述的命令。
此外,请在Microsoft远程连接分析器工具中运行 忙/闲 连接测试。 此测试验证Microsoft 365 邮箱是否可以访问本地邮箱的忙/闲信息,反之亦然(每个测试运行一个方向)。
注意
- Microsoft远程连接分析器工具不适用于 GCC 和 GCC High Microsoft 365 政府版环境。
- 必须通过将源邮箱电子邮件地址与目标邮箱电子邮件地址交换两次来运行此测试,因为每次运行都是单向的。 无需使用受影响的帐户运行此测试。 可以使用任意一对本地邮箱和 Microsoft 365 邮箱来运行测试。
若要运行连接测试,请执行以下步骤:
- 打开 Web 浏览器并导航到 忙/闲 连接测试。
- 在 “源邮箱电子邮件地址 ”字段中,输入源邮箱的电子邮件地址。
- 在“身份验证类型”下拉列表框中,选择“新式身份验证”(OAuth)。
- 使用源邮箱的凭据登录。
- 在 “目标邮箱电子邮件地址 ”字段中,输入目标邮箱的电子邮件地址。
- 在“ 服务选择 ”字段中,选择相应的服务。
- 输入显示的验证码,然后选择“ 验证”。
- 选中复选框以接受协议条款,然后选择“ 执行测试”。
测试完成后,屏幕会显示有关已执行的检查的详细信息,以及测试是成功、失败还是成功,但显示一些警告。 选择提供的链接,了解有关警告和故障的详细信息以及如何解决它们。
若要详细了解如何在 Microsoft 365 中本地和 Exchange Online 的混合部署中排查忙/闲问题,请参阅 本文。
解决 Teams 委派问题
注意
这些故障排除步骤仅适用于 问题 1。
运行 Teams 会议委派连接测试
管理员和非管理员可以在 Microsoft 远程连接分析器工具中运行 Teams 会议委派 连接测试。 此工具用于排查影响 Teams 的连接问题。 连接测试验证你的帐户是否满足代表委托人安排 Teams 会议的要求。
注意
Microsoft远程连接分析器工具不适用于 GCC 和 GCC High Microsoft 365 政府版环境。
若要运行连接测试,请执行以下步骤:
- 打开 Web 浏览器并导航到 Teams 会议委派 连接测试。
- 使用受影响用户帐户的凭据登录。
- 输入委托人的电子邮件地址。
- 输入显示的验证码,然后选择“ 验证”。
- 选中复选框以接受协议条款,然后选择“ 执行测试”。
测试完成后,屏幕会显示有关已执行的检查的详细信息,以及测试是成功、失败还是成功,但显示一些警告。 选择提供的链接,了解有关警告和故障的详细信息以及如何解决它们。
如果测试失败,请执行以下步骤。
步骤 1:验证委托是否向委派者日历授予了“作者”权限
如果委派者的邮箱托管在本地 Exchange 服务器上,请执行以下步骤:
使用委派器的凭据打开经典 Outlook。
选择“文件>帐户设置>委托访问权限”。
在 “委托 ”对话框中,选择该委托,然后选择“ 权限”。 如果未列出委托,请选择“ 添加” 以添加委托。
在“委派权限”对话框中,确保委托具有“日历”文件夹的“作者”(可读取和创建项目)或编辑器(可读取、创建和修改项目)权限。
注意:代表委派创建会议所需的最低权限是 作者(可以读取和创建项目) 权限。 默认情况下,添加委托时,将授予“编辑者”(可以读取、创建和修改项目)对日历文件夹的权限。
选择“确定”。
执行这些步骤后,文件夹和代表权限将存储在委派者的邮箱中。 此外,该委托将添加到委托人邮箱中隐藏项中的委托列表中。
如果委派者的邮箱托管在 Exchange Online 中,则可以按照上面列出的相同步骤操作,就像委派者的邮箱托管在本地 Exchange 服务器上时一样。 或者, 连接到 Exchange Online PowerShell,并使用管理员权限运行 Set-Mailboxfolderpermission PowerShell 命令:
Set-Mailboxfolderpermission -identity <delegator's UserPrincipalName>\Calendar -User <delegate's UserPrincipalName> -AccessRights Author –SharingpermissionFlags Delegate
步骤 2:验证未阻止 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。
步骤 3:验证 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。
步骤 4:升级问题
如果验证本文中提到的先决条件或配置没有问题,请通过以下信息提交服务请求以Microsoft 支持部门:
- 委托人和委托的 UserPrincipalName。
- Teams 会议外接程序记录在
%appdata%\\microsoft\\teams\\meeting-addin
文件夹下。 - 重现问题时的 UTC 时间。
- 从代理的计算机上收集的 Teams 客户端调试日志。 有关如何收集这些日志的详细信息,请参阅在对 Microsoft Teams 进行故障排除时使用日志文件。
解决 Teams 日历应用问题
注意
这些故障排除步骤仅适用于 问题 2。
第 1 步:验证 Teams 日历应用是否已启用
打开 Microsoft Teams 管理中心,选择“用户管理用户>”,选择受影响的用户,然后选择“查看策略”。
选择为该用户分配的“应用设置策略”。 在上面的示例中,分配全局(Org-Wide 默认)策略。 确认显示日历应用 (ID
ef56c0de-36fc-4ef8-b417-3d82ba9d073c
)。如果日历应用丢失,请还原它。 有关更多信息,请参阅在 Microsoft Teams 中管理应用设置策略。
步骤 2:验证 Teams 升级共存模式是否允许 Teams 会议
打开 Microsoft Teams 管理中心。
选择“用户管理用户>”,然后选择受影响的用户。
验证共存模式设置是否设置为仅 Skype for Business 或具有 Teams 协作的 Skype for Business 以外的值。
如果用户的共存模式设置为 “使用组织范围的设置”,则使用默认租户共存模式。 在这种情况下,请执行以下步骤:
转到“组织范围的设置”,然后选择“Teams 升级”。
验证默认共存模式设置是否设置为仅 Skype for Business 或具有 Teams 协作的 Skype for Business 以外的值。
第 3 步:验证 Teams 未被阻止访问整个组织的 EWS
运行此 Exchange PowerShell 命令,检查是否为整个组织设置了EnforceAllowList
参数EwsApplicationAccessPolicy
:
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:验证 Teams 日历应用连接测试是否成功
管理员和非管理员可以在 Microsoft 远程连接分析器工具中运行 Teams 日历应用 连接测试。 此工具用于排查影响 Teams 的连接问题。 连接测试验证 Teams 后端服务是否可以连接到 Exchange 邮箱。
注意
Microsoft远程连接分析器工具不适用于 GCC 和 GCC High Microsoft 365 政府版环境。
若要运行连接测试,请执行以下步骤:
- 打开 Web 浏览器并导航到 Teams 日历应用 连接测试。
- 使用受影响用户帐户的凭据登录。
- 输入显示的验证码,然后选择“ 验证”。
- 选中复选框以接受协议条款,然后选择“ 执行测试”。
测试完成后,屏幕会显示有关已执行的检查的详细信息,以及测试是成功、失败还是成功,但显示一些警告。 选择提供的链接,了解有关警告和故障的详细信息以及如何解决它们。
步骤 6:升级问题
如果验证本文中提到的先决条件和配置没有问题,请提交服务请求以Microsoft 支持部门并提供以下信息:
- 受影响用户的 UserPrincipalName。
- 重现问题时的 UTC 时间。
- Teams 客户端调试日志。 有关如何收集这些日志的详细信息,请参阅在对 Microsoft Teams 进行故障排除时使用日志文件。
解决 Teams 状态问题
注意
这些故障排除步骤仅适用于 问题 3。
第 1 步:验证本地 Exchange REST API 的 URL 是否已在公共网络上发布
使用用户的邮箱查找本地 Exchange EWS URL 并更改 URL 格式,验证自动发现服务是否可以将自动发现请求路由到 本地。 例如,将 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 状态是否成功
管理员和非管理员可以在 Microsoft 远程连接分析器工具中基于日历事件连接测试运行 Teams 状态。 远程连接分析器工具使用一组特定的 IP 地址来查找 EWS URL。 有关 Microsoft 365 的这些 IP 地址的列表,请参阅 Microsoft 365 URL 和 IP 地址范围中 ID 46 的信息。 此连接测试根据 Microsoft用户在 Outlook 中的日历事件来验证更新 Teams 中的状态的要求。
注意
Microsoft远程连接分析器工具不适用于 GCC 和 GCC High Microsoft 365 政府版环境。
若要运行连接测试,请执行以下步骤:
- 打开 Web 浏览器并导航到 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 进行故障排除时使用日志文件。