适合于 Teams 和 Skype for Business 的云整合

重要

由世纪互联在中国运营的Skype for Business将于2023年10月1日停用。 如果尚未升级 Skype for Business Online 用户,系统会自动安排他们进行辅助升级。 如果想要自行将组织升级到 Teams,强烈建议你立即开始规划升级路径。 请记住,成功升级与技术和用户就绪情况一致,因此在导航到 Teams 旅程时,请务必利用我们的 升级指南

Skype for Business Online(不包括世纪互联在中国运营的服务)已于 2021 年 7 月 31 日停用。

许多大型企业有多个本地 AD 林。 在某些情况下,客户具有多个 Exchange 和/或Skype for Business Server (或 Lync Server) 部署。 由于业务合并或收购,只有一个本地林的组织可能处于类似的情况。 当这些客户迁移到云时,他们希望将给定本地工作负载的多个实例合并到单个联机 Microsoft 365 组织中。 本文适用于具有多个本地部署Skype for Business (或 Lync) 的组织,这些组织希望将其组织完全迁移到 Microsoft Teams, (所有用户都是仅限 Teams) 。

从历史上看,指导客户先合并本地部署,然后再迁移到云。 虽然本指南仍是一个选项,但本文介绍一种解决方案,它使具有多个Skype for Business部署的组织能够一次将一个部署迁移到单个 Microsoft 365 组织,而无需执行本地合并。 Microsoft Teams 不支持单个 Microsoft 365 组织在混合模式下使用多个Skype for Business或 Lync Server 林。

重要

在使用本指南进行配置之前,请务必查看并了解 限制,因为它们可能会影响组织。

云整合概述

如果满足以下关键要求,可以将多个Skype for Business部署中的所有本地用户合并到单个联机 Microsoft 365 组织中:

  • 最多必须有一个 Microsoft 365 组织参与。 不支持在具有多个组织的方案中进行合并。

  • 在任何给定时间,只有一个本地Skype for Business林可以处于混合模式, (共享 SIP 地址空间) 。 所有其他本地Skype for Business林必须保持本地 (,并且大概) 相互联合。 如果需要,如果禁用联机 SIP 域,这些本地组织可以同步到Microsoft Entra ID。

在多个林中部署Skype for Business的客户必须使用共享 SIP 地址空间功能将单个混合Skype for Business林的所有用户单独迁移到 Microsoft 365 组织。 然后,必须禁用与该本地部署的混合,然后才能继续迁移下一个本地Skype for Business部署。 在迁移到云之前,本地用户与未在同一用户的本地目录中表示的任何用户保持联合状态。

云整合的规范示例

假设一个组织有两个单独的联合本地部署(Skype for Business)想要在 Microsoft Teams 中在线整合它们。

原始状态详细信息 所需状态详细信息
  • 单独的 AD 林中的两个独立的Skype for Business本地部署
  • 最多一个林与 Teams 混合
  • 组织相互联合
  • 用户不会跨这些林同步
  • 组织可能有一个 Microsoft 365 组织,并且可能正在将其目录同步到Microsoft Entra ID
  • 一个 Microsoft 365 组织
  • 不再使用本地部署,因此没有剩余的混合部署
  • 本地所有用户都已移动到“仅限 Teams”模式
  • 任何地方都没有Skype for Business Server的本地占用空间
  • 用户仍具有本地身份验证

合并两个单独的联合本地部署。

下面是从原始状态到所需结束状态的基本步骤。 某些组织可能会发现,其起点位于这些步骤的中间位置。 请参阅本文后面的 其他起点。 最后,在某些情况下,可以根据需要调整顺序。 稍后将介绍关键约束和限制

  1. 获取 Microsoft 365 组织(如果尚不存在)。
  2. 确保两个本地部署中的所有相关 SIP 域都已验证 Microsoft 365 域。
  3. 选择一个与 Microsoft 365 混合的Skype for Business部署。 在此示例中,我们将使用 OriginalCompany。Com。
  4. 为将首先成为混合 (OriginalCompany 的林启用 Microsoft Entra Connectcom) 。
  5. TeamsUpgradePolicy 的租户范围策略设置为 SfBWithTeamsCollab 或其他Skype for Business模式之一, (SfBOnly 或 SfBWithTeamsCollabAndMeetings) 。 此步骤对于确保从仅迁移到 Teams 的用户路由到留在本地的用户的呼叫和聊天至关重要。
  6. 此时,建议 (但直到步骤 11) 为另一个林启用 Microsoft Entra Connect (AcquiredCompany 之前才需要它。com) 。 假设在两个林中都启用了Microsoft Entra Connect,则组织看起来类似于图 A,这可能是某些组织常见的起点。
  7. 对于由其他本地部署托管的任何 SIP 域, (在这种情况下,请使用 AcquiredCompany。com) , 在 Microsoft 365 组织中 使用 Disable-CsOnlineSipDomain Teams PowerShell 模块禁用这些联机 SIP 域。
  8. 为 OriginalCompany 配置Skype for Business混合com (仍启用了联机 SIP 域) 的部署。
  9. 在混合部署中, (OriginalCompany。com) ,开始将用户从本地Skype for Business移动到云, (是否) ,以便该用户仅限 Teams。 现在,组织如图 B 所示。图 A 的主要更改是:
    • 来自两个本地目录的用户现在都位于 MICROSOFT ENTRA ID 中。
    • AcquiredCompany。com 是禁用的联机 SIP 域。
    • 某些用户已联机移动到仅限 Teams。 (请参阅紫色用户 A.)
  10. 将所有用户移动到云后,请为 OriginalCompany 禁用Skype for Business本地部署的混合Microsoft 365 中的 com:
    • 在 Microsoft 365 组织中禁用拆分域。
    • 禁用在 OriginalCompany 中与 Microsoft 365 通信的功能。com 本地。
    • 更新 OriginalCompany 的 DNS 记录。com 指向 Microsoft 365。
  11. 如果尚未执行此操作,请为下一个林启用Microsoft Entra Connect,该林将 (AcquiredCompany 进行混合。com) 。 此时,组织类似于 图 C。对于某些组织来说,此配置可能是另一个常见起点。
  12. 在 Teams PowerShell 中,为将进行混合的 下一个本地部署启用 SIP 域 ,即 AcquiredCompany。Com。 这是使用 Enable-CsOnlineSipDomain完成的,这是自 2018 年 12 月起提供的新功能。
  13. 如果使用封闭式联合身份验证,则必须 在同一 Microsoft 365 中添加任何 SIP 域 (不包括纯联机租户的 *.microsoftonline.com) 作为允许的域。 更改生效可能需要一段时间,并且尽早执行此操作没有危害,因此我们建议在转到步骤 14 之前做好此操作。
  14. 更新本地环境以接受来自联机租户的任何 SIP 域,使其匹配。
    • 将所有边缘证书中的 SAN 更新 为与之前相同的值,加上除 *.microsoftonline.com) 之外的任何现有联机 SIP (域的值(在本例中为 Sip.OriginalCompany)。Com。
    • 确保 OriginalCompany。com 是本地部署 AcquiredCompany 中 允许的域 。 添加允许的域。
  15. 在本地 AcquiredCompany 之间启用Skype for Business混合com 和云。
  16. 根据需要,将 用户从本地迁移到云, 成为 TeamsOnly 用户。 在此状态下,组织如图 D 所示。
  17. 迁移所有用户后, 请禁用与本地环境的混合使组织成为纯云

下图显示了在此过程中各个关键点的配置。

图 A
  • 两个组织都通过 Microsoft Entra Connect 同步,因此Microsoft Entra ID 现在包含来自两个本地部署的所有用户。
  • 所有用户都驻留在本地。
  • 尚未配置Skype for Business 混合。
  • 如果任一部署中的用户使用 Teams,他们将无法相互联合 (或任何组织) ,也无法与任何Skype for Business用户进行互操作性。 在此阶段,Microsoft 建议仅使用 Teams for Channels。

    图为示意图。
图 B
  • AcquiredCompany。com 是 禁用的 联机 SIP 域。 所有用户都位于本地。 如果他们使用 Teams,则他们没有联合身份验证或互操作性。 在此阶段,Microsoft 建议仅使用 Teams for Channels。

  • 已为其中一个本地组织启用了Skype for Business 混合。

  • 混合组织中的某些用户已移动到云,并且仅 teams (用户 A,如紫色底纹) 所示。 这些用户 Teams 仅用户与任何其他Skype for Business用户具有完全的互操作性和联合支持。

    图 B 示意图。

图 C
  • OriginalCompany 中的所有用户。com 现在是云中的“仅限 Teams”模式。

  • 使用 OriginalCompany Skype for Business混合配置。com 部署已被禁用。 本地部署已消失。

  • If AcquiredCompany。com 以前未同步到Microsoft Entra ID,若要从此处继续,现在需要同步它。 但它尚不是混合 (共享 SIP 地址空间) 。 在组织准备好迁移到混合之前,纯本地组织 (AcquiredCompany.com) 的联机 SIP 域应保持禁用状态,以便联机 Teams 用户可以与本地用户通信。

    图 C 关系图。

图 D
  • AcquiredCompany。com 现已作为联机 SIP 域启用。

  • 本地更新为接受 OriginalCompany。Com。 () 更新允许的域和边缘证书。

  • 在 AcquiredCompany 之间启用共享 SIP 地址空间。com 和 Microsoft 365 组织。

  • 混合组织中的某些用户可能已移动到云,例如以下用户 D (紫色底纹) 指示。

    图 D 示意图。

其他起点

上述规范示例中的步骤假定组织从两个没有 Microsoft 365 状态的联合本地部署开始。 但是,某些组织可能具有现有的 Microsoft 365 占用空间,并且上述序列中可能存在不同的入口点。 有四种典型配置:

  • 多个没有 Microsoft 365 组织的联合本地组织。 在这种情况下,请从步骤 1 开始。
  • 已将多个Skype for Business林同步到单个Microsoft Entra租户的多个联合本地组织。 此类组织类似于图 A 中的假设组织,该组织已完成步骤 1-6,应从步骤 7 开始。
  • 与一个或多个其他纯本地组织联合的混合组织,这些组织均未同步到Microsoft Entra ID。 此类组织类似于 图 E 中的假设组织,如下所示。
    • 此组织类似于图 B,后者已完成步骤 1-9,但以下情况除外: - 其非混合Skype for Business部署尚未同步到Microsoft Entra ID。 - 联机 SIP 域尚未禁用。
    • 这些组织应: - 完成现有混合组织的迁移,并在步骤 10 中输入上述顺序。 或者, - 如果要在完成混合组织的迁移之前将任何其他Skype for Business林同步到Microsoft Entra,则必须执行步骤 7 以禁用将同步到的任何其他本地Skype for Business部署中的所有联机 SIP 域Microsoft Entra ID。 然后,必须启用 Microsoft Entra Connect,然后才能继续执行步骤 10 (停用原始混合部署) 。
图 E

图 E 示意图。

  • 与单独的本地Skype for Business组织联合的纯 Teams 仅限 Teams 组织。 一旦此组织禁用本地组织的联机 SIP 域并为本地Skype for Business组织启用Microsoft Entra Connect,它类似于图 C 中所示已完成步骤 1-11 的假设组织。

限制

  • 最多必须有一个 Microsoft 365 组织参与。 不支持在具有多个组织的方案中进行合并。
  • 一次只能有一个本地Skype for Business林处于混合模式, (共享 SIP 地址空间) 。 所有其他本地Skype for Business林必须仅保留在本地,并且应彼此和 Microsoft 365 组织联合。
  • 在迁移到云之前,此部署中的用户会有非对称体验,因为并非所有联机用户都在本地表示。
    • 体验总结如下:
      • 任何联机用户都将与混合环境中的本地用户交互,就像该用户是混合用户一样。
      • 混合部署中的本地用户将与本地目录中表示的联机用户交互,就像他们是混合用户一样。
      • 混合部署中的本地用户将与本地 AD 中未表示为联合的联机用户进行交互。
      • 在上面的 图 D 中,用户 E 位于 AcquiredCompany 中的本地。Com。 用户 E 将使用标准混合体验与用户 D (托管联机) 交互,但用户 E 将具有与用户 A、B 和 C 的联合体验,因为它们不在本地目录中表示。 但是,用户 A、B 和 C 将与用户 E 交互,就像用户处于混合中一样。
      • 混合交互与联合身份验证的影响:
        • 除非将用户标记为联系人,否则不会为联合用户自动订阅状态。
        • 呼叫转接在联合域之间不起作用。
        • 呼叫转移方案更加有限。
        • 可能会对联合流量应用限制。
  • 鉴于此体验,本地用户与不在本地目录中的云用户之间对跨界方案中的功能调用支持仅限于对等。
    • 不支持这些用户之间的呼叫转接、转接、呼叫队列等。
    • 这些不支持的调用方案仍将显示为已启用,但在许多情况下,它们会以不可预知的方式失败。
    • 在上面的 图 D 中,用户 E 位于本地,用户 A、B 或 C 的通话仅支持作为对等。 (使用用户 D 的调用没有支持限制。) 但是,在本地用户 E 移动到云后,此限制不再适用。
  • 如果环境中有多个 Skype for Business Server 2019 部署,则只能将其中一个部署配置为使用组织自动助理,因为该功能需要Skype for Business Server混合配置。
  • 可以调整前面一些步骤的顺序。 关键要求是,如果满足以下所有条件:
    • 多个本地Skype for Business林同步到Microsoft Entra ID 中的单个 Microsoft 365 租户。
    • 使用一个本地林启用拆分域。
    • 混合组织中至少有一个用户已迁移到云。 然后,必须从任何其他本地Skype for Business林禁用所有其他联机 SIP 域。 否则,混合组织中的联机用户与其他组织中的本地用户之间的联合将向一个方向中断。

影响

  • 由于支持上述高级调用功能存在限制, 因此组织应将这些非对称状态视为迁移的一部分,而不是将其视为稳定状态
  • 具有多个本地Skype for Business部署的组织通常应从可完全迁移到云的部署开始,以便可以继续整合。 据了解,在某些情况下,某些用户组仍无法迁移到 Teams。 在涉及多个Skype for Business林的方案中,如果可能,请开始使用另一个没有这些限制的林进行迁移。
  • 从本地迁移到云时,具有委派关系和/或通常参与呼叫转接方案的用户应作为一个单元一起移动。

迁移到 TeamsOnly 模式的注意事项

将用户从本地移动到混合环境中的云时,这些用户将成为仅限 Teams 的用户。

  • 将 TeamsOnly 模式分配给用户时,来自任何其他用户的所有聊天和呼叫都将进入该用户的 Teams 客户端。
  • 如果本地Skype for Business的用户主要使用Skype for Business客户端而不是 Teams,请考虑设置 TeamsUpgradePolicy,以便到这些本地用户的路由始终位于 Skype for Business 而不是 Teams 中。 为了确保在 TeamsOnly 用户和仍在本地使用Skype for Business的用户之间正确路由聊天和呼叫,本地用户必须具有有效值 TeamsUpgradePolicy,其Skype for Business模式之一,而不是岛 (这是默认) 。
    • 必须先将租户的 TeamsUpgradePolicy 全局实例设置为以下值之一: - SfBWithTeamsCollab (建议) - SfBWithTeamsCollabAndMeetings - SfBOnly
    • 可以使用以下命令授予租户范围策略:
      Grant-CsTeamsUpgradePolicy -PolicyName SfBWithTeamsCollab -Global
    • 注意:必须在租户级别执行此步骤,因为无法将策略分配给联机目录中没有 SIP 地址的单个用户。 虽然已为纯本地部署禁用联机 SIP 域 () ,但根据设计,这些域中的用户不会在联机目录中拥有 SIP 地址。 因此,向这些本地用户应用策略的唯一方法是在租户级别分配策略。 在混合部署中,用户在联机目录中将有一个 SIP 地址,因此,如果需要他们具有与租户全局策略不同的值,可以显式为其分配策略。

另请参阅

更新 Microsoft Edge 证书

更新 Microsoft Entra Connect 以包含多个林

禁用混合以完成到云的迁移