このページでは、最初のポッドの移行を開始する前に、必要に応じて評価、準備、および更新する必要がある領域について説明します。

概要

これらの評価と準備手順のほとんどは、新しい次世代環境にログインして移行ユーザー インターフェイスを表示する前であれば、いつでも実行できます。

これらの評価と準備手順の一部には、第 1 世代ポッドがデプロイされている Microsoft Azure サブスクリプション環境とネットワークが含まれます。その場合は、その環境を処理する IT チームのサポートが必要になる場合があります。

注意: 本書の執筆時点では、第 1 世代のポッドを移行する資格は、第 1 世代テナントへの段階的なロールアウトです。該当する場合は、 Horizon Migration Communications から直接通信を受け取ります。

用語集

次世代サービスには、新しい概念と用語があります。次世代サービスでは、デプロイは（「ポッド」という用語ではなく）「Horizon Edge」と呼ばれます。

セルフサービスの移行は、第 1 世代ポッドの移行に使用されるのと同じ Microsoft Azure サブスクリプションに Microsoft Azure Horizon Edge をデプロイし、同じサブスクリプション情報、VNet、サブネットを使用するように設計されています。

各ポッドが移行されると、プロセスはデフォルトでそのポッドから次の項目を再利用します。

  • Microsoft Azure サブスクリプション ID、ディレクトリ ID、サービス プリンシパル アプリケーション ID およびシークレット キー。
  • VNet
  • 管理サブネット、テナント サブネット、DMZ サブネット
  • 第 1 世代テナント(ドメイン バインドおよびドメイン参加ユーザー、補助ドメイン バインドおよびドメイン参加ユーザー)に登録されているドメイン情報とドメイン バインドおよびドメイン参加サービス アカウントをActive Directoryします。

    最初のポッドの移行がスケジュール設定されると、システムは第 1 世代テナントの登録済みActive Directoryドメイン情報とサービス アカウント情報をすべてコピーし、次世代環境で同じように登録します。

第 1 世代ポッドの一部のアイテムは再利用されません。これらのいくつかの場合は、新しい追加リソースを設定する必要があります。

したがって、次の領域を評価し、次世代の要件に対応するために必要に応じて準備する必要があります。

注： いくつかの特別な特性を持つポッドの場合、移行プロセスでは、第 1 世代ポッドとは異なる新しい VNet と管理サブネットの使用が必要になる場合があります。この特別なケースについては、このページのセクションで説明します。

前提条件の表

この表に続くセクションでは、これらの前提条件の詳細を示します。この表は、便利なアウトラインとして含まれています。

☐ 次世代 Unified Access Gateway. の新しい FQDN と証明書の取得
☐ 第 1 世代のポッドとエージェントのバージョンを評価し、必要に応じて更新します。
☐ ポッドの VNet または接続されたネットワークに AKS が制限された IP アドレスが含まれているかどうかを確認します。
☐ 展開タイプを決定し、その要件を満たします。
☐ ポッドの Microsoft Azure サブスクリプションにリソース グループ タグに関するポリシーがあるかどうかを確認します。「はい」の場合は、移行要件の処理方法を計画します。
☐ ネットワーク - ネットワーク トラフィックの既存の設定を評価し、必要に応じて更新します。
☐ ポッドに関連付けられたアプリケーション のプライベート キーがまだ有効であることを確認します。
☐ VNet - デスクトップへの内部アクセスに使用している現在のルーティングを評価します。
☐ Microsoft Azure vCPU ファミリの割り当てを評価し、必要に応じて増やします。
☐ Unified Access Gateway ロード バランサのパブリック IP アドレスがある場合は、「このロード バランサのパブリック IP アドレスがある場合」のガイダンスに従ってください。
☐ Unified Access Gateway ロード バランサのプライベート IP アドレスがある場合は、「このロード バランサのプライベート IP アドレスがある場合」のガイダンスに従ってください。
☐ 新しい次世代環境にログインし、次世代の Horizon Universal Console を表示する機能を評価します。
☐ ID プロバイダを決定し、Active Directory ユーザーとグループを同期します。
☐ Active Directory組み込みユーザーまたは組み込みグループの使用を評価し、必要に応じて更新します。
☐ App Volumesアプリケーション割り当ての使用を評価します。
☐ 特殊なケース - 第 1 世代ポッドのアプリケーション登録でカスタム ロールが使用されている場合は、「第 1 世代ポッドのアプリケーション登録でカスタム ロールが使用されている場合」のガイダンスに従って、次世代のデプロイに必要な権限を更新します。

次世代 Unified Access Gateway の新しい FQDN と証明書の取得

注： 次世代の Unified Access Gateway デプロイの FQDN は、移行する第 1 世代のデプロイですでに使用されている FQDN とは異なるものにする必要があります。まれに移行後に問題が発生した場合の第 1 世代のデプロイへのロールバックをサポートするには、第 1 世代のデプロイのゲートウェイの FQDN とその SSL 証明書を、第 1 世代のデプロイ用に構成されたままにする必要があります。移行を完了した後にのみ、その時点で必要であれば、次世代ゲートウェイ デプロイの FQDN と SSL 証明書を更新できます。

スケジュール設定ウィザードのユーザー インターフェイスでは、ウィザードでこの FQDN を指定し、その FQDN に基づいて SSL 証明書を指定する必要があります。

次世代環境の場合、SSL 証明書は PEM または PFX のいずれかの形式にすることができます。

証明書に設定されている共通名または FQDN は、スケジュール ウィザードに入力する FQDN と一致する必要があります。ウィザードは、証明書のデータがウィザードに入力した FQDN と一致することを検証します。

必要に応じて第 1 世代ポッドとエージェントのバージョンを評価し、更新します

ポッドを移行する前に、ポッドとエージェントのバージョンが次の基準を満たしている必要があります。

  • ポッドHorizon Cloudポッド マニフェスト 4136.0 以降を実行している必要があります。以前のマニフェストを実行している場合は、サービス要求を開始してポッドをアップグレードします。
  • ポッドの専用 VDI デスクトップは、移行プロセスでサポートされるエージェント バージョン(バージョン 23.1.0.22973254 以降Horizon Agents Installer)を実行している必要があります。専用 VDI デスクトップで 23.1.0.22973254 より前のバージョンのエージェントが実行されている場合は、移行前にエージェントをバージョン 23.1.0.22973254 以降に更新します。
  • フローティング VDI デスクトップおよびイメージは、エージェントのバージョンが Horizon Cloud on Microsoft Azure バージョン 2210 の VMware 相互運用性マトリックスに準拠している限り、22.3.x より前のバージョンのエージェントを含むことができます。

ポッドの VNet または接続されたネットワークに AKS 制限付き IP アドレスが含まれているかどうかの判断

重要： 決定の結果は、移行に使用する Horizon Edge Gateway 展開のタイプに関するガイダンスを提供します。タイプについては、次の「 Edge Gateway のデプロイ タイプを決定する」セクションで説明します。

第 1 世代ポッドの管理サブネット、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

含める場合、そのポッドを移行するには、次に単一仮想マシンのデプロイ タイプでニーズを満たすことができるかどうか、または AKS デプロイ タイプのみで満たせる要件があるかどうかを評価する必要があります。

  • 単一仮想マシンのデプロイ タイプを使用してそのポッドを移行するか、
  • 要件で AKS デプロイ タイプの使用が規定されている場合は、ポッドのサブスクリプション内のその VNet に最小 CIDR /26 の新しい VNet と管理サブネットを設定し、その新しい VNet をポッドの既存の VNet とピアリングする必要があります。最小 /26 CIDR は、AKS 展開タイプに対する強力な推奨です。

    新しい VNet に制限された範囲の IP アドレスが含まれていないか、使用されていないことを確認します。新しい VNet と管理サブネットを使用すると、HA を提供する AKS デプロイ タイプを使用できます。

詳細なガイダンスについては、Edge Gateway のデプロイ タイプの決定に関する次のセクションを参照してください。

これらの特定の範囲が AKS で制限されている理由は、Microsoft が、AKS タイプの Horizon Edge Gateway デプロイに使用される Azure Kubernetes Service (AKS) クラスタに関してこのルールを適用するためです。

これらの制限付き IP アドレスがポッドの管理サブネットまたは VNet に含まれている場合、または VNet に接続されているオンプレミス ネットワークに含まれている場合、AKS タイプを使用した移行プロセスはポッドの既存の VNet を再利用できません。

展開タイプを決定し、その要件を満たす

第 1 世代ポッドを次世代環境に移行する場合、システムは Horizon Edge Gateway と呼ばれるものをポッドの Microsoft Azure サブスクリプションにデプロイします。

デプロイには、単一仮想マシン（単一 VM）タイプと Azure Kubernetes サービス (AKS) タイプの 2 つのタイプがあります。

システムでは、各ポッドの移行に使用するタイプを指定できます。

したがって、次の表に従って、必要な品質に基づいて、使用するタイプを決定する必要があります。

Edge Gateway のデプロイ 主な品質 詳細
[単一仮想マシン]
  • 最大 5,000 セッションをサポートします。
  • AKS タイプよりも Microsoft Azure サブスクリプションに含まれる前提条件が少ない
  • AKS 要件を簡単に満たすことができないポッドの移行に対応します。
  • 展開された が将来使用できない場合、結果の動作は次のようになります。
    • エンド ユーザーはシングル サインオン (SSO) なしでログインする必要があります。
    • 仮想マシンが使用できない間、デスクトップの監視データは記録されません。

単一仮想マシン タイプでは、AKS タイプに比べて第一世代ポッドの移行がより簡単です。

簡単になる理由は、単一仮想マシン タイプでは、AKS タイプに比べ、ポッドの Azure サブスクリプションに含まれる新しい要件が少ないことです。その結果、AKS タイプの要件を簡単に満たすことができない第一世代のポッドデプロイに対応できます。

簡単であることに加えて、デプロイされた仮想マシンが使用できなくなった場合の動作が、単一仮想マシン タイプと AKS タイプでは異なります。使用できない場合：

  • エンド ユーザーには、SSO ログイン エクスペリエンスなしでログイン フローが表示されます。たとえば、デスクトップを表示する前に、Active Directory認証情報を使用してログインする必要があります。
  • Edge Gateway 仮想マシンに送信されるデスクトップの監視データは、仮想マシンが使用できない間は記録されません。
[AKS]
  • 5,000 を超えるセッションをサポートします。
  • Azure Kubernetes サービスには、満たす必要がある Microsoft 関連の要件があります
  • AKS 要件を満たすことができるポッドの移行に対応します。
  • SSO ログイン エクスペリエンスと監視データ収集は、レプリケートされたサービスを介して処理され、これらの機能の可用性の高い配信が可能になります。

AKS は、Microsoft Azure データセンターのエンタープライズ クラウド ネイティブ アプリケーションの Microsoft Azure 標準です。

AKS タイプは、クラスタ化されたアーキテクチャの Edge Gateway を提供し、SSO ログイン エクスペリエンスと監視データ収集をサポートする複製されたサービスを提供します。
次の決定表に関する 2 つの質問:
  1. 5,000 を超えるセッションに対する要件や、障害発生時の完全なフェイルオーバー機能を備えたサービスを通じてサポートされる SSO ログイン エクスペリエンスと監視データの収集に関する要件はありますか?
  2. AKS で制限された IP アドレス範囲のいずれかがポッドの管理サブネット、ポッドの VNet、またはオンプレミス ネットワークに接続されていることがわかっているマシンで使用されていますか?
入力された回答 使用する方法 満たす前提条件
  1. はい
  2. いいえ
 最初の質問には AKS タイプが必要です。

5,000 を超えるセッションが必要で、SSO ログイン エクスペリエンスと監視データ収集の要件を満たす必要がある場合、それらを提供するには AKS タイプが必要です。

 AKS タイプの前提条件
  1. はい
  2. はい
 最初の質問には AKS タイプが必要です。

この場合、5,000 を超えるセッションを提供し、SSO ログイン エクスペリエンスとデータ収集の監視に関する要件を満たすためには AKS タイプが必要ですが、ポッドの VNet は AKS タイプの IP アドレス制限に反しています。

AKS タイプの要件をサポートするには、次の手順を実行する必要があります。

  1. 制限付き IP アドレスを含まない、ポッドのサブスクリプション内のその VNet に別の VNet と管理サブネットを設定します。
  2. 新しい VNet と管理サブネットが AKS Edge Gateway の要件を満たしていることを確認します。
  3. 新しい VNet をポッドの既存の VNet とピアリングします

次に、移行ウィザードを実行するときに、その新しい VNet と管理サブネットと Azure Kubernetes サービス オプションを選択します。

 AKS タイプの前提条件
  1. いいえ
  2. いいえ
 最初の質問に「いいえ」を答えると、ニーズを満たしているのは単一仮想マシン タイプです。

同時に、ポッドの VNet は AKS タイプの IP 制限を満たしているため、移行に AKS タイプを使用することもできます。

 単一仮想マシン タイプには、「第 1 世代 Horizon Cloud ポッドを移行するための前提条件」ページとそのすべてのサブセクションで詳述されている要件を超える特定の要件はありません。
  1. いいえ
  2. はい
 最初の質問に「いいえ」を答えると、ニーズを満たしているのは単一仮想マシン タイプです。次のいずれかを選択します。
  • 最も簡単なオプションは、単一仮想マシン タイプを使用することです。
  • より複雑なオプションは、次の方法で AKS が制限された IP アドレスを回避することです。
    1. 制限付き IP アドレスを含まないポッドのサブスクリプション内の、その VNet に別の VNet と管理サブネットを設定します。
    2. 新しい VNet と管理サブネットが AKS Edge Gateway の要件を満たしていることを確認します。
    3. その新しい VNet をポッドの既存の VNet とピアリングする

    上記の項目を満たすことで、必要に応じてAKSタイプを使用することもできます。

 単一仮想マシン タイプには、「第 1 世代 Horizon Cloud ポッドを移行するための前提条件」ページとそのすべてのサブセクションで詳述されている要件を超える特定の要件はありません。

ポッドの Microsoft Azure サブスクリプションにリソース グループ タグに関するポリシーがあるかどうかを判断する

本書の執筆時点では、Horizon Edge のデプロイ プロセスでは、Microsoft Azure サブスクリプションがタグを持っていないリソース グループの作成を許可する必要があります。

移行メンテナンスウィンドウの日時をスケジュール設定すると、システムは Horizon Edge Gateway および Unified Access Gateway インスタンスのリソース グループを作成します。

したがって、ポッドのサブスクリプションにタグ付けされていないリソース グループの作成をブロックする Microsoft Azure ポリシーがある場合、またはサブスクリプションに任意のタイプのリソース タグ要件がある場合、そのスケジュール設定手順の直後に移行プロセスが失敗します。

サブスクリプションにそのようなポリシーがある場合は、移行スケジュール ウィザードを完了する直前にその Azure ポリシーをオフにし、Horizon Edge Gateway インスタンスと Unified Access Gateway インスタンスがサブスクリプションにデプロイされるまでポリシーをオフのままにする計画を立てることで、この要件を管理できます。Horizon Edge Gateway および Unified Access Gateway インスタンスが正常にデプロイされたことを確認したら、リソース グループの作成時にタグを要求する Azure ポリシーを、移行アクティビティに影響を与えずに再度有効にすることができます。

ネットワーク - ネットワーク トラフィックの既存の設定を評価し、必要に応じて更新する

現在のファイアウォール設定で、次世代 Horizon Edge で必要なエンドポイントとポートおよびプロトコルへの接続が許可されているかどうかを評価します。

次世代サービスに必要なエンドポイント URL とポートは、ネットワーク チームが第 1 世代ポッドに対してすでに許可しているものと異なる可能性があります。

必要なエンドポイント、ポート、プロトコルのリストについては、『Horizon Cloud Service - next-gen の使用』ガイドの以下のページを参照して、第 1 世代ポッドの環境に加える変更を決定してください。

ポッドに関連付けられたアプリケーション シークレット キーがまだ有効であることを確認する

ポッド デプロイのための Azure ポータルにログインし、ポッドで使用されるアプリケーション キーの有効期限が切れていないことを確認します。

Azure ポータルでは、アプリケーション登録領域でクライアント シークレット キーという用語を使用します。ポッドに関連付けられているアプリケーション登録を見つけます。

VNet - デスクトップへの内部アクセスのルーティングの評価

第 1 世代ポッドとデスクトップへの内部アクセス用に設定されているルーティングによっては、次世代 Horizon Edge でデスクトップへの内部アクセスが引き続き機能するように、そのルーティングの調整が必要になる場合があります。

Microsoft Azure vCPU ファミリの割り当てを評価し、必要に応じて増やします

第 1 世代ポッドの Microsoft Azure サブスクリプションの現在の vCPU ファミリ割り当てによっては、移行プロセスをサポートするために特定の vCPU ファミリの割り当てを増やす必要がある場合があります。

移行プロセスでは、少なくとも 1 つの Horizon Edge Gateway と 2 つのUnified Access Gateway インスタンスで構成される Horizon Edge をデプロイします。

Microsoft Azure にデプロイされた Horizon Edge には、単一仮想マシンのデプロイ タイプまたは AKS デプロイ タイプの Horizon Edge Gateway があります。

「Edge Gateway のデプロイ タイプを決定する」の説明に従って、ポッドの移行に使用するタイプを決定します。

目的 追加の vCPU/割り当て容量のニーズ
Unified Access Gateway インスタンス 2 つのStandard_F8s_v2に対応する追加の割り当て
Horizon Edge Gateway - 単一仮想マシンのデプロイ タイプ（このタイプを選択した場合） 次の仮想マシン SKU サイズの 1 台の仮想マシンに対応する追加の割り当て：
  • Standard_D4s_v3 - 4 個の vCPU
  • Standard_D4s_v4 - 4 個の vCPU
  • Standard_D4s_v5 - 4 個の vCPU
Horizon Edge Gateway - このタイプを選択した場合は、AKS デプロイ タイプ

次の仮想マシン SKU サイズの 5 台の仮想マシンに対応する追加の割り当て：

  • Standard_D2s_v3 - 2 個の vCPU
  • Standard_D2ds_v5 - 2 個の vCPU
  • Standard_D2a_v4 - 2 個の vCPU

ポッドのサブスクリプションに、上記の少なくとも 1 つの仮想マシン SKU サイズの 5 台の仮想マシンに対応できるキャパシティがある場合、4 ノード Edge Gateway (AKS) という移行要件が満たされ、AKS の将来のアップグレードのための 1 ノードという要件も満たされます。

これらの仮想マシン SKU 要件の背景にあるのは、Edge Gateway (AKS) デプロイでは Azure Kubernetes サービス (AKS) クラスタが使用され、そのためキャパシティとして以下にリストされているいずれかの仮想マシン サイズの仮想マシン ノードが 4 つ必要であるということです。

次に、1 つの追加ノードが必要で、アップグレード プロセス中に使用されます。

これにより、これらの仮想マシン SKU が合計で 5 つ必要になります。
イメージ
  • 各イメージが複製され、next-gen に移行されます。その結果、ファミリ内のイメージあたりの vCPU の量の 2 倍が必要になります。

    たとえば、2 つの vCPU コアを持つ Standard_DS2_v2 のイメージを移行するには、移行中に 2 つの追加の vCPU コアが必要です。そのため、Azure サブスクリプションには、対応するリージョンの Standard DSv2 ファミリの vCPU コアが少なくとも 4 つ必要です。

    ただし、イメージは 20 のバッチで移行されるため、この超過割り当てはイメージあたりの vCPU コア数の 20 倍を超える必要はありません。つまり、イメージ vCPU の 20 倍の割り当てだけではなく、既存の割り当てに加えてイメージ vCPU の 20 倍の超過割り当てが必要になります。

Unified Access Gateway ロード バランサのパブリック IP アドレスがある場合

第 1 世代ポッドが外部 Unified Access Gateway 構成のロード バランサにパブリック IP アドレスを使用している場合、システムは次世代 Horizon Edge を立ち上げて、Horizon Edge の Unified Access Gateway 構成にパブリック IP アドレスを使用します。

この場合、ポッドのサブスクリプションには追加のパブリック IP アドレスが必要です。したがって、移行をスケジュール設定する前に、サブスクリプションにこの追加のパブリック IP アドレスを提供するキャパシティがあることを確認します。

Unified Access Gateway ロード バランサのプライベート IP アドレスがある場合

第 1 世代の外部 Unified Access Gateway デプロイのロード バランサがプライベート IP アドレスを使用している場合は、次世代のデプロイのロード バランサにルーティングするパブリック IP アドレスを取得します。

移行する第 1 世代の外部ゲートウェイ構成がロード バランサにプライベート IP アドレスを使用し、パブリック IP アドレスがそのプライベート IP アドレスにルーティングされている場合、システムは移行のスケジュール設定を開始するときにこの構成を検出します。

このシナリオは、外部ゲートウェイ構成の Unified Access Gateway アプライアンスへのアクセスを許可する前にインターネット ベースのトラフィックを制御する目的で、外部ゲートウェイ構成の Azure ロード バランサの前にファイアウォールまたは NAT が構成されている場合に、第 1 世代のデプロイで使用されました。

システムは、スキャン プロセス中に、移行の準備完了 状態であると判断したときに、第 1 世代の構成を検出します。

システムがその構成を検出すると、移行のスケジュール設定ウィザードのユーザー インターフェイスに [手動パブリック IP アドレス] フィールドが表示されます。このフィールドには、次世代の Unified Access Gateway デプロイに使用するパブリック IP アドレスを入力します。

注： ロールバックが必要な場合に第 1 世代のデプロイ状態へのロールバックをサポートするため、このパブリック IP アドレスは、移行対象のポッドのゲートウェイですでに使用されているパブリック IP アドレスとは異なる必要があります。

したがって、この構成を使用している場合は、使用する新しいパブリック IP アドレス（第 1 世代ポッドの外部ゲートウェイに現在使用されているアドレスとは異なるアドレス）を取得します。

新しい次世代環境にログインし、次世代 Horizon Universal Console を確認する機能の評価

console.cloud.vmware.com にログインし、ログイン後、サービス ユーザー インターフェイスに [Workspace ONE Cloud] というラベルのカードが表示されるかどうかを確認してください。次のスクリーンショットは例を示します。

  1. 最初に、サービス ユーザー インターフェイスに [Workspace ONE Cloud] というラベルのカードが表示されているかどうかを確認します。次のスクリーンショットは例を示します。
    console.cloud.vmware.com のサービス ユーザー インターフェイスでの Workspace ONE クラウド カードのスクリーンショット
  2. カードが表示された場合は、[サービスの起動] リンクをクリックし、[Horizon Cloud] というラベルのカードが表示されるかどうかを確認します。このスクリーンショットは、Workspace ONE サービス内のカードを示しています。カードのセットが異なる場合があります。
    [Horizon Cloud] カードとそのカードを指している緑色の矢印のスクリーンショット。

    [Horizon Cloud] カードをクリックすると、次世代 Horizon Universal Console が開きます。

    • 以前に次世代環境にオンボーディングした場合は、次世代 Horizon Universal Console に [移行] 画面が表示されます。
    • 次世代環境へのオンボーディングをまだ完了していない場合は、「クラウド リージョンの選択」セクションで説明するようにリージョン選択ユーザー インターフェイスが表示されます。オンボーディングを完了するための手順を実行すると、コンソールに [移行] 画面が表示されます。

上記の手順を実行しても次世代 Horizon Universal Console が表示されず、すでに VMware Horizon 移行チームと連携している場合は、チームの担当者にお問い合わせください。VMware Horizon 移行チームとまだ連携していない場合は、VMware グローバル サポートにお問い合わせいただき、Horizon Cloud 移行サポートを依頼してください。

次のスクリーンショットは、上記の手順 2 の最後にある次世代コンソールのナビゲーション側の上部の外観を示しています。メイン領域には、このスクリーンショットに表示されているようこそコンテンツが表示される場合と表示されない場合があります。メイン領域に移行画面が自動的に表示されることがあります。このタイプのナビゲーションを表示すると、次世代のコンソールに移動します。


次世代コンソールのナビゲーションの上部を示すスクリーンショット。

ID プロバイダを決定し、Active Directory ユーザーとグループを同期する

次世代環境では、サービスは外部 ID プロバイダと Active Directory ドメインの両方の使用に依存します。

背景

第 1 世代テナントでは、デスクトップおよび公開アプリケーションへのエンドユーザー アクセスを認証するために、登録済みの Active Directory ドメインがマシン ID とユーザー ID の両方に使用されていました。

次世代環境では、サービスに外部 ID プロバイダを提供して、ユーザー ID 側の条件を満たします。

外部 ID プロバイダを使用すると、サードパーティのソリューションと統合して、多要素認証などの機能を提供できます。

第 1 世代ポッドから次世代 Horizon Edge への移行では、移行後の Horizon Edge は、第 1 世代の環境と同様にマシン ID に Active Directory ドメインを使用します。移行された仮想デスクトップと、公開（リモート）アプリケーションを提供する仮想マシンは、Active Directory ドメインに参加します。

注： 次世代環境に選択する ID プロバイダは、第 1 世代テナントに登録されている第 1 世代ポッドの Active Directory ドメインに接続する必要があります。

使用する ID プロバイダを決定する

次世代サービスに登録する ID プロバイダは、Horizon Cloud Service - next-gen の要件を満たす必要があります。

本書の執筆時点での状況は以下のとおりです。

  • 次世代環境で使用できる ID プロバイダは 1 つのみです。
  • サポートされているタイプ：
    • Microsoft Entra ID
    • Workspace ONE Access（クラウドまたはオンプレミス）

その他の背景情報については、Horizon Cloud Service next-gen ドキュメントの「ID プロバイダのセットアップ」を参照してください。

前提条件 - Microsoft Entra ID

次世代 Horizon Universal Console でウィザードを実行して、Microsoft Entra ID を使用するように次世代の設定を構成します。

ヒント: Microsoft Entra ID を ID プロバイダとして構成する操作を説明したビデオについては、Tech Zone ビデオ「 Scheduling a Horizon Cloud on Microsoft Azure pod migration」の開始 3 分からご覧ください。

ウィザードを完了するには、次の項目が必要です。

必要な項目 詳細
グローバル管理者権限を持つユーザー Microsoft Entra ID のこのユーザーは、次の場合に必要です。
  • 要求された権限を承認する
  • 組織全体の同意書を提供する

ウィザード ユーザー インターフェイスの一部として、Microsoft Entra ID にログインして権限を承認し、次世代サービスが Microsoft Entra ID のユーザー情報にアクセスするための同意書を提供できるようにするリンクを生成してそのユーザーに提供します。

Microsoft Entra ID のグローバル管理者の場合、ウィザードは、Microsoft Entra ID にログインして権限を承認し、同意書を提供するよう求めるプロンプトを表示します。画面に表示される指示に従います。
テナント サブドメイン ウィザードは、[テナント サブドメイン] というラベルの付いたフィールドに文字列を入力するよう要求します。英字 (a ～ Z) または数字 (0 ～ 9) で開始および終了する必要があります。また、英字、数字、およびダッシュ (-) のみを使用できます。

この文字列はユーザー自身が作成したものであり、ユーザーとユーザーのチームが使用するために作成した文字列です。ほとんどの場合、会社名、組織名、または会社のドメインに関連する文字列を入力します。

ただし、エンド ユーザーが移行された次世代環境を使用して後でデスクトップやアプリケーションにログインするときに、この文字列を [会社のドメインを使用] フィールドに入力することに注意してください。このフィールドは、エンドユーザーのログイン フローの一部として表示されます。

ヒント: エンドユーザーのログイン フローと [テナント サブドメイン] 文字列を使用する場所を説明したビデオについては、 管理者とエンドユーザーのログイン フローを比較する Tech Zone ビデオの 3:30 からご覧ください。

前提条件 - Workspace ONE Access クラウドまたはオンプレミス

次世代 Horizon Universal Console でウィザードを実行して、Workspace ONE Access を使用するように次世代の設定を構成します。

ヒント: Workspace ONE Access を ID プロバイダとして構成する操作を説明したビデオについては、「 Tech Zone 実習：Horizon Cloud のユーザー ID プロバイダとして Workspace ONE Access を接続する」のビデオをご覧ください。

ウィザードを完了するには、次の項目が必要です。

必要な項目 詳細
管理者権限を持つユーザー Workspace ONE Access のこのユーザーは、次の場合に必要です。
  • 要求された権限を承認する
  • 組織全体の同意書を提供する
テナント サブドメイン ウィザードは、[テナント サブドメイン] というラベルの付いたフィールドに文字列を入力するよう要求します。英字 (a ～ Z) または数字 (0 ～ 9) で開始および終了する必要があります。また、英字、数字、およびダッシュ (-) のみを使用できます。

この文字列はユーザー自身が作成したものであり、ユーザーとユーザーのチームが使用するために作成した文字列です。ほとんどの場合、会社名、組織名、または会社のドメインに関連する文字列を入力します。

ただし、エンド ユーザーが移行された次世代環境を使用して後でデスクトップやアプリケーションにログインするときに、この文字列を [会社のドメインを使用] フィールドに入力することに注意してください。このフィールドは、エンドユーザーのログイン フローの一部として表示されます。

ヒント: エンドユーザーのログイン フローと [テナント サブドメイン] 文字列を使用する場所を説明したビデオについては、 管理者とエンドユーザーのログイン フローを比較する Tech Zone ビデオの 3:30 からご覧ください。
Workspace ONE Access テナントの FQDN ウィザードで、Workspace ONE Access テナントの FQDN を入力します。通常、この FQDN は yourcompany.workspaceoneaccess.com の形式です。この FQDN は、Workspace ONE Access コンソールから取得できます。
Workspace ONE Access テナントのクライアント ID とクライアント シークレット（Workspace ONE Access オンプレミスを使用している場合） Workspace ONE Access オンプレミスを使用する場合、ウィザードは、次世代環境との統合を目的として構成した OAuth クライアント ID と OAuth クライアント シークレットを要求します。

Active Directory (AD) ユーザーとグループをその ID プロバイダと同期する

移行するポッドを選択する前に、移行対象のポッドからデスクトップおよびアプリケーションの使用資格が付与されているすべての Active Directory ユーザーと Active Directory グループが、選択した ID プロバイダと同期されていることを確認します。

システムの事前検証チェック中に、システムが第 1 世代のポッドのデスクトップおよびアプリケーション割り当てから一連の Active Directory ユーザーとグループを取得し、これらの Active Directory ユーザーおよびグループの次世代環境に登録されている ID プロバイダをチェックします。登録済み ID プロバイダ内の Active Directory ユーザーまたはグループのいずれかが見つからない場合、事前検証の手順は失敗します。ユーザー インターフェイスから取得した障害レポートは、見つからない Active Directory ユーザーまたはグループを報告します。

Active Directory 組み込みユーザーまたは組み込みグループの使用を評価して必要に応じて更新

第 1 世代の Horizon Cloud on Microsoft Azure デプロイが Azure Active Directory (Azure AD) を使用するように構成されている場合は、移行の前に、指定された組み込みグループや組み込みユーザーを使用している場所を更新し、組み込みグループや組み込みユーザー以外に変更する必要があります。

システムが第 1 世代のポッドをスキャンして移行基準を満たしているかどうかを判断し、各割り当てに指定されたユーザーとグループに関する情報を収集し、次世代環境の構成済み ID プロバイダで同等の構成を作成しようとします。Microsoft Azure AD を次世代環境の ID プロバイダとして使用する場合、Microsoft Azure AD Connect で Active Directory ドメインを Microsoft Azure AD と同期します。

ただし、Microsoft ドキュメントに記載されているように、Active Directory グループと Azure AD の同期を処理する Microsoft Azure AD Connect 同期では、組み込みのセキュリティ グループがディレクトリ同期から除外されます。その結果、システムがその ID プロバイダで、組み込みグループと組み込みユーザーを使用した同等の 第 1 世代の構成を作成しようとすると、組み込みグループが同期されないため、Azure AD では同等のエンティティが見つかりません。組み込みユーザーと組み込みグループが関係するポッドは移行できないことが報告されます。

このシナリオでは、組み込みグループや組み込みユーザーと同じメンバーシップを持つ通常の Active Directory グループを作成します。また、デスクトップまたはリモート アプリケーションを受信するために組み込みグループと組み込みユーザーを指定した場合は、それらの設定を更新して通常の Active Directory グループを使用します。

App Volumes アプリケーション割り当ての使用状況の評価

第 1 世代のテナントに App Volumes アプリケーション割り当てがある場合は、次世代環境に有効な App Volumes ライセンス サブスクリプションがあることを確認します。

システムの事前検証チェック中に、システムは次世代環境に有効な App Volumes ライセンス サブスクリプションがあるかをチェックします。

見つからない場合、システムはポッドの移行のスケジュール設定をエラーと判断し、実行されないようにします。

次世代コンソールでは、Horizon Universal Console を使用して Horizon ライセンスを追跡するに記載されている手順を使用して、次世代環境でのライセンスの存在を確認できます。

特殊なケース - 第 1 世代ポッドのアプリケーション登録でカスタム ロールが使用されている場合

第 1 世代ポッドがサブスクリプションの Horizon Cloud アプリケーション登録にカスタム ロールを使用するように構成されている場合、移行の前提条件は、そのカスタム ロールを次世代環境で必要な権限で更新することです。

カスタム ロールの使用は一定ではありません。ほとんどの第 1 世代ポッドのデプロイでは、Horizon Cloud サービス プリンシパルのアプリケーション登録に共同作成者ロールが使用されます。

第 1 世代のポッドがデプロイされたとき、第 1 世代のドキュメント ページ「組織がカスタム ロールの使用を希望する場合」で説明されているように、カスタム ロールが使用されていた可能性があります。

ポッドがこのシナリオに該当する場合は、next-gen 環境が必要な API 呼び出しを行うために必要な権限を含むように、既存のカスタム ロールを更新する必要があります。

第 1 世代ポッドのサブスクリプションで、Horizon Cloud アプリケーション登録のカスタム ロール(ポッドで使用されるアプリケーション登録)で次の操作が許可されていることを確認します。

これらの一部は、第 1 世代ポッドのデプロイに必要なのと同じです。この表には、次世代環境に追加で必要となるものが記載されています。

重要： カスタム ロールですでに許可されている操作を削除しないでください。

次世代の必須権限

表 1. サブスクリプション レベルで権限を割り当てるときに、カスタム ロールで許可する必要がある Microsoft Azure リソースの操作
運用
Additional new ones to allow for next-gen 
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
Needed by next-gen which should be already allowed in your first-gen pod's custom role カスタム ロールでこれらのいずれかが許可されていない場合は、前述の操作のロールを更新するときに不足しているロールを含めます。
  • 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/gallerys/images/*
  • Microsoft.Compute/gallerys/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 Edge をデプロイする場合、次の権限は必須ではありませんが、これらのオプションの権限に依存するサービスの機能は、これらの権限を含めない場合は機能しません。

表 2. 次世代機能をサポートするために、サブスクリプション レベルで権限を割り当てるときにカスタム ロールに必要な Microsoft Azure リソース操作
運用 目的
Additional new ones to allow for next-gen 
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

Microsoft.Network/natGateways/join/action および Microsoft.Network/natGateways/read は、移行に AKS デプロイ タイプを使用し、AKS タイプの前提条件で管理サブネットで NAT ゲートウェイを使用することを選択した場合に必要な操作です。サービスには、プライベート エンドポイント リソースを作成し、管理サブネットの NAT ゲートウェイが正しく構成されていることを検証するために、これらの権限が必要です。

移行に AKS 展開タイプを使用する場合は、これらのプライベート エンドポイント権限が必要です。これらは、Azure プライベート リンクを使用した Horizon Edge (AKS) の移行の使用に関連しています。

これらのルート テーブル権限は、AKS デプロイ タイプを使用し、AKS タイプの前提条件で管理サブネットでルート テーブルを使用することを選択した場合に必要です。サービスには、プライベート エンドポイント リソースを作成し、管理サブネットに関連付けられているルート テーブルを検証して、デフォルト ルートが正しく構成されていることを確認するために、これらの権限が必要です。
Needed by next-gen which could be already allowed in your first-gen pod's custom role カスタム ロールでこれらのいずれかが許可されていない場合は、前述の操作のロールを更新するときに不足しているロールを含めます。
  • Microsoft.KeyVault/*/read
  • Microsoft.KeyVault/vaults/*
  • Microsoft.KeyVault/vaults/secrets/*
  • Microsoft.Network/publicIPAddresses/*

プール仮想マシンのディスク暗号化には、キー コンテナの権限が必要です。

パブリック IP アドレスを持つロード バランサの背後に、Unified Access Gateway インスタンスを含む Horizon Edge インスタンスをデプロイするには、パブリック IP アドレス権限が必要です。また、イメージをデプロイし、イメージにパブリック IP アドレス追加するには、この権限は必須です。
注： この情報は、移行後の次世代環境を見据えて、利便性を高める目的で追加されています。ポッドの移行の前に権限を更新する場合は、この権限を同時に含める場合があります。

このシナリオは、次世代環境の ID プロバイダが Microsoft Entra ID で、マシン ID に使用する場合です。

詳細については、次世代のドキュメント ページの Microsoft Entra ID に関する注意事項を参照してください。