EnglishFrançaisDeutschEspañolItaliano日本語한국어NederlandsPortuguês (Brasil)中文 (简体)中文 (繁體, 台灣)
Skip to main content

2025 年 8 月 27 日

迁移第一代 Horizon Cloud Pod 的必备条件

本页介绍了在开始迁移第一个 Pod 之前应根据需要评估、准备和更新的内容。

简介

在登录到新的 Horizon Cloud 环境并看到“迁移”UI 之前，可以随时完成其中的大多数评估和准备步骤。

其中的一些评估和准备步骤涉及部署了第一代 Pod 的 Microsoft Azure 订阅环境和网络。对于这些步骤，您可能需要 IT 团队帮助处理该环境。

**切记：**截至撰写本文时，正在逐步向第一代租户提供迁移第一代 Pod 的资格。如果符合资格条件，您会收到直接从 Horizon Migration Communications 发来的电子邮件。

术语

Horizon Cloud Service 具有新的概念和术语。在 Horizon Cloud Service 中，部署称为 Horizon Edge（而不是称为 Pod）。

自助迁移旨在将 Microsoft Azure Horizon Edge 部署到用于迁移第一代 Pod 的同一 Microsoft Azure 订阅中，并使用相同的订阅信息、VNet 和子网。

在迁移每个 Pod 时，迁移过程默认重用该 Pod 中的以下项目：

  • Microsoft Azure 订阅 ID、目录 ID、服务主体应用程序 ID 和密钥。

  • VNet

  • 管理子网、租户子网、DMZ 子网

  • 在第一代租户中注册的 Active Directory 域信息以及域绑定和域加入服务帐户（域绑定和域加入用户、辅助域绑定和域加入用户）。

    在计划迁移您的第一个 Pod 时，系统会复制第一代租户注册的所有 Active Directory 域信息和服务帐户信息，并在 Horizon Cloud 环境中注册相同的信息。

第一代 Pod 中的某些项目不会被重用。对于其中的一些项目，您必须设置新的额外资源。

因此，您必须评估以下方面，并根据需要做好准备以满足 Horizon Cloud 要求。

**注意：**对于具有某些特殊特性的 Pod，迁移过程可能要求使用与第一代 Pod 不同的新 VNet 和管理子网。本页的相应章节中介绍了这种特殊情况。

必备条件表

此表后面的几个章节提供了其中每个必备条件的详细信息。此表仅作概览，方便查阅。

☐为 Horizon Cloud Unified Access Gateway 获取新的 FQDN 和证书。
☐评估第一代 Pod 和代理版本，并根据需要进行更新。
☐确保所有需要迁移的映像都有效。
☐确定 Pod 的 VNet 或连接的网络是否包含受 AKS 限制的 IP 地址。
☐确定您的部署类型并满足其要求。
☐在第一代中，如果您的 Microsoft Azure 订阅的名称包含非英文字符，在迁移到 Horizon Cloud 之前重命名该订阅以仅使用英文字符。
☐确定 Pod 的 Microsoft Azure 订阅是否具有有关资源组标记的策略。如果是，请制定一个关于如何处理迁移要求的计划。
☐网络 - 评估网络流量的现有设置并根据需要进行更新。
☐确认 Pod 的关联应用程序密钥仍然有效。
☐VNet - 评估您用于对桌面进行内部访问的当前路由。
☐评估 Microsoft Azure vCPU 系列配额并根据需要增加配额。
☐评估 Pod 订阅和资源组上的 Azure 策略，并确保这些策略允许置备 Horizon Edge Gateway 的存储帐户和文件共享。
☐当 Pod 具有 App Volumes 应用程序时，请遵循确保这些策略允许切换存储帐户上的网络访问中的指导。
☐在您具有 Unified Access Gateway 负载均衡器的公用 IP 时，请按照在您具有该负载均衡器的公用 IP 时中的指导进行操作。
☐在您具有 Unified Access Gateway 负载均衡器的专用 IP 时，请按照在您具有该负载均衡器的专用 IP 时中的指导进行操作。
☐评估是否能够登录到新的 Horizon Cloud 环境，并显示 Horizon Cloud Horizon Universal Console。
☐确定您的身份提供程序，并将 AD 用户和组同步到该身份提供程序。
☐评估您对 Active Directory 内置用户或内置组的使用情况，并根据需要进行更新。
☐评估您对 App Volumes 应用程序分配的使用情况。
☐特殊情况 - 如果您的第一代 Pod 的应用程序注册使用的是自定义角色，请按照如果您的第一代 Pod 的应用程序注册使用的是自定义角色中的指导更新 Horizon Cloud 部署所需的权限。

为 Horizon Cloud Unified Access Gateway 获取新的 FQDN 和证书

**注意：**Horizon Cloud Unified Access Gateway 部署的 FQDN 必须不同于已用于要迁移的第一代部署的 FQDN。为了在极少数情况下出现迁移后问题时支持回滚到第一代部署，第一代部署的网关 FQDN 及其 SSL 证书必须保持为第一代部署配置的状态。只有在您完成迁移后，才能更新 Horizon Cloud 网关部署的 FQDN 和 SSL 证书（如果您此时希望更新）。

计划向导 UI 要求您在向导中指定该 FQDN，并提供基于该 FQDN 的 SSL 证书。

对于 Horizon Cloud 环境，SSL 证书可以采用 PEM 或 PFX 格式。

证书中设置的公用名或 FQDN 必须与您打算在计划向导中输入的 FQDN 相匹配。该向导会验证证书中的数据是否与在向导中输入的 FQDN 相匹配。

**注意：**如果您的第一代 Pod 同时具有外部 Unified Access Gateway 配置和内部 Unified Access Gateway 配置，则迁移后 Edge 的 Unified Access Gateway 的访问类型将设置为内部和外部访问，并且外部 FQDN 和内部 FQDN 默认设置为相同的 FQDN（您在计划向导中输入的 FQDN）。如果您想要在迁移后使用不同的 FQDN 进行内部访问，则此时可以编辑 Edge 的 Unified Access Gateway 详细信息，以将其内部 FQDN 更改为要使用的 FQDN，并相应地为内部用户配置网络范围。请注意，上载的证书必须在证书信息中同时包含外部 FQDN 和内部 FQDN（例如，在主体备用名称数据中包含内部 FQDN）。

评估第一代 Pod 和代理版本，并根据需要进行更新

Pod 和代理版本必须满足以下条件，然后才能迁移 Pod：

  • Horizon Cloud Azure Pod 必须运行 Pod 清单 5041.0 或更高版本。如果运行较早的清单，请发起一个服务请求以升级 Pod。
  • Pod 的专用 VDI 桌面必须运行 Horizon Agents Installer 版本 24.2.0 或更高版本。

确保所有要迁移的映像均有效。

为避免在迁移的预构建阶段出现问题，请确保需要迁移的所有第一代映像都处于“已发布”状态，并且其虚拟机和快照在 Microsoft Azure 中保持不变。

确定 Pod 的 VNet 或连接的网络是否包含受 AKS 限制的 IP 地址

**重要信息：**确定结果将指导您选择哪种类型的 Horizon Edge Gateway 部署以用于迁移。在标题为确定 Edge 网关部署类型的下一节中介绍了这些类型。

确定第一代 Pod 的管理子网、VNet 或 VNet 连接到的网络（例如，通过 ExpressRoute 连接的内部部署网络）是否包含此处列出的受 AKS 限制的范围内的 IP 地址：

  • 169.254.0.0/16
  • 172.30.0.0./16
  • 172.31.0.0/16
  • 192.0.2.0/24

如果是，则要迁移该 Pod，您需要接下来评估单个虚拟机部署类型是否可以满足您的需求，或者您的要求是否只有 AKS 部署类型才能满足。

  • 您使用单个虚拟机部署类型迁移该 Pod，或者

  • 如果您的要求指示要使用 AKS 部署类型，则必须在该 Pod 的订阅中设置一个新的 VNet 并在该 VNet 中设置管理子网（最小 CIDR /26），然后将这个新 VNet 与 Pod 的现有 VNet 对等互连。对于 AKS 部署类型，强烈建议使用最小 CIDR /26。

    确保新 VNet 中没有任何子网包含或使用受限制的范围内的 IP 地址。对于新的 VNet 和管理子网，您可以使用提供 HA 的 AKS 部署类型。

请参阅介绍如何确定 Edge 网关部署类型的下一节以获得详细指导。

这些特定范围之所以是受 AKS 限制的范围，是因为 Microsoft 对用于 AKS 类型的 Horizon Edge Gateway 部署的 Azure Kubernetes 服务 (AKS) 集群实施了该规则。

如果这些受限制的 IP 包含在 Pod 的管理子网或 VNet 中，或者包含在连接到 VNet 的内部部署网络中，则使用 AKS 类型的迁移过程无法重用 Pod 的现有 VNet。

确定您的部署类型并满足其要求

在将第一代 Pod 迁移到 Horizon Cloud 环境的过程中，系统将所谓的 Horizon Edge Gateway 部署到 Pod 的 Microsoft Azure 订阅中。

部署具有两种类型 - 单个虚拟机类型或 Azure Kubernetes 服务 (AKS) 类型。

系统允许您指定用于每个 Pod 迁移的类型。

因此，您必须按照下表根据所需的特性确定要使用的类型。

Edge 网关部署重要特性详细信息
单个虚拟机
  • 最多支持 5K (5000) 个会话。
  • 在 Microsoft Azure 订阅中涉及的必备条件比 AKS 类型少
  • 适合无法轻松满足 AKS 要求的 Pod 迁移。
  • 如果部署在将来的某个时间不可用，则最终的行为是：
    • 最终用户将需要在没有单点登录 (Single Sign-On, SSO) 的情况下登录。
    • 在虚拟机不可用期间，不会记录桌面的监控数据。
在迁移第一代 Pod 时，单个虚拟机类型比 AKS 类型更简便。该选项更简便的原因是，单个虚拟机类型在 Pod 的 Azure 订阅中涉及的新要求比 AKS 类型少。因此，它适合无法轻松满足 AKS 类型要求的第一代 Pod 部署。除了简便以外，如果部署的虚拟机变得不可用，单个虚拟机类型的行为与 AKS 类型也不同。在虚拟机不可用时：
  • 最终用户将看到没有 SSO 登录体验的登录流程。例如，他们必须使用 Active Directory 凭据登录，才能看到桌面。
  • 在虚拟机不可用期间，不会记录发送到 Edge 网关虚拟机的桌面监控数据。
AKS
  • 支持超过 5K (5000) 个会话。
  • Azure Kubernetes 服务具有必须满足的 Microsoft 相关要求
  • 适合可以满足 AKS 要求的 Pod 迁移。
  • SSO 登录体验和监控数据收集是通过复制的服务来处理的，这些服务实现了这些功能的高可用性交付
AKS 是 Microsoft Azure 数据中心内适用于企业云原生应用程序的 Microsoft Azure 标准。AKS 类型提供了集群架构的 Edge 网关，该网关提供了支持 SSO 登录体验和监控数据收集的复制服务。
  • 针对以下决策表的两个问题：
    1. 您是否要求具有超过 5K 的会话，或者要求通过具有完全故障切换功能的服务在发生故障时支持 SSO 登录体验和监控数据收集？
    2. Pod 的管理子网、Pod 的 VNet 中是否包含任何受 AKS 限制的 IP 范围，或者该 VNet 已知且连接到内部部署网络的计算机是否正在使用这些 IP 范围？
您的回答使用的方法满足的必备条件
  1. 是
  2. 否
如果对第一个问题回答“是”，则需要使用 AKS 类型。 在您需要超过 5K 会话并需要满足 SSO 登录体验和监控数据收集要求时，需要使用 AKS 类型以提供这些功能。AKS 类型必备条件
  1. 是
  2. 是
如果对第一个问题回答“是”，则需要使用 AKS 类型。 在这种情况下，您需要使用 AKS 类型提供超过 5K 会话并满足 SSO 登录体验和监控数据收集要求，但 Pod 的 VNet 与 AKS 类型的 IP 地址限制相反。 要支持 AKS 类型的要求，您必须：
  1. 在 Pod 的订阅中设置另一个 VNet 并在该 VNet 中设置管理子网，其中不包含受限制的 IP 地址。
  2. 确保新的 VNet 和管理子网满足 AKS Edge 网关的要求。
  3. 将该新 VNet 与 Pod 的现有 VNet 对等互连
然后，在运行迁移向导时，您将选择该新 VNet 和管理子网以及 Azure Kubernetes 服务选项。		AKS 类型必备条件
  1. 否
  2. 否
如果对第一个问题回答“否”，则意味着单个虚拟机类型满足您的需求。 同时，由于 Pod 的 VNet 满足 AKS 类型的 IP 限制，您也可以选择决定使用 AKS 类型进行迁移。除了“迁移第一代 Horizon Cloud Pod 的必备条件”页面及其所有小节中详细介绍的要求以外，单个虚拟机类型没有任何特定的要求。
  1. 否
  2. 是
如果对第一个问题回答“否”，则意味着单个虚拟机类型满足您的需求。您可以选择以下任一选项：
  • 最简单的选项是使用单个虚拟机类型。
  • 更复杂的选项是通过以下方法解决受 AKS 限制的 IP 问题：
    1. 在 Pod 的订阅中设置另一个 VNet 并在该 VNet 中设置管理子网，其中不包含受限制的 IP 地址。
    2. 确保新的 VNet 和管理子网满足 AKS Edge 网关的要求。
    3. 将该新 VNet 与 Pod 的现有 VNet 对等互连
    在完成上述各项后，如果您愿意，也可以选择使用 AKS 类型。
除了“迁移第一代 Horizon Cloud Pod 的必备条件”页面及其所有小节中详细介绍的要求以外，单个虚拟机类型没有任何特定的要求。

确定 Pod 的 Microsoft Azure 订阅是否具有有关资源组标记的策略

截至撰写本文时，Horizon Edge 的部署过程要求 Microsoft Azure 订阅允许创建没有标记的资源组。

在您计划迁移维护时段的日期和时间后，系统会立即为 Horizon Edge Gateway 和 Unified Access Gateway 实例创建资源组。

因此，如果 Pod 的订阅具有阻止创建未标记资源组的 Microsoft Azure 策略，或者如果订阅具有任何类型的资源标记要求，则迁移过程将在该计划步骤后不久失败。

如果订阅具有此类策略，您可以制订计划以在完成迁移计划向导之前禁用该 Azure 策略，并在订阅中部署 Horizon Edge Gateway 和 Unified Access Gateway 实例之前将该策略保持禁用状态，从而管理该要求。当您看到 Horizon Edge Gateway 和 Unified Access Gateway 实例已成功部署时，可以重新启用在创建资源组时需要标记的 Azure 策略，而不会影响迁移活动。

网络 - 评估网络流量的现有设置，并根据需要进行更新

评估当前防火墙设置是否允许连接到 Horizon Cloud Horizon Edge 所需的端点、端口和协议。

Horizon Cloud Service 所需的端点 URL 和端口可能与您的网络团队已为第一代 Pod 允许的端点 URL 和端口不同。

有关所需的端点、端口和协议列表，请参阅*《使用 Horizon Cloud》*指南中的以下页面，并确定要在第一代 Pod 的环境中做出的更改。

有关无法使用 URL 的情况，请参阅知识库文章 6000374 - 服务组件的 IP 地址。

如果为第一代 Pod 配置了代理，迁移的池将继承代理配置。在迁移过程中，专用桌面池必须绕过代理，通过 Internet 直接连接到特定的 URL。如果为桌面 VDI 子网的出站连接配置了防火墙，则必须在迁移过程中允许这些 URL。完成迁移后，您可以从允许列表中移除这些 URL。

要在迁移过程中允许专用虚拟机使用的 URL
美国：
cloud-sg-us-r-westus2.horizon.omnissa.com
cloud-sg-us-r-eastus2.horizon.omnissa.com

欧盟：
cloud-sg-eu-r-northeurope.horizon.omnissa.com
cloud-sg-eu-r-germanywestcentral.horizon.omnissa.com
cloud-sg-eu-r-uksouth.horizon.omnissa.com

日本：
cloud-sg-jp-r-japaneast.horizon.omnissa.com
cloud-sg-jp-r-australiaeast.horizon.omnissa.com
cloud-sg-jp-r-centralindia.horizon.omnissa.com

验证 Pod 的关联应用程序密钥是否仍然有效

登录到 Pod 部署的 Azure 门户，并确认 Pod 使用的应用程序密钥没有过期。

Azure 门户在“应用程序注册”区域中使用客户端密钥这一术语。查找与 Pod 关联的应用程序注册。

VNet - 评估内部桌面访问的路由

根据您为第一代 Pod 和内部桌面访问设置的路由，您可能需要调整该路由，以继续在 Horizon Cloud Horizon Edge 中正常进行内部桌面访问。

评估 Microsoft Azure vCPU 系列配额并根据需要增加配额

根据第一代 Pod 的 Microsoft Azure 订阅中的当前 vCPU 系列配额，您可能需要增加特定 vCPU 系列的配额以支持迁移过程。

迁移过程将部署至少包含一个 Horizon Edge Gateway 和两个 Unified Access Gateway 实例的 Horizon Edge。

Microsoft Azure 中部署的 Horizon Edge 具有单个虚拟机部署类型或 AKS 部署类型的 Horizon Edge Gateway。

您可以确定用于 Pod 迁移的类型，如确定 Edge 网关部署类型中所述。

用途其他 vCPU/配额需求
Unified Access Gateway 实例需要其他配额，用于容纳两 (2) 个 Standard_F8s_v2
Horizon Edge Gateway - 单个虚拟机部署类型（如果您选择该类型）需要其他配额，用于容纳 1 个具有以下虚拟机 SKU 大小的虚拟机：
  • Standard_D4s_v3 - 4 个 vCPU
  • Standard_D4s_v4 - 4 个 vCPU
  • Standard_D4s_v5 - 4 个 vCPU
Horizon Edge Gateway - AKS 部署类型（如果您选择该类型） 需要其他配额，用于容纳 5 个具有以下虚拟机 SKU 大小的虚拟机：
  • Standard_D2s_v3 - 2 个 vCPU
  • Standard_D2ds_v5 - 2 个 vCPU
  • Standard_D2a_v4 - 2 个 vCPU
如果 Pod 订阅的容量可容纳五 (5) 个虚拟机，并且这些虚拟机至少具有上面列出的虚拟机 SKU 大小之一，则满足 4 节点 Edge 网关 (AKS) 的迁移要求，并且还满足将来升级 AKS 的单节点要求。这些虚拟机 SKU 要求的背景是，Edge 网关 (AKS) 部署使用 Azure Kubernetes 服务 (AKS) 集群，这要求通过四个具有下面列出的虚拟机大小之一的虚拟机节点提供容量。然后，还需要一 (1) 个额外的节点，并在升级过程中使用。这意味着，总共需要 5 个具有这些虚拟机 SKU 的节点。
映像 各个映像将复制并迁移到 Horizon Cloud。

因此，您必须为系列中的每个映像提供两部数量的 vCPU。

例如，要迁移具有 2 个 vCPU 内核的 Standard_DS2_v2 映像，在迁移过程中还需要两个 vCPU 内核，因此，Azure 订阅在相应区域中必须至少具有 4 个标准 DSv2 系列 vCPU 内核。

但是，由于映像是以每批 20 个进行分批迁移，因此该额外配额不需要超过每个映像 vCPU 内核数的 20 倍。换句话说，您需要现有配额加上 20 倍的映像 vCPU 额外配额，而不仅仅是 20 倍的映像 vCPU 配额。

确保您的 Azure 策略允许置备存储帐户和文件共享

在计划迁移之前，请与 Pod 的 Azure 订阅所有者确认在订阅级别或 Pod 资源组上的 Microsoft Azure 策略不会阻止、拒绝或限制在第一代 Pod 资源组中置备存储帐户和文件共享。

如果要将 Pod 迁移到现有的 Horizon Edge，请确保现有 Horizon Edge 订阅和资源组上的 Microsoft Azure 策略不会阻止、拒绝或限制置备存储帐户和文件共享。

要成功部署 Horizon Edge Gateway，需要置备 App Volumes 存储帐户和文件共享。

当第一代 Pod 具有 App Volumes 应用程序时，确保您的 Azure 策略允许切换存储帐户上的网络访问

如果第一代 Pod 具有 App Volumes 应用程序，请与 Pod 的 Azure 订阅所有者确认在订阅级别或 Pod 资源组上的 Microsoft Azure 策略不会阻止、拒绝或限制开启公共网络访问的功能。

系统迁移 App Volumes 应用程序时，需要将这些资源从 Pod 的 Azure 存储帐户复制到 Horizon Edge Gateway 的存储帐户。

为了便于进行这种复制，迁移过程需要同时访问这两个存储帐户。在迁移过程中，系统会临时在存储帐户上开启公共网络访问，然后在复制完成后关闭该访问。

如果 Azure 策略阻止迁移过程在开始复制 App Volumes 应用程序之前在存储帐户上开启公共网络访问，则迁移将会失败。在迁移的构建阶段和维护时段内，系统需要能够开启和关闭网络访问。

在您具有 Unified Access Gateway 负载均衡器的公用 IP 时

如果第一代 Pod 将公用 IP 用于其外部 Unified Access Gateway 配置的负载均衡器，则系统支持 Horizon Cloud Horizon Edge 将公用 IP 用于 Horizon Edge 的 Unified Access Gateway 配置。

在这种情况下，该 Pod 的订阅需要一个额外的公用 IP。因此，在计划迁移之前，请确保订阅具有相应容量以提供该额外的公用 IP。

在您具有 Unified Access Gateway 负载均衡器的专用 IP 时

如果第一代外部 Unified Access Gateway 部署的负载均衡器使用专用 IP，请获取要路由到 Horizon Cloud 部署的负载均衡器的公用 IP 地址。

如果要迁移的第一代外部网关配置对其负载均衡器使用专用 IP，并将公用 IP 路由到该专用 IP，则在开始计划迁移时，系统会检测此配置。

如果在外部网关配置的 Azure 负载均衡器前面配置了防火墙或 NAT，以在允许访问外部网关配置的 Unified Access Gateway 设备之前控制基于 Internet 的流量，则在第一代部署中使用此方案。

当系统确定 Ready to migrate 状态时，会在扫描过程中检测第一代配置。

当系统检测到该配置时，“计划迁移”向导 UI 会显示手动公用 IP 字段。在该字段中，您需要输入要用于 Horizon Cloud Unified Access Gateway 部署的公用 IP 地址。

**注意：**此公用 IP 必须与已用于要迁移的 Pod 网关的公用 IP 不同，以支持回滚到第一代部署状态（如果需要回滚）。

因此，如果您具有此配置，请获取要使用的新公用 IP 地址，该地址与当前用于第一代 Pod 的外部网关的地址不同。

评估是否能够登录到新的 Horizon Cloud 环境，并显示 Horizon Cloud Horizon Universal Console

尝试登录到 connect.omnissa.com，并在登录后检查是否在“服务”UI 中看到标有 Workspace ONE Cloud 的卡。以下屏幕截图显示了一个示例。

  1. 先检查您是否在“服务”UI 中看到标有 Workspace ONE Cloud 的卡。以下屏幕截图显示了一个示例。

    “服务”UI 中的 Workspace ONE Cloud 卡的屏幕截图

  2. 如果您看到该卡，请单击其启动服务链接，然后检查是否看到标有 Horizon Cloud 的卡。以下屏幕截图显示了服务中的该卡。您的具体卡组合可能会有所不同。

    Horizon Cloud 卡的屏幕截图，其中有一个绿色箭头指向该卡。

    在单击该 Horizon Cloud 卡时，将开始打开 Horizon Cloud Horizon Universal Console。

    • 如果您以前载入了 Horizon Cloud 环境，您将会看到具有“迁移”屏幕的 Horizon Cloud Horizon Universal Console。
    • 如果您以前尚未完成载入 Horizon Cloud 环境的过程，系统将显示区域选择 UI（如云区域选择一节中所述），您可以执行其中所述的步骤以完成载入并看到具有“迁移”屏幕的控制台。

如果执行上述步骤没有导致显示 Horizon Cloud Horizon Universal Console，并且您已与 Horizon 迁移团队合作，请与该团队中与您合作的人员联系。如果您尚未与 Horizon 迁移团队合作，请与全球支持部门联系并请求获取 Horizon Cloud 迁移帮助。

以下屏幕截图显示了在上述步骤 2 结束时 Horizon Cloud Console 导航侧栏顶部的外观。主区域可能会显示该屏幕截图中显示的欢迎内容，也可能不会显示该内容。主区域可能会自动显示“迁移”屏幕。看到这种类型的导航侧栏意味着，您位于 Horizon Cloud Console 中。

Horizon Cloud Console 的导航侧栏顶部的屏幕截图。

确定您的身份提供程序，并将 AD 用户和组同步到该身份提供程序

在 Horizon Cloud 环境中，该服务依赖于使用外部身份提供程序和 Active Directory 域。

背景

在第一代租户中，您注册的 Active Directory 域用于计算机身份和用户身份，以对访问桌面和已发布应用程序的最终用户进行身份验证。

在 Horizon Cloud 环境中，您可以为该服务提供外部身份提供程序以满足用户身份要求。

使用外部身份提供程序可以与第三方解决方案集成在一起，以提供多因素身份验证等功能。

在将第一代 Pod 迁移到 Horizon Cloud Horizon Edge 时，该迁移后 Horizon Edge 使用 Active Directory 域管理计算机身份，这与第一代环境相同。迁移的虚拟桌面和提供已发布（远程）应用程序的那些虚拟机将加入 Active Directory 域。

**注意：**您为 Horizon Cloud 环境选择的身份提供程序应连接到第一代 Pod 的 Active Directory 域，这是在第一代租户中注册的域。

确定您将使用的身份提供程序

您决定在 Horizon Cloud Service 中注册的身份提供程序必须满足 Horizon Cloud 要求。

截至撰写本文时：

  • 只能将一个身份提供程序用于 Horizon Cloud 环境。
  • 支持的类型包括：
    • Microsoft Entra ID Commercial（对于 Azure Commercial 环境）和 Microsoft Entra ID Government（对于 Azure US Government 环境）。在 Azure US Government 环境中部署第一代 Pod 时，您将使用 Microsoft Entra ID Government。
    • Omnissa Access（云或内部部署版本）

有关其他背景信息，请参阅 Horizon Cloud 文档中的连接身份提供程序。

必备条件 - Microsoft Entra ID Commercial 或 Microsoft Entra ID Government

您将在 Horizon Cloud Horizon Universal Console 中运行向导，以将 Horizon Cloud 设置配置为使用 Microsoft Entra ID。

您需要以下项目以完成该向导。

必需项目详细信息
具有全局管理员特权的用户需要 Microsoft Entra ID 中的此用户，才能执行以下操作：
  • 批准请求的权限
  • 为整个组织提供同意
在向导 UI 中，您可以生成一个链接，并提供给该用户以登录到 Microsoft Entra ID，批准权限并同意 Horizon Cloud Service 访问 Microsoft Entra ID 中的用户信息。 如果您是 Microsoft Entra ID 中的全局管理员，向导将提示您登录到 Microsoft Entra ID，批准权限并提供同意。请按照屏幕上的指导进行操作。
租户子域向导将要求您在标有租户子域的字段中输入一个字符串。它必须以字母 [a-Z] 或数字 [0-9] 开头和结尾，并且仅包含字母、数字和短划线 [-]。该字符串是您自己创建的，这是您和您的团队编造出来使用的字符串。大多数人会输入与其公司或组织名称或公司域相关的字符串。

但请记住，以后最终用户使用迁移的 Horizon Cloud 环境登录到其桌面和应用程序时，他们将在使用公司域字段中输入该字符串。该字段在最终用户登录流程中提供。

必备条件 - Omnissa Access 云或内部部署版本

您将在 Horizon Cloud Horizon Universal Console 中运行向导，以将 Horizon Cloud 设置配置为使用 Access。

您需要以下项目以完成该向导。

必需项目详细信息
具有管理员特权的用户需要 Omnissa Access 中的此用户，才能执行以下操作：
  • 批准请求的权限
  • 为整个组织提供同意
租户子域向导将要求您在标有租户子域的字段中输入一个字符串。它必须以字母 [a-Z] 或数字 [0-9] 开头和结尾，并且仅包含字母、数字和短划线 [-]。该字符串是您自己创建的，这是您和您的团队编造出来使用的字符串。大多数人会输入与其公司或组织名称或公司域相关的字符串。 但请记住，以后最终用户使用迁移的 Horizon Cloud 环境登录到其桌面和应用程序时，他们将在使用公司域字段中输入该字符串。该字段在最终用户登录流程中提供。
Access 租户 FQDN在向导中，您需要输入 Access 租户 FQDN。此 FQDN 通常采用 yourcompany.workspaceoneaccess.com 格式。您可以从 Access 控制台中获取该 FQDN。
Access 租户客户端 ID 和客户端密钥（如果使用 Access 内部部署版本）使用 Access 内部部署版本时，向导会要求提供您为与 Horizon Cloud 环境集成而配置的 OAuth 客户端 ID 和 OAuth 客户端密钥。

将 Active Directory (AD) 用户和组与该身份提供程序同步

选择要迁移的 Pod 之前，请确认已授权从要迁移的 Pod 访问桌面和应用程序的所有 AD 用户和 AD 组均已与所选身份提供程序同步。

在系统的预验证检查期间，系统会从第一代 Pod 的桌面和应用程序分配中获取一组 AD 用户和组，并检查在 Horizon Cloud 环境中为这些 AD 用户和组注册的身份提供程序。如果系统在注册的身份提供程序中找不到这些 AD 用户或组之一，则预验证步骤将失败。从 UI 获取的故障报告将报告缺少的 AD 用户或组。

评估您对 Active Directory 内置用户或内置组的使用情况，并根据需要进行更新

如果将第一代 Horizon Cloud on Microsoft Azure 部署配置为使用 Azure Active Directory (Azure AD)，您必须在迁移之前更新指定了内置用户或内置组的位置，并更改为非内置组和用户。

系统会扫描第一代 Pod 以确定它们是否符合迁移条件，然后收集有关每个分配中指定的用户和组的信息，并尝试在 Horizon Cloud 环境配置的身份提供程序中创建等效配置。如果您在 Horizon Cloud 环境中将 Microsoft Azure AD 作为身份提供程序，Microsoft Azure AD Connect 会将 Active Directory 域同步到 Microsoft Azure AD。

但是，如 Microsoft 文档中所述，处理将 Active Directory 组同步到 Azure AD 的 Microsoft Azure AD Connect 同步会从其目录同步中排除内置安全组。因此，如果系统尝试在该身份提供程序中创建等效的第一代配置，并且您以前在该配置中使用了内置组和内置用户，则系统在 Azure AD 中找不到等效的实体，因为永远不会同步这些内置组和用户。系统将报告无法迁移涉及内置用户和内置组的 Pod。

在此场景中，请创建与内置组和内置用户具有相同成员资格的常规 Active Directory 组，无论您在何处指定用于接收桌面或远程应用程序的内置组和内置用户，都请更新这些设置以使用常规 Active Directory 组。

评估您对 App Volumes 应用程序分配的使用情况

如果第一代租户具有 App Volumes 应用程序分配，请验证 Horizon Cloud 环境是否具有有效的 App Volumes 许可证订阅。

在系统预验证检查期间，系统会检查您的 Horizon Cloud 环境是否存在有效的 App Volumes 许可证订阅。

如果未找到，系统会禁止计划 Pod 迁移并显示错误。

在 Horizon Cloud Console 中，您可以执行使用 Horizon Universal Console 跟踪 Horizon 许可证中所述的步骤，以验证在 Horizon Cloud 环境中是否存在许可证。

特殊情况 - 如果您的第一代 Pod 的应用程序注册使用的是自定义角色

如果将第一代 Pod 配置为使用自定义角色进行其订阅的 Horizon Cloud 应用程序注册，则迁移必备条件是使用 Horizon Cloud 环境中所需的权限更新该自定义角色。

使用自定义角色并不常见。大多数第一代 Pod 部署使用 Contributor 角色进行 Horizon Cloud 服务主体的应用程序注册。

以前，在部署第一代 Pod 时，它可能使用了自定义角色，如第一代文档页面在您的组织希望使用自定义角色时中所述。

如果您的 Pod 属于此场景，则必须更新该现有的自定义角色，以包含 Horizon Cloud 环境执行其必要 API 调用所需的权限。

在第一代 Pod 的订阅中，确认允许在 Horizon Cloud 应用程序注册的自定义角色（Pod 使用的应用程序注册）中执行以下操作。

其中一些权限与第一代 Pod 部署所需的权限相同。下表指出了 Horizon Cloud 环境还需要哪些权限。

**重要信息：**请勿移除自定义角色中已允许的操作。

Horizon Cloud 必需权限

在订阅级别分配权限时必须在自定义角色中允许的 Microsoft Azure 资源操作
 操作
要为 Horizon Cloud 允许的其他新权限 

Microsoft.ContainerService/managedClusters/delete
Microsoft.ContainerService/managedClusters/read
Microsoft.ContainerService/managedClusters/write
Microsoft.ContainerService/managedClusters/commandResults/read
Microsoft.ContainerService/managedClusters/runcommand/action
Microsoft.ContainerService/managedClusters/upgradeProfiles/read

Microsoft.ManagedIdentity/userAssignedIdentities/*/assign/action
Microsoft.ManagedIdentity/userAssignedIdentities/*/read

Microsoft.ResourceGraph/*

Microsoft.Resources/subscriptions/read

Microsoft.Network/privateEndpoints/read
Microsoft.Network/privateEndpoints/write
Microsoft.Network/privateEndpoints/delete
Microsoft.Network/locations/availablePrivateEndpointTypes/read
Horizon Cloud 需要且应在第一代 Pod 的自定义角色中已允许的权限如果自定义角色中尚不允许其中的任何一项，请在为上述操作更新角色时包括缺少的权限。
  • Microsoft.Authorization/*/read
  • Microsoft.Compute/*/read
  • Microsoft.Compute/availabilitySets/*
  • Microsoft.Compute/disks/*
  • Microsoft.Compute/galleries/read
  • Microsoft.Compute/galleries/write
  • Microsoft.Compute/galleries/delete
  • Microsoft.Compute/galleries/images/*
  • Microsoft.Compute/galleries/images/versions/*
  • Microsoft.Compute/images/*
  • Microsoft.Compute/locations/*
  • Microsoft.Compute/snapshots/*
  • Microsoft.Compute/virtualMachines/*
  • Microsoft.Compute/virtualMachineScaleSets/*
  • Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/read
  • Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/write
  • Microsoft.Network/loadBalancers/*
  • Microsoft.Network/networkInterfaces/*
  • Microsoft.Network/networkSecurityGroups/*
  • Microsoft.Network/virtualNetworks/read
  • Microsoft.Network/virtualNetworks/write
  • Microsoft.Network/virtualNetworks/checkIpAddressAvailability/read
  • Microsoft.Network/virtualNetworks/subnets/*
  • Microsoft.Network/virtualNetworks/virtualNetworkPeerings/read
  • Microsoft.Resources/deployments/*
  • Microsoft.Resources/subscriptions/resourceGroups/*
  • Microsoft.ResourceHealth/availabilityStatuses/read
  • Microsoft.Storage/*/read
  • Microsoft.Storage/storageAccounts/*

可选权限

尽管在 Microsoft Azure 中部署 Horizon Cloud Horizon Edge 时，以下权限并不是必需的，但如果您不包括这些可选权限，则依赖于这些权限的服务功能将无法正常使用。

为支持 Horizon Cloud 功能，在订阅级别分配权限时自定义角色必需的 Microsoft Azure 资源操作
 操作用途
要为 Horizon Cloud 允许的其他新权限 

Microsoft.Network/natGateways/join/action
Microsoft.Network/natGateways/read


Microsoft.Network/privateEndpoints/write 
Microsoft.Network/privateEndpoints/read


Microsoft.Network/routeTables/join/action
Microsoft.Network/routeTables/read

如果您将使用 AKS 部署类型进行迁移，并在“AKS 类型必备条件”中选择了在管理子网上使用 NAT 网关，则 Microsoft.Network/natGateways/join/action 和 Microsoft.Network/natGateways/read 是必需操作。

如果您将使用 AKS 部署类型进行迁移，并且 Pod 部署在 Azure Commercial 环境中，则 Microsoft.Network/privateEndpoints/write 和 Microsoft.Network/privateEndpoints/read 是必需的。需要具有这些权限才能创建专用端点资源并验证管理子网的 NAT 网关是否已正确配置。这些专用端点权限与迁移时将 Horizon Edge (AKS) 与 Azure 专用链路结合使用有关。注意：当第一代 Pod 部署在 Azure US Government 环境中，并且您使用 AKS 部署类型进行迁移时，Horizon Edge (AKS) 默认设置为使用 Internet 连接，而不是 Azure 专用链路。不支持在 Azure US Government 环境中使用 Azure 专用链路。

如果您将使用 AKS 部署类型，并在“AKS 类型必备条件”中选择了在管理子网上使用路由表，则需要 Microsoft.Network/routeTables/join/action 和 Microsoft.Network/routeTables/read 权限。服务需要这些权限才能创建专用端点资源并验证与管理子网关联的路由表，以确保正确配置默认路由。

Horizon Cloud 需要且应在第一代 Pod 的自定义角色中已允许的权限如果自定义角色中尚不允许其中的任何一项，请在为上述操作更新角色时包括缺少的权限。
  • Microsoft.KeyVault/*/read
  • Microsoft.KeyVault/vaults/*
  • Microsoft.KeyVault/vaults/secrets/*
  • Microsoft.Network/publicIPAddresses/*

池虚拟机的磁盘加密需要密钥文件库权限。

需要具有公用 IP 地址权限，才能在具有公用 IP 地址的负载均衡器后面部署具有 Unified Access Gateway 实例的 Horizon Edge 实例。此外，要执行部署和向映像添加公用 IP 地址，需要具有此公用 IP 地址权限。

**注意：**为方便起见，此处添加了这些信息，以便提前了解迁移后的 Horizon Cloud 环境。在 Pod 迁移之前更新权限时，您可能会考虑同时包含此权限。

当您的 Horizon Cloud 环境的身份提供程序是 Microsoft Entra ID，并且您希望将其用于计算机身份时，会出现这种场景。

有关详细信息，请参阅 Horizon Cloud 文档页面上有关 Microsoft Entra ID 的说明。

此页面对您有帮助吗?

对本主题提供反馈

本主题对您有帮助吗?

请勿填写任何个人信息或机密信息。

正在生成链接…