第 1 世代の Horizon Cloud on Microsoft Azure デプロイから Horizon Cloud Service - next-gen へのセルフサービスの移行

次世代環境が有効になっている場合は、第 1 世代 Horizon Cloud の制御プレーンにある Horizon Cloud on Microsoft Azure デプロイの Horizon Cloud Service - next-gen へのセルフサービス移行を開始できます。

注： 本書の執筆時点では、ポッド フリートが完全に VMware Horizon 8 ポッド（Connection Server タイプのポッド）で構成される第 1 世代環境は、このセルフサービス移行プロセスおよびこの付属の移行ガイドには含まれていません。移行プロセスは、 Horizon Cloud on Microsoft Azure ポッドとは異なります。 Horizon 8 ポッドの移行に関する情報については、 VMware Horizon 8 の担当者にお問い合わせください。

はじめに

ユーザーまたは Horizon 移行チームが移行プロセスをどこまで完了したかに応じて、以下のリンクの 1 つを選択して内容を確認します。

注目: Horizon Cloud Service on Microsoft Azure ポッドのセルフサービス移行は段階的なロールアウトであり、 Horizon 移行チームによって順次行われます。該当する場合は、 Horizon Migration Communications から直接通信を受け取ります。

Horizon 移行チームから E メールが送信されない場合

「 移行における除外と特別なケースのシナリオ」で現在の資格基準を確認します。有効化の資格は、特定の要因に基づいています。これらの要因は時間の経過とともに展開し、段階的なロールアウトを行います。

表 1. 開始する

	現在の状況...	次に行うこと
☐	次世代への移行について Horizon 移行チームから E メールを受信したが... プロセスの概要が届いていない。 次世代への最初のオンボーディングを完了していない。	確認：Tech Zone ビデオ「Horizon Cloud Service first-gen to next-gen」 実行：このガイドに記載されている前提条件を満たす 実行：次世代環境で初期オンボーディングの準備ができていることを移行チームに確認し、最初のオンボーディング手順を完了する
☐	次世代への最初のオンボーディングを完了すると、移行ユーザー インターフェイスが表示されるが... 次世代の ID プロバイダを構成していない。 第 1 世代テナントと次世代をペアリングしていない。	次の Tech Zone ビデオの前半を確認：「Scheduling a Horizon Cloud on Microsoft Azure pod migration」。 実行：ID プロバイダを構成する。 実行：テナントをペアリングする。
☐	ID プロバイダを構成してペアリングしたが... ポッドのメンテナンス ウィンドウをまだスケジュール設定していない。	次の Tech Zone ビデオの後半を確認：「Scheduling a Horizon Cloud on Microsoft Azure pod migration」。 実行：メンテナンス ウィンドウをスケジュール設定する。
☐	メンテナンス ウィンドウをスケジュール設定した後、まだその日付が来ていない。	確認：プレビルドの段階で何が起きるかを確認する。 実行：新しい Unified Access Gateway インスタンスが次世代ユーザー インターフェイスに一覧表示されていることを確認したら、DNS レコードを構成する。 実行：プレビルドされたテスト プールを使用して動作を事前検証する。 第 1 世代のフローティング デスクトップ プールごとに、システムは Horizon Edge に 1 つのデスクトップのテスト プールを作成し、第 1 世代の対応するプールの構成をミラーリングします。これらのテスト プールを使用して、各フローティング デスクトップ プールが期待どおりに動作することを事前検証できます。
☐	移行のメンテナンス時間の直前からメンテナンス期間が終了するまでの間。	確認：メンテナンス ウィンドウで何が起きるかを確認する。
☐	メンテナンス期間の直後。	実行：移行後のアクティビティを実行する
☐	移行後のアクティビティを実行した後。	実行：移行をファイナライズする。 実行：App Volumes アプリケーション ストレージ アカウントのプライベート エンドポイント構成を確認し、必要に応じて構成する。 追加のポッドがある場合は、次のポッドの移行を計画する。

注： Horizon Cloud on Microsoft Azure デプロイおよび Horizon Cloud という用語は、第 1 世代の Horizon Cloud Service およびそのクラウド制御プレーンを指します。v1 や first-gen などのその他の用語は、 Horizon Cloud Service の第 1 世代を指します。次世代のサービスおよび制御プレーンには、正式な名称 Horizon Cloud Service - next-gen と省略語の next-gen が含まれます。

対応ブラウザ

次世代の Horizon Universal Console は、Google Chrome、Mozilla Firefox、Microsoft Edge、およびApple Safariの最新バージョン (N) および N-1 および N-2 バージョンと互換性があります。次世代の Horizon Universal Console を使用して実行される移行アクティビティは、これらのブラウザ バージョンを使用してサポートされます。

ペアリング キーの取得など、第 1 世代の Horizon Universal Console で実行される移行アクティビティについては、第 1 世代のデプロイ ガイドの説明に従って、第 1 世代の Horizon Universal Console と互換性のあるブラウザ バージョンを使用します。

フェーズ 1：Horizon Cloud Service - next-gen 環境への初期オンボーディング

このフェーズでは、次世代環境での最初のオンボーディング手順を完了します。これらの手順は、次世代環境で新しいグリーンフィールド デプロイを実行する場合の手順とほぼ同じです。

注： next-gen 環境にオンボーディングしたことがある場合は、このフェーズをスキップできます。最初のオンボーディングの完了後は、次世代コンソールにログインするときに、 [移行] ページがすぐに表示されなくても、左側のナビゲーションにあるコンソールの [移行] エントリをクリックしてページを表示できます。

VMware Horizon Cloud Service - next-gen のデプロイとオンボーディングページで説明されているオンボーディング手順を Horizon Cloud リージョンを選択する手順を介して実行します。

組織の選択

オンボーディング ワークフローの手順で、ユーザー インターフェイスに答える形で既存の組織を選択するか、新しい組織を作成して、組織を指定します。これは、「使用する Cloud Services 組織の決定」の説明に沿って行います。

クラウド リージョンの選択

組織の後に、リージョンを選択するユーザー インターフェイスが表示されます。

重要： この手順でリージョンを選択して保存すると、後で変更することはできません。

制御プレーンのメタデータが第 1 世代テナントで使用されていたのと同じ地理的リージョンに保持するには、第 1 世代テナントのリージョンに対応する地理的リージョンを選択します。

次のスクリーンショットは、[米国] を選択した場合のリージョン選択手順を示しています。

次世代のリージョンの選択は、第 1 世代テナントに使用したリージョンと一致させることができます。これにより、使用している第 1 世代の制御プレーン領域を特定できます。次世代のリージョンの選択を第 1 世代のテナントで使用したリージョンに一致させるには、第 1 世代の Horizon Universal Console にログインし、「Horizon Cloud テナント環境への認証について」で説明されている認証フローを完了して、ブラウザのアドレス フィールドに表示されるリージョンの DNS 名を調べます。

注： この表は、サポートされている第 1 世代のリージョンと、対応する next-gen のリージョンを一覧表示することを目的としています。時間の経過とともに、 Horizon Cloud Service - next-gen は追加のリージョンをサポートする場合があります。このようなリージョンは、対応する第 1 世代のリージョンを持たないため、この表には追加されません。

第 1 世代のリージョン名	対応する次世代リージョンの選択肢
cloud.horizon.vmware.com	米国
cloud-eu-central-1.horizon.vmware.com	アイルランド
cloud-ap-southeast-2.horizon.vmware.com	オーストラリア
cloud-us-2.horizon.vmware.com	米国
cloud-eu-2.horizon.vmware.com	アイルランド
cloud-ap-2.horizon.vmware.com	オーストラリア
cloud-jp.horizon.vmware.com	日本
cloud-uk.horizon.vmware.com	英国
cloud-de.horizon.vmware.com	ドイツ

リージョンの選択後

前の手順で保存したら、コンソールには通常、[移行] 画面が表示されます。

注： [移行] 画面が表示されない場合は、左側のナビゲーションの [移行] を使用して画面に移動できます。

次の手順

画面に表示される指示に従います。文書化された移行の前提条件を満たしてから、ペアリング プロセスを完了します。

フェーズ 2：環境をペアリングして、次世代環境と第 1 世代環境間の移行を有効にする

Horizon Cloud on Microsoft Azure デプロイの次世代環境への移行を有効にするには、第 1 世代環境と Horizon Cloud - next-gen 環境をペアリングする必要があります。

注： 次世代コンソールで手順を実行するには、次世代環境で Administrator ロールが必要です。 Horizon Cloud Service - next-gen ユーザー ガイドにある 管理ロールの割り当てに関するページを参照してください。

注意: 現時点では、第 1 世代のデプロイが VMware によって移行可能にされた場合のみ、移行のバナー、 [next-gen の移行] ウィザード、 [移行] メニュー、および [移行] ページがコンソールに表示されます。

このペアリング コードについて

ペアリング コードは、第 1 世代のデプロイを移行する目的で、Horizon Cloud - next-gen 環境を第 1 世代環境に関連付けるシステムの方法です。

第 1 世代環境からペアリング コードを取得し、そのペアリング コードをコピーして、Horizon Cloud - next-gen 環境の移行パネルに貼り付けます。

ペアリング手順

コンソールを使用してペアリング コードを生成するたびに、コードは 30 分間有効です。30 分経過するまでに手順 9 を完了しなかった場合は、手順 5 を繰り返して新しいコードを生成し、手順 9 でコピーして貼り付けます。

両方のコンソールを同時に表示する場合、ベスト プラクティスは、ブラウザ ウィンドウをプライベート モードまたはシークレット モードで使用して、イメージのブラウザ キャッシュまたはその他のキャッシュされたページ コンテンツによって生じる可能性のあるユーザー インターフェイスの問題を回避します。

1. 次のいずれかの方法を使用してペアリング コードを取得します。
   • コンソールに移行のバナーが表示されている場合は、バナーの [始めましょう] をクリックして [next-gen の移行] ウィザードを開始し、[使用開始] 手順で [はい] を選択して、次のスクリーンショットに示すようにペアリング コードを表示します。
     注： 第 1 世代コンソールには、VMware が第 1 世代環境で有効になっている場合にのみ、このバナーとウィザードが表示されます。
     
     
     
   • コンソールに表示されているアカウント名をクリックし、[ペアリング コード] を選択します。
     
     
2. ペアリング コードをコピーします。次のスクリーンショットは、プライバシーのために編集されたコードを示しています。
   
   

   このペアリング コードは 30 分間有効です。

   コードの有効期限が切れると、新しいコードを生成するための更新アクションがコンソールに表示されます。

3. Horizon Cloud - next-gen 環境の [移行] ページに移動します。
   • [移行 - 使用開始] ウィザードで [開始] をクリックし、次世代コンソールを起動して [移行] ページを表示します。
   • または、ブラウザ ウィンドウを開いて VMware Cloud Services にログインし、[サービス] ページから Workspace ONE サービスに移動し、Workspace ONE Cloud Services のセット内で Horizon Cloud Service カードを見つけて [アクション] をクリックし、そこから次世代コンソールを開きます。次に、左側のナビゲーション メニューの [移行] エントリを使用して、[移行] ページに移動します。
     
     
     
     

     次のスクリーンショットは、コンソールの [移行] ページを示しています。

   
   
   
4. [テナントのペアリング] リンクをクリックします。
5. 表示される [テナントのペアリング] ウィンドウで、コピーしたペアリング コードを [ペアリング コード] フィールドに貼り付けます。

   次のスクリーンショットは、この手順を示しています。貼り付けたコードはここでプライバシーのためにマスキング処理されています。

   
   
   
6. [ペア] をクリックします。

   システムがテナントを正常にペアリングすると、次世代ユーザー インターフェイスにペアリングが成功したことが示されます。

   
   
   

次の手順

第 1 世代テナントと次世代テナントがペアリングされたら、画面上のガイダンスに従って ID プロバイダを接続します。

フェーズ 3：次世代環境に必要な ID プロバイダ設定の構成

移行ワークフローのこのフェーズでは、外部 ID プロバイダの設定を入力する必要があります。これらの設定により、次世代環境で使用する ID プロバイダが登録されます。

簡単な紹介

次世代環境は、設計上、エンド ユーザーが資格のあるリソースにアクセスしようとするときに必要な認証の提供を外部 ID プロバイダに頼っています。

次世代アーキテクチャで外部 ID プロバイダを使用すると、サードパーティの製品やソリューションと統合して、多要素認証や SSO 機能を提供できます。

注目:

ID プロバイダを登録する前に、移行対象のポッドの Active Directory ドメインが、この次世代環境に指定する ID プロバイダに接続されていることを確認します。

ビデオ イラスト

次の Tech Zone ビデオでは、次世代環境でサポートされている ID プロバイダ タイプの 1 つを構成する方法について説明します。

• Microsoft Entra ID を使用したデモについては、Tech Zone「ポッドの移行スケジュールを設定する」の開始 3 分から始まる、Microsoft Entra ID を ID プロバイダとして構成する手順を確認してください。
• Workspace ONE Access を使用したデモについては、「演習：Horizon Cloud のユーザー ID プロバイダとして Workspace ONE Access を接続する」内のビデオを参照してください。

準備

Horizon Cloud - next-gen ガイドにある「ID プロバイダのセットアップ」の説明に従って、ID プロバイダが設定され、Active Directory ドメインに接続されていることを確認します。

次世代テナント コンソールのユーザー インターフェイスには、補助ドメイン参加アカウントの入力が必要です。これは、補助ドメイン参加アカウントがオプションだった第 1 世代テナント コンソールとは異なる点です。ユーザー インターフェイスでドメイン登録手順を開始する前に、補助ドメイン参加アカウントの名前があることを確認します。

ID プロバイダ接続の作成

次世代テナントのコンソールで、[移行] ページの [接続] をクリックして、コンソールの [ID プロバイダ] ユーザー インターフェイス タブに移動します。

コンソールの [ID プロバイダ] フローを完了して、次世代テナントを ID プロバイダに接続します。

この [ID プロバイダ] ユーザー インターフェイスに関する具体的なガイダンスについては、Horizon Cloud - next-gen ガイドにある「ID プロバイダの接続」ページを参照してください。

次のスクリーンショットは、ID プロバイダが正常に接続された完了状態を示しています（プライバシーのために一部の値がマスキング処理されています）。

次の手順

次世代コンソールで、[移行] ページに移動します。

ID プロバイダが接続されると、コンソールで [開始] ボタンが使用可能になり、これをクリックすることで、自動移行のスケジュール設定を開始できます。

フェーズ 4：ポッドの移行メンテナンス ウィンドウのスケジュール設定

このフェーズでは、移行するポッドを選択し、システムの Horizon Edge の構築に必要な詳細を指定し、移行メンテナンス ウィンドウを実行するカレンダー スロットを予約します。

このカレンダー スロットがメンテナンス ウィンドウです。

メンテナンス ウィンドウ中、ユーザーと他の管理者は第 1 世代のテナントの Horizon Universal Console にアクセスできません。また、エンド ユーザーは移行中のポッドによってプロビジョニングされたデスクトップおよびアプリケーションにアクセスできません。

これらの手順を開始する前に

コンソールでこのワークフローを開始する前に、次の項目を確認します。

☐	すべての前提条件を満たしていること
☐	どちらの Horizon Edge Gateway デプロイ タイプ（単一仮想マシンまたは AKS）を使用するかを決定していること：展開タイプを決定し、その要件を満たす。
☐	主な前提条件に加えて、選択した Horizon Edge Gateway デプロイ タイプの前提条件を満たしていること。 単一仮想マシン タイプの前提条件 AKS タイプの前提条件
☐	「フェーズ 3：次世代環境に必要な ID プロバイダ設定の構成」の手順を完了していること。
☐	タグとリソース グループの作成に関連する Azure ポリシーが解除されている（オフ）ことを確認し、Horizon Edge Gateway インスタンスと Unified Access Gateway インスタンスがポッドのサブスクリプションに正常にデプロイされていることを確認するまでオフのままにします。デプロイ アクティビティは、スケジュール設定ウィザードの完了後に開始されます。正常にデプロイされると、次世代 Horizon Universal Console に通知メッセージが表示されます。

重要： 前提条件を満たしていない場合、システムの事前検証チェックは失敗し、システムはプレビルド フェーズに入ることができません。これにより、移行プロセスがブロックされます。

スケジュール設定ウィザードのユーザー インターフェイスでは、次の項目の値を選択または入力する必要があります。

ウィザードを開始する前に、この情報と項目を確認してください。これらの項目はすべて、前提条件のページで説明されています。

☐	新しい Unified Access Gateway の項目： ウィザードのユーザー インターフェイスに入力する FQDN FQDN に一致する Unified Access Gateway 構成の SSL 証明書（PEM または PFX 形式） 重要： 証明書の共通名または FQDN が、ウィザードに入力する FQDN と正確に一致していることを確認します。ウィザードは、入力された FQDN を使用して証明書内のデータを検証します。一致しない場合、システムは移行のスケジュール設定を許可しないため、スケジュール設定ウィザードをキャンセルする必要があります。
☐ AKS デプロイ タイプを使用している場合	AKS タイプの場合、ウィザードは以下を要求します。 Horizon Edge の AKS クラスタの送信接続に使用される、管理サブネットに関連付けられた NAT ゲートウェイまたはルート テーブル ユーザーが割り当てた管理対象 ID Horizon Edge の AKS クラスタに使用する CIDR（サービス CIDR、ポッド CIDR） 注： AKS が制限された IP アドレスを回避するために、AKS タイプで使用する新しい VNet と管理サブネットを作成する必要がある場合は、ウィザードのユーザー インターフェイスで識別して選択できるように、それらの名前を確認してください。
☐ 単一仮想マシンのデプロイ タイプを使用している場合	単一仮想マシン タイプの場合、ウィザードは入力を要求しません。
☐ ポッドの外部ゲートウェイがプライベート IP アドレスを使用している場合	第 1 世代ポッドの外部ゲートウェイ デプロイがプライベート IP アドレスを使用するように構成されている場合は、「第 1 世代 Horizon Cloud ポッドを移行するための前提条件」の説明に従って、次世代の Unified Access Gateway デプロイに使用する新しいパブリック IP アドレスを設定します。 ウィザードがこの情報を要求します。

サイト関連のいくつかのポイント - Universal Broker 環境

複数の Horizon Cloud ポッドを持つ第一世代の Universal Broker 環境がある場合は、次の点に注意してください。

第 1 世代の管理ガイドの「Universal Broker 環境でのサイトの操作」ページで説明されているように、第 1 世代のテナントが Universal Broker を使用している場合、サイトとホーム サイトを構成できます。

• システムは、最初のポッドの移行中に第 1 世代テナントに存在するサイト構成を移行します。サイト関連情報の例として、ユーザーとホーム サイトのマッピングがあります。
• 最初のポッドの移行を完了し、その後、第 1 世代環境でサイト関連情報を変更すると、次のポッドの移行まで、これらの変更は次世代環境に表示されることはありません。
• 次世代環境内のサイトからユーザーおよびサイトからグループへの既存のマッピングは、ポッドが移行されるときの信頼できる情報源となります。ユーザーまたはグループのホーム サイト マッピングが次世代環境と第 1 世代環境の両方に存在する場合、移行プロセスは第 1 世代のサイト マッピングを無視します。この情報は、移行レポートに含まれています。
• 各ポッドの移行後、ホーム サイト マッピングがある場合は、次世代環境のホーム サイト マッピングを確認し、組織のニーズに応じて更新します。

移行のスケジュール設定ワークフローのユーザー インターフェイス

[移行] ページで [開始] をクリックして、[移行のスケジュール設定]ワークフローを確認します。

コンソールには、この次世代テナントとペアリングされた第 1 世代テナントのポッド フリート内にある第 1 世代の Horizon Cloud on Microsoft Azure デプロイのセットが表示されます。

システムは、第 1 世代のデプロイがセルフサービスの移行と互換性があることを自動的に検証します。この基準には、ポッド マネージャ インスタンスが適切なマニフェスト バージョンを実行していること、イメージ、VDI デスクトップおよびファーム仮想マシンに適切な Horizon Agent バージョンがあること、および第 1 世代のデプロイで使用される機能がセルフサービスの移行の現在の機能と互換性があることの検証が含まれます。

第 1 世代のデプロイごとに、コンソールは、デプロイが自動移行に関するシステムの基準を満たしているかどうかを示します。基準を満たしている場合、ユーザー インターフェイスには [移行の準備完了] と表示されます。

デプロイが条件を満たしていない場合は、ステータス列をクリックすると、問題を説明するウィンドウが表示されます。これらの項目に対処したら、[再スキャン] アクションを使用して、第 1 世代のデプロイのシステム チェックを再実行できます。デプロイが満たす必要がある基準の例については、移行における除外と特別なケースのシナリオを参照してください。

注： [再スキャン] アクションを使用しても、ページは自動的に更新されません。最新の状態を表示するには、 [更新] をクリックする必要があります。

第 1 世代ポッドの選択

移行するポッドを移行する準備ができていることがユーザー インターフェイスに示されている場合は、[次へ] をクリックします。

第 1 世代環境に複数のポッドがあり、内部専用ゲートウェイと外部ゲートウェイの組み合わせがある場合は、最初に外部ゲートウェイを持つポッドを移行します。

ポッドを選択したら、[次へ] をクリックして続行します。

Horizon Edge - 新規追加、既存のものを選択

[次へ] をクリックすると、システムは移行後のポッドを表す Horizon Edge の次世代環境で利用可能なものを分析します。

ウィザードに次のボタンが表示されます。

• [新規追加]
• [既存のものを選択]

灰色で表示されたボタンはこの移行に使用できないことを意味し、システムが選択したボタンを使用する必要があります。バナーに理由が表示されます。

どちらも灰色で表示されておらず、一方がデフォルトで選択されている場合、システムは事前に選択されているものの使用を推奨していますが、この移行ではシステムが推奨するボタンを上書きして別のボタンを選択できることを意味します。

次のセクションでは、[移行のスケジュール設定]フローにおける [新規追加] と [既存のものを選択] の目的について簡単に説明します。

ボタン - 既存のものを選択

[既存のものを選択] を選択すると、ウィザードに環境の既存の Horizon Edge のリストが表示されます。この移行に使用する Horizon Edge を選択し、[次へ] をクリックします。「手順 3 - 移行期間のスケジュール設定」に進みます。

既存の Horizon Edge を使用する場合、システムは、第 1 世代ポッドに関連付けられているのと同じ数の Unified Access Gateway インスタンスを使用して、既存の Unified Access Gateway デプロイをスケーリングします。このスケールの上限は 8 つの Unified Access Gateway インスタンスです。選択した Horizon Edge でこの上限に達すると、Unified Access Gateway デプロイは増加しません。

また、次の使用事例についても説明します。

• 第 1 世代ポッドには、選択した Horizon Edge と同じサブスクリプション、同じ Microsoft Azure リージョン、異なるアプリケーション ID（サービス プリンシパル）があります。システムは、第 1 世代ポッドのアプリケーション ID をそのプロバイダに追加することによって、選択された Horizon Edge のプロバイダをスケーリングします。
• 第 1 世代ポッドには、選択した Horizon Edge と異なるサブスクリプション、同じ Microsoft Azure リージョン、異なるアプリケーション ID（サービス プリンシパル）があります。システムは選択した Horizon Edge にセカンダリ プロバイダを追加します。

ボタン - 新規追加

[新規追加] を選択すると、システムはこの第 1 世代ポッドの移行用に新しい Horizon Edge を作成します。

この場合、ウィザードでは、新しい Horizon Edge を構成するために、表示されたオプションとフィールドに入力する必要があります。

ユーザー インターフェイス フィールド	説明
[Horizon Edge 名]	次世代テナント内でこの Horizon Edge を一意に識別する名前を指定します。名前は英字（a ～ Z）で始まり、英字、ハイフン (-)、および数字のみで構成する必要があります。
[デプロイ タイプ]	Horizon Edge Gateway に使用することを決定したデプロイ タイプに対応する選択肢をクリックします。 [単一の仮想マシン] がデフォルトです。 [単一の仮想マシン] - 単一の仮想マシン タイプをデプロイします。 [Azure Kubernetes サービス] - AKS タイプをデプロイします。

選択した [デプロイ タイプ] に対応する以下のセクションを参照してください。

単一仮想マシンのデプロイ タイプ

[単一の仮想マシン] のデプロイの場合、ウィザードにはその他の関連するフィールドはありません。このタイプのデプロイでは、Horizon Edge Gateway にポッドの管理サブネットを使用します。

Unified Access Gateway 情報の入力を続行します。

Azure Kubernetes サービスのデプロイ タイプ

フィールドの入力を完了します。これらはすべて必須です。ユーザー インターフェイスでは、[次へ] ボタンを有効にする前に、これらのすべてのエントリを検証します。

ユーザー インターフェイス フィールド	説明
[クラスタ送信タイプ]	[NAT ゲートウェイ] または [ユーザー定義ルート] の 2 つの選択肢があります。 「AKS タイプ - NAT ゲートウェイまたはルート テーブルの設定と管理サブネットへの関連付け」セクションの説明に従って、この要件を満たすためにユーザーまたはユーザーの IT チームが Azure で設定することを決定したものと一致する選択肢を選択してください。
[ユーザーが割り当てた管理対象 ID]	ユーザーまたはユーザーの IT チームがこの要件を満たすために Azure で設定したユーザー割り当ての管理対象 ID を選択します。詳細については、「AKS タイプ - ユーザーが割り当てた管理対象 ID の作成」セクションを参照してください。
[仮想ネットワーク] と [管理サブネット]	これらのフィールドの両方が表示される場合は、前提条件を処理するために準備した内容に従って選択を行います。 これらのフィールドは、「ポッドの VNet または接続されたネットワークに AKS 制限付き IP アドレスが含まれているかどうかの判断」で説明されているように、システムのチェックで VNet が AKS が制限された IP アドレス範囲と重複していると判断された場合に表示されます。 その VNet で新しい VNet と管理サブネットを選択します。
[サービス CIDR]	ユーザーまたはユーザーの IT チームが AKS のサービス CIDR 要件を満たすために決めた CIDR を入力します。詳細については、「AKS タイプ - 必要な仮想 IP アドレス範囲の予約」セクションを参照してください。
[ポッド CIDR]	ユーザーまたはユーザーの IT チームが AKS のポッド CIDR 要件を満たすために決めた CIDR を入力します。詳細については、「AKS タイプ - 必要な仮想 IP アドレス範囲の予約」セクションを参照してください。

Unified Access Gateway 情報

ユーザー インターフェイス フィールド	説明
[Unified Access Gateway の FQDN]	ユーザーまたは IT チームがこのデプロイに使用することを決定した Unified Access Gateway の FQDN を入力します。仮想デスクトップおよびアプリケーションの Horizon Agent は、この FQDN に接続します。
[証明書タイプ]	[PEM] または [PFX] の 2 つの選択肢があります。ユーザーまたはユーザーの IT チームがこのデプロイで取得した証明書と一致するタイプを選択します。これは、[Unified Access Gateway の FQDN] に一致します。 [PFX] の場合、PFX 証明書のパスワードを入力するための追加の [パスワード] フィールドが表示されます。
[証明書]	ボタンをクリックして、証明書をアップロードします。
[手動パブリック IP アドレス]	このフィールドは、第 1 世代ポッドの外部ゲートウェイのデプロイがプライベート IP アドレスを使用するように構成されていることをシステムが検出した場合に表示されます。 「第 1 世代 Horizon Cloud ポッドを移行するための前提条件」の説明に従って、次世代のデプロイに使用するパブリック IP アドレスを入力します。 注： ロールバックが必要な場合に第 1 世代のデプロイ状態へのロールバックをサポートするため、このパブリック IP アドレスは、移行対象の第 1 世代デプロイですでに使用されているパブリック IP アドレスとは異なる必要があります。 ビルド前のアクティビティの一環として、システムは、プライベート IP アドレスを使用して次世代 Unified Access Gateway デプロイのロード バランサをデプロイします。ロード バランサがデプロイされ、そのプライベート IP アドレスが認識されたら、このパブリック IP アドレスがトラフィックをデプロイされたロード バランサのプライベート IP アドレスに送信するようにルーティングを設定する必要があります。

すべてのフィールドにエントリがある場合は、[次へ] ボタンをクリックして次の手順に進みます。

手順 3：移行期間のスケジュール設定

この手順では、移行のメンテナンス ウィンドウの期間を選択します。

選択した期間内：

• 第 1 世代のポッド、そのリソース、設定などに変更を加えないでください。
• 次世代環境のデプロイに変更を加えないでください。
• システムは、Horizon Universal Console へのアクセスを禁止します。
• エンド ユーザーは、移行中のポッドによってプロビジョニングされたデスクトップおよびアプリケーションにアクセスできません。
• プロセスの中断を回避するため、選択した期間内に次世代環境にアクセスしないようにします。

ユーザー インターフェイスには、移行アクティビティで使用できる時間枠を示すカレンダー ビューが表示されます。

• カレンダー ビューには、選択した第 1 世代ポッドの移行に使用できる日と時間枠が正確に反映されます。
• 一般的に、選択できる最初の日は、少なくとも 7 日先になります。
• 必要に応じてこのカレンダー ビューをスクロールして、チームと組織のニーズに適した日と時間枠を見つけることができます。
• 各時間枠は 6 時間ブロックです。

次のスクリーンショットは、移行メンテナンス ウィンドウの選択に使用されるユーザー インターフェイス カレンダーを示しています。

時間ブロックの 1 つにカーソルを置くと、ブラウザのローカル時間と UTC の両方でその時間枠の時間を示すポップアップが表示されます。

次のスクリーンショットは、選択したブロックを示しています。システムは、この時間にアクティビティを開始します。

いずれかの時間枠を選択したら、[保存] をクリックして選択内容を保存します。

システムが次に行うこと

選択した時間枠を保存すると、選択した時間枠を確認し、次の手順を説明するメッセージが表示されます。

確認メッセージで [OK] をクリックすると、次の処理が実行されます。

1. ビルド前のアクティビティを実行します。

   [新規追加]（新しい Horizon Edge への移行）を使用する場合

   この場合、システムは Horizon Edge とそれに関連付けられたリソース(Horizon Edge Gateway および Unified Access Gateway インスタンスおよび関連するロード バランサ)をデプロイします。

   [既存のものを選択]（既存の Horizon Edge への移行）を使用する場合

   既存の Horizon Edge を使用する場合、システムは、第 1 世代ポッドに関連付けられているのと同じ数の Unified Access Gateway インスタンスを使用して、既存の Unified Access Gateway デプロイをスケーリングします。このスケールの上限は 8 つの Unified Access Gateway インスタンスです。選択した Horizon Edge でこの上限に達すると、Unified Access Gateway デプロイは増加しません。

   また、次の使用事例についても説明します。

   • 第 1 世代ポッドには、同じサブスクリプション、同じ Microsoft Azure リージョン、異なるサービス プリンシパルのアプリケーション ID があります。システムは、第 1 世代ポッドのアプリケーション ID をそのプロバイダに追加することによって、選択された Horizon Edge のプロバイダをスケーリングします。
   • 第 1 世代ポッドには、異なるサブスクリプション、同じ Microsoft Azure リージョン、異なるサービス プリンシパルのアプリケーション ID があります。システムは選択した Horizon Edge にセカンダリ プロバイダを追加します。

2. 第 1 世代ポッドから Horizon Edge に公開イメージとApp Volumes アプリケーションをコピーします。

展開された Horizon Edge には、Horizon Edge Gateway インスタンス用のロード バランサと、Unified Access Gateway インスタンス用のロード バランサがあります。

[新規追加] ユースケースでは、新しい Horizon Edge がデプロイされ、ユーザーとユーザーの IT チームがそれらのロード バランサの IP アドレスを取得できる場合、DNS を更新して、[Unified Access Gateway の FQDN] ロード バランサの IP アドレスをこの移行のスケジュール設定ウィザードで指定された [Unified Access Gateway の FQDN] にマッピングするレコードを追加する必要があります。詳細については、next-gen ドキュメントの「Horizon Edge Gateway および Unified Access Gateway のデプロイ後に必要な DNS レコードを構成する」を参照してください。

注： [手動パブリック IP アドレス] を入力した場合は、そのパブリック IP アドレスからデプロイ済みのロード バランサのプライベート IP アドレスに必要なルーティングを設定する必要があります。

確認メッセージで [OK] をクリックすると、コンソールの [移行] ページに戻ります。

次の手順

システムのプレビルド フェーズ中のほとんどの時間は、システムがプレビルド アクティビティを完了するのを待つことになります（移行フロー図を参照してください）。

プレビルド フェーズでは、コンソールの [移行] ページの [移行ステータス] および [レポート] 列を使用して、何が起きているかを確認できます。

ヒント: 移行で新しい Horizon Edge を追加する場合、VMwareは、Unified Access Gateway インスタンスとロード バランサがデプロイされていることを確認したら、必要な DNS エントリを構成することをお勧めします。

これらの DNS エントリはメンテナンス アクションの完了後に構成できますが、指定した FQDN をこれらのリソースに割り当てられた基盤となる IP アドレスにマッピングする DNS エントリがないと、移行された環境は完全には機能しません。フェーズ 6：セルフサービスの移行のフェーズ 5 で作成されたインフラストラクチャの DNS レコードの構成を参照してください。

重要： 第 1 世代テナントが Universal Broker 環境の場合は、第 1 世代テナントですでに設定されているユーザーおよびグループのサイト関連の構成を変更しないでください。

[移行] ページの機能

1 つのポッドの移行がスケジュール設定されたので、コンソールの [移行] ページにそのステータスが表示され、スケジュール設定された移行時間を再スケジュール設定（[再スケジュール]）およびキャンセル（[キャンセル]）するためのアクションが利用可能になります。

これらのアクションのいずれかを選択したら、画面のプロンプトに従います。

次のスクリーンショットは、選択したポッドおよび [再スケジュール] アクションと [キャンセル] アクションを実行できることを示しています。このポッドはまだ移行されていないため、このスクリーンショットの [ファイナライズ] アクションは使用できません。

フェーズ 5：プレビルド - メンテナンス ウィンドウ前の自動アクション

このフェーズでは、システムは指定された移行期間の前にプレビルド移行アクティビティを自動的に実行します。このアクティビティを前倒しで実行することで、移行のメンテナンス ウィンドウで必要な時間を最小限に抑えることを目指します。

簡単な紹介

予測されることで説明するように、このプレビルドを使用すると、メンテナンス ウィンドウ中に移行にかかる時間が短縮されます。

すべての移行で、システムはビルド前の段階で必要なリソースを展開します。

移行が新しい Horizon Edge を使用している場合、システムは事前ビルドの開始時に Horizon Edge のリソースもデプロイします。

注目: システムはこのプレビルド フェーズでリソースを作成するため、この間に Azure サブスクリプションと次世代環境に新しいリソースが表示される可能性があります。

次の点を認識しておく必要があります。

• 次世代コンソールは、これらのリソースを使用して次世代環境でプールを作成することを妨げませんが、移行全体が完了するまで、それらの新しいリソースを使用してプールを作成したり、他の作成ワークフローを実行したりしないことを強くお勧めします。

  これらのリソースが移行メンテナンス ウィンドウの前に次世代環境内で使用され、その後、移行をキャンセルするか、ユーザー インターフェイスのロールバック アクションを行った場合、システムは次世代環境を元の開始状態に戻すことができなくなります。このシナリオでは、環境で追加の手動アクションを実行して、システムが移行プロセスを再開できるようにする必要がある場合があります。

• プレビルド中、システムは最初に第 1 世代ポッドの base-vms リソース グループ内の各第 1 世代の公開イメージを一時的に複製し、これらの複製に対してエージェントの更新やその他のアクティビティを実行してから、次世代環境で公開します。これらの一時的な仮想マシンは、MIGXXXXXXXXXXXXxxx という命名規則を使用します。

  システムがこれらの一時的な仮想マシンを操作すると、次世代環境に公開されるまで、第 1 世代コンソールの [インポートされた仮想マシン] ページに MIGXXXXXXXXXXXX イメージが表示されます。

  移行のプレビルド フェーズが失敗する可能性があるため、これらの一時的な仮想マシンに対してアクションを実行しないようにすることが重要です。たとえば、一時的な仮想マシンをパワーオフしないようにします。

このプレビルドは、既存のポッドまたはユーザー セッションには影響しません。

重要： 第 1 世代テナントが Universal Broker 環境の場合は、第 1 世代テナントですでに設定されているユーザーおよびグループのサイト関連の構成を変更しないでください。

プレビルド中

ビルド前の実行中:

1. 移行で既存の Horizon Edge ではなく新しい Horizon Edge を使用する場合、システムは、フェーズ 4 の [移行のスケジュール設定] ユーザー インターフェイスで指定した入力を使用して、次世代の Horizon Edge をデプロイします。
2. システムは、ポッド レベルおよび第 1 世代制御プレーンに格納されている第 1 世代の構成データを取得し、次世代の制御プレーン設計に一致するようにデータを変換し、変換されたデータを適切に保存します。
3. この移行が次世代環境への最初の移行である場合、システムは第 1 世代テナントのActive Directory (AD) ドメイン構成を取得し、同等のドメイン構成を次世代環境に作成します。

   次世代環境では、システムは最初のスケジュール設定された移行のビルド前アクティビティ中に、第 1 世代テナントの登録済みドメインをすべて登録します。同じ第 1 世代テナントからの後続のポッド移行の場合、システムは第 1 世代のテナント構成が同期されていることを再検証し、次世代環境にすでに存在するドメインの登録をスキップします。

   注： 次世代環境では、次世代 Active Directory ドメイン構成で、ドメイン バインド アカウントとドメイン参加アカウントの両方に対する補助アカウントが必要です。第 1 世代テナントの Active Directory ドメイン構成に、補助ドメイン バインド アカウントまたは補助ドメイン参加アカウントがない場合、システムはプライマリ アカウント情報を次世代 Active Directory ドメイン構成のコンパニオン補助アカウントとして自動的に再利用します。

   ベスト プラクティスとして、これらの補助ドメイン バインド アカウントおよび補助ドメイン参加アカウントのサービス アカウントを Active Directory ドメイン内で取得し、プレビルド アクティビティの後で、これらの補助アカウントを追加するように Active Directory ドメイン構成を編集する必要があります。

4. システムは、第 1 世代のデプロイの公開イメージとApp Volumes関連ファイルを Horizon Edge にコピーし、Horizon Edge で使用するようにコピーを構成します。
5. 以下の第 1 世代のアイテムごとに、システムは Horizon Edge にテスト プールを作成します。
   • RDSH デスクトップ ファーム
   • RDSH アプリケーション サーバ ファーム
   • 単一ポッド ブローカ テナントからのフローティング デスクトップ割り当て（プール）。（マルチクラウド割り当てにはテスト プールはありません。）

   各テスト プールには 1 台のマシンが含まれており、対応する第 1 世代の仮想マシンからプールの構成設定をミラーリングします。

   これらのテスト プールを使用して、メンテナンス ウィンドウ中にプールが完全に移行される前に、ポッドのマシンが想定どおりに動作することを事前検証できます。

   注： システムはフローティングおよび RDSH プールを再構築するため、ライセンスが仮想マシンの ID に関連付けられている環境にサードパーティ製ソリューションのライセンスがある場合は、これらのライセンスの多くが消費される可能性があります。

プレビルド アクティビティはこの時点で終了します。システムは、次回のアクティビティをスケジュール設定されたメンテナンス期間の開始時に開始します。ロールバックのイベントに備えて、後でエンドツーエンドの移行が完了したことを確認するまで、第 1 世代のデプロイの公開されたイメージおよび App Volumes 関連ファイルはそのまま残ります。

次の手順

リソースがサブスクリプションに組み込まれた後、次のセクションで説明するアクティビティを実行してください。

新しい Horizon Edge に移行する場合は、必要な DNS エントリを構成します

新しい Horizon Edge の Unified Access Gateway インスタンスと Horizon Edge Gateway インスタンスが起動して実行されていることを確認したら、移行ユーザー インターフェイスで指定した FQDN を関連 IP アドレスにマッピングするレコードを使用して DNS を構成する必要があります。フェーズ 6：セルフサービスの移行のフェーズ 5 で作成されたインフラストラクチャの DNS レコードの構成を参照してください。

通常、これらのインスタンスは、スケジュール設定された移行メンテナンス ウィンドウから 48 時間以内に起動して実行されます。

テスト プールを使用したプールの動作の事前検証

Horizon Universal Console で [リソース] > [プール] の順に移動して、テスト プールを見つけます。

各テスト プールには、そのプールの次世代のエクスペリエンスの事前検証に使用する単一のマシンがあります。

Active Directory ドメイン - 補助ドメイン バインド アカウントおよびドメイン参加アカウント

前のセクションで説明したように、第 1 世代テナントの Active Directory ドメイン構成に、補助ドメイン バインド アカウントまたは補助ドメイン参加アカウントがない場合、システムはプライマリ アカウント情報を次世代 Active Directory ドメイン構成のコンパニオン補助アカウントとして自動的に再利用します。

ベスト プラクティスとして、これらの補助ドメイン バインド アカウントおよび補助ドメイン参加アカウントのサービス アカウントを Active Directory ドメイン内で取得し、プレビルド アクティビティの後で、補助アカウントを追加するように Active Directory ドメイン構成を編集する必要があります。次世代コンソールの [統合] ページ（[統合] > [管理] > [ドメイン]）でドメインを編集します。

フェーズ 6：セルフサービスの移行のフェーズ 5 で作成されたインフラストラクチャの DNS レコードの構成

このフェーズでは、ユーザーまたはユーザーの IT チームが、移行のスケジュール設定のユーザー インターフェイスで指定した FQDN を適切な IP アドレスにマッピングするレコードで DNS を更新します。

注： 既存の Horizon Edge を使用して移行している場合は、DNS レコードの構成のこの手順をスキップできます。

グリーンフィールドの Horizon Edge のデプロイの場合と同じように、DNS レコードを作成する必要があります。セルフサービスの移行では、ユーザーに代わってその更新を実行できません。

IP アドレスを FQDN にマッピングする DNS レコードは後で作成できますが、IP アドレスがインスタンスに割り当てられたらすぐにこれらのレコードを作成することをお勧めします。

すぐにでもマッピングを行う理由は、選択した FQDN をインスタンスの基盤となる IP アドレスにマッピングするレコードがないと、移行後の検証手順で次世代環境を完全に機能させることができないからです。

FQDN にマッピングする必要がある IP アドレスの詳細については、next-gen ドキュメントの「Horizon Edge Gateway および Unified Access Gateway のデプロイ後に必要な DNS レコードを構成する」ページを参照してください。

Horizon Universal Console では、FQDN と関連するロード バランサの IP アドレスが Horizon Edge の詳細ページに表示されます。コンソールの [キャパシティ] ページ（[リソース] > [キャパシティ] > [Horizon Edge]）から Horizon Edge の詳細を確認できます。

次の手順

スケジュール設定された移行メンテナンス ウィンドウの開始時間になると、システムは残りの移行アクティビティを開始します。

この移行ドキュメントでは、引き続きフェーズ 7：移行メンテナンス ウィンドウをお読みください。

フェーズ 7：移行メンテナンス ウィンドウ

スケジュール設定された移行期間の開始時間に、システムは最後の自動移行手順を自動的に開始します。この間、管理者およびエンド ユーザーは、第 1 世代テナントの管理コンソールおよびエンド ユーザーに資格のあるリソースにアクセスできなくなります。

移行の進行中は、コンソールの [移行] ページに移行中のポッドのステータスが表示されます。

制限されたアクティビティ

このメンテナンス ウィンドウ中：

• 第 1 世代ポッド、そのリソース、設定などに変更を加えないでください。
• 次世代のデプロイに変更を加えないでください。
• システムは、第 1 世代の Horizon Universal Console へのアクセスを禁止します。
• エンド ユーザーは、移行中のポッドによってプロビジョニングされたデスクトップおよびアプリケーションにアクセスできません。
• 選択した期間中は、次世代環境へのアクセスを控えてください。

この間、システムは第 1 世代のデプロイから次世代環境にリソースをアクティブに転送しているため、セルフサービスの移行には上記の制限が必要です。

システムの自動アクション

このメンテナンス ウィンドウ中に発生するアクティブな操作には以下のようなものがあります。

• 第 1 世代のデプロイのフローティング デスクトップ プールとファームをキャパシティを使用しなくなるまで縮小する。
• これに対応して、次世代環境でフローティング デスクトップ プールとファームを拡張して、第 1 世代のデプロイで使用していたキャパシティと一致させる。
• 第 1 世代のデプロイの専用デスクトップ プールからのデスクトップ仮想マシンを次世代環境とペアリングする。
  注： 専用デスクトップの移行アクションでは、時間が専用デスクトップ プールの電源管理スケジュール外であっても、必要に応じてデスクトップ仮想マシンの電源が自動的にオンになる場合があります。移行の一環として、デスクトップ仮想マシンの Horizon Agent は、第 1 世代のデプロイからペアリングを解除し、次世代環境とペアリングする必要があります。これには、仮想マシンの電源投入が必要な場合があります。

障害を検出すると、自動的にその時点までの変更を元に戻そうとします。元に戻すプロセスの詳細については、「移行のロールバック」のページを参照してください。

アクションが正常に完了し、メンテナンス ウィンドウの終了時間に達すると、コンソールの [移行] ページにポッドの 移行中 ステータスの変更が表示されます。

ヒント: ポッドの削除を確認するまで、ポッド マネージャ インスタンスと Unified Access Gateway インスタンスの第 1 世代のポッド インフラストラクチャがまだ存在するため、システムはこの状態を反映します。

専用デスクトップ仮想マシンに関する特別な注意事項

移行を完了しない限り、メンテナンスウィンドウの最後に次の手順を実行します。

• 専用デスクトップ仮想マシンの監視データは、Workspace ONE Intelligence に公開されません。
• 次世代コンソールを使用すると、専用デスクトップ プールまたは専用デスクトップ仮想マシンのエージェントを更新または再インストールできなくなります。

  移行が完了するまでエージェントの更新とエージェントの再インストールを防止する理由は、専用デスクトップのエージェントを変更すると、ロールバック時に問題が発生する可能性があるためです。next-gen 環境から第 1 世代のデプロイ状態への移行をロールバックしようとするときに、エージェントが次世代環境で変更された場合、ロールバックされた第 1 世代の展開で専用デスクトップが適切に動作しないことがあります。

移行の完了については、「移行のファイナライズ」 を参照してください。

移行後のアクティビティを実行して移行の成功を確認する

システムが移行メンテナンス ウィンドウでアクションを完了すると、すべてのリソースが次世代環境内に移行し、エンド ユーザーはデスクトップとアプリケーションにアクセスできるようになります。

この時点で、システムはメンテナンス ウィンドウに設定した制限を解除します。

• ユーザーとその他の管理者は、第 1 世代の Horizon Universal Console にアクセスできます。
• エンド ユーザーは、次世代環境によってプロビジョニングされたデスクトップとアプリケーションにアクセスできます。

重要： 次世代環境ではエンド ユーザー リソースへのアクセスに使用される URL またはサーバ アドレスが異なるため、Horizon Client および Horizon HTML Access Client（ブラウザ）の使用時に使用する新しいアドレスをエンド ユーザーに通知する必要があります。next-gen ドキュメントの デスクトップの起動ページを参照してください。

移行が完了するまで以下のアクティビティを実行しない

一部のアクティビティは移行を完了する前に許可されますが、実行すると問題が発生する可能性があります。

移行が完了するまで、移行されたサイトの名前を変更しないでください。

移行フローを終了する前にサイトの名前を変更しないでください。次世代環境から第 1 世代テナントに移行をロールバックし、移行されたサイト名が次世代環境で変更されている場合は、そのロールバックされたポッドが後で移行されて移行が最終的に完了すると、次世代環境には以前の移行による元の第 1 世代サイト名（現在は空になっています）と、名前が変更されたときの新しいサイト名の両方のサイト名が表示されます。このシナリオが発生した場合は、空の元の第 1 世代サイト名を次世代環境から削除します。

推奨されるアクティビティと注意事項

次世代環境が組織のビジネスの観点から機能するようにするには、ユーザーと VDI 管理者が以降のセクションで説明するアクティビティを完了する必要があります。

以降のセクションでは、移行されたデプロイの特性についても説明します。これらの特性を確認し、移行後の次世代環境で注意すべきことを理解します。

移行レポートのダウンロードと確認

移行後に、移行レポートをダウンロードして確認します。

移行レポートは、コンソールの [移行] ページの [レポート] 列から使用できます。

この移行レポートは、移行されたリソースと、移行プロセスで変更が行われた場所に関する詳細を提供します。

よくある変更には、リソースの名前の変更があります。第 1 世代のデプロイのリソースが、同じ名前がすでに使用されている次世代環境に移行する場合、移行によってリソースの名前が変更されることがあります。このような場合、セルフサービスの移行では、名前の競合を回避するために、これらの第 1 世代のリソースの名前を自動的に変更します。

エンド ユーザーのエクスペリエンスの確認

エンド ユーザーが資格に応じてフローティング デスクトップ、専用デスクトップ、およびリモート アプリケーションを起動できることを確認します。

ヒント: エンドユーザー エクスペリエンスのビデオ イラストについては、「 Horizon Cloud - 次世代デスクトップまたはアプリケーションにエンドユーザーとしてログインする」にある Tech Zone ビデオを参照してください。

次世代環境でデスクトップとアプリケーションを起動するエンド ユーザー エクスペリエンスについては、『VMware Horizon Cloud Service - next-gen の使用』ガイドの説明を参照してください。

• ブラウザ：Horizon HTML Access を使用したデスクトップの起動、Horizon HTML Access を使用したアプリケーションの起動
• ネイティブ Horizon Client：VMware Horizon Client を使用したデスクトップの起動。VMware Horizon Client を使用したアプリケーションの起動

次世代環境の開始アドレスは cloud.vmwarehorizon.com です。

認証フローも異なります。次世代環境では、エンド ユーザーは、第 1 世代のデプロイで使用される Active Directory ドメイン ログイン ワークフローではなく、構成された ID プロバイダを使用してログインする必要があるためです。

注意: 移行における除外と特別なケースのシナリオで説明されているように、各デスクトップの Horizon Client で設定されたエンドユーザーのデスクトップ環境設定の移行は、現在、このセルフサービスの移行ではサポートされていません。移行後、エンド ユーザーは必要に応じてクライアントで必要な環境設定を再度選択できます。

管理者のログイン エクスペリエンスの確認

次世代コンソールにログインしている管理者が移行された第 1 世代のデプロイから想定されるプールやその他のリソースを確認できることを確認します。

Horizon Universal Console への管理アクセスは、Workspace ONE Admin Hub を介して行います。

1. https://console.cloud.vmware.com/ (VMware Cloud Services) を使用してログインし、[マイ サービス] に移動して [Workspace ONE] カードを見つけます。
   
   
2. そのサービスを起動して、Horizon Cloud Service カードが存在する Workspace ONE Admin Hub を開きます。そのカードの [管理] をクリックして、Horizon Universal Console を起動します。

ポッドの VDI デスクトップ割り当ておよびファームからの仮想マシンの最小数の設定

移行プロセスは、第 1 世代の VDI デスクトップ割り当てとファームが、次世代環境の同等のエンティティで同等の電源管理設定を持つよう設計されています。

第 1 世代の VDI デスクトップ割り当ておよびファームと同等の次世代エンティティは、プールとプール グループです。次世代環境では、電源管理設定はプール グループ レベルで行われます。プール グループの電源管理設定では、[仮想マシンの最小数] は、プール グループ内の仮想マシンの合計に対してパワーオン状態を維持する仮想マシンの割合に基づいています。第 1 世代の環境では、[仮想マシンの最小数] という名前の設定は、VDI デスクトップ割り当てまたはファームで必要な仮想マシンの最小数を直接表しています。

移行後、first-gen の割り当てとファームの移行からシステムが作成したプール グループを編集すると、コンソールにこれらのプール グループの [仮想マシンの最小数] 設定が first-gen の [仮想マシンの最小数] の値から変換されたパーセンテージとして表示されます。この機能は、変換されたパーセンテージに基づく [仮想マシンの最小数] の値に準拠し続けます。

Active Directory ドメインの構成

次世代環境では、次世代 Active Directory ドメイン構成で、ドメイン バインド アカウントとドメイン参加アカウントの両方に対する補助アカウントが必要です。

プレビルド アクティビティ中、第 1 世代テナントの Active Directory ドメイン構成に、補助ドメイン バインド アカウントまたは補助ドメイン参加アカウントがない場合、システムはプライマリ アカウント情報を次世代 Active Directory ドメイン構成のコンパニオン補助アカウントとして自動的に再利用します。

このシナリオでは、移行後にこれらの補助ドメイン バインド アカウントおよび補助ドメイン参加アカウントのサービス アカウントを Active Directory ドメイン内で取得し、補助アカウントを追加するように Active Directory ドメイン構成を編集する必要があります。次世代コンソールで、[統合] > [管理] > [ドメイン] に移動してドメインを編集します。

注目: 最初のポッドの移行中に、システムによって第 1 世代テナントの Active Directory ドメイン構成が次世代環境に移行されたら、第 1 世代環境と次世代環境の両方で、構成されたドメインの属性の変更を管理する必要があります。システムは、一方の環境で行った変更を他の環境に自動的に伝達しません。たとえば、第 1 世代テナントのドメイン バインド アカウントのパスワードを更新する場合は、ペアの next-gen 環境で同じ更新を実行する必要があります。

サイト関連の設定 - マルチクラウド割り当て

第 1 世代環境にマルチクラウド割り当てがある場合は、移行後に次のアクションを実行します。

ホーム サイトのマッピングの確認

各ポッドの移行後、ホーム サイト マッピングがある場合は、次世代環境のホーム サイト マッピングを確認し、組織のニーズに応じて更新します。

マルチクラウド割り当ての移行から作成されたプール グループのサイト関連の設定を確認します

移行プロセスでは、第 1 世代マルチクラウド割り当ての移行から次世代プール グループへの移行から作成されたプール グループの設定の一部がデフォルトで設定されます。これらのデフォルトは、移行ウィンドウの終了時にエンド ユーザーがデスクトップにアクセスできるようにするために選択されます。

移行後は、これらの設定を注意して確認し、デフォルトが要件を満たしていることを確認するか、組織のユースケースに合わせて必要に応じて調整する必要があります。これらの設定は、プール グループの設定内にあります。

• [範囲] 設定はデフォルトで [任意のサイト] に設定されており、ホーム サイトを必要とする設定はオフになっています。
• 第 1 世代の割り当てからのホーム サイトのオーバーライドは、プール グループに移行されません。

App Volumes

移行後：

App Volumes：アプリケーションの一括資格

next-gen アーキテクチャでは、システムは first-gen アーキテクチャとは異なる方法で資格を管理します。移行プロセス中に、システムは移行された first-gen 展開にあった一括アプリケーション資格の解決を処理します。この解決により、一括ライセンスが次世代環境の資格の管理に適した形式に確実に移行されます。エンド ユーザーは、第 1 世代環境で使用資格が付与されたのと同じ一連の App Volumes アプリケーションに引き続きアクセスできます。

App Volumes：ポッドの移行

一定の期間にわたって Horizon Cloud ポッドを継続的に移行する際、システムは、first-gen ポッドから次世代環境へのすべての App Volumes エンティティを処理します。

たとえば、この Notepad++ アプリケーションが第 1 世代のポッドを使用する App Volumes アプリケーションとして、pod-1 と pod-2 の両方で使用されているとします。アプリケーションには複数のバージョンがあり、pod-1 には npp v7.8.1、pod-1 と pod-2 の両方に npp v7.8.2、pod-2 に npp v7.8.3 があります。

ポッド 1 の移行のプレビルド中に、システムは App Volumes アプリケーション Notepad++ と npp v7.8.1 および npp v7.8.2 を次世代環境にコピーします。これらは、pod-1 で使用される 2 つのバージョンです。もう 1 つのポッド (pod-2) は、この時点でまだ移行されていません。

この時点では両方の環境があり、次世代環境と第 1 世代環境の両方で App Volumes エンティティに変更を加えたいと考えています。これらのエンティティの場合、移行中、システムは第 1 世代環境にすでにコピーされたものを削除しません。第 1 世代環境と次世代環境の間で App Volumes エンティティに競合がある場合は、次世代環境に存在するエンティティが優先されます。

つまり、第 1 世代環境では、移行前に pod-2 のパッケージ npp v7.8.2 を削除し、新しいパッケージnpp v7.8.4を追加します。次に、pod-2 の移行をスケジュール設定すると、システムは現在 pod-2（npp v7.8.3 および npp v7.8.4）で使用されているパッケージを次世代環境にコピーします。pod-1 の移行中にそこでコピーされた次世代環境の npp v7.8.2 パッケージは、npp v7.8.2 が第 1 世代環境から削除された場合でも、次世代環境に残ります。

第 1 世代アプリケーション ファームからのリモート アプリケーション

この第 1 世代のドキュメントで説明するように、リモート アプリケーションは、第 1 世代ポッドのアプリケーション ファームによって提供されます。次世代の Horizon Universal Console には新しい用語があり、ラベルにはその用語が反映されています。

移行後：

• 1 対 1 のマッピングは、第 1 世代のアプリケーション ファームと、生成されたプールの間で next-gen に保持されます。
• 移行されたファームごとに、ファームの名前を使用してプールが作成されます。
• 移行プロセスでは、プールの名前を使用してプールごとにプール グループも作成されます。これは、移行の場合は元のファームの名前でもあります。
• 各プール グループには、そのプール グループのプールに関連付けられているアプリケーションに応じて、第 1 世代アプリケーション割り当てから移行されたユーザー資格に関する情報が表示されます。
• 第 1 世代アプリケーションの割り当て名は、次世代コンソールに表示されません。第 1 世代アプリケーション割り当てに複数のファームからのリモート アプリケーションが含まれている場合、次世代コンソール内でリモート アプリケーションとエンド ユーザー資格を表示するには、ファーム名で作成された各プール グループを表示するか、コンソールの [デスクトップとアプリケーション カタログ] > [公開アプリケーション] を使用します。
  注： 第 1 世代のファーム仮想マシンに手動アプリケーションを直接インストールした場合、移行プロセスの一環としてメタデータが移行されても、そのようなアプリケーションはデフォルトで次世代環境のプール仮想マシンにインストールされません。このようなアプリケーションの場合は、第 1 世代のファーム仮想マシンにインストールされた特定の正確なパスで、プール仮想マシンに再インストールする必要があります。

次を考慮します。

• 第 1 世代アプリケーション割り当て Assign-1 には、ファーム Farm-1 のアプリケーション app1、app2 があり、ユーザー User-1 には app1 および app2 の使用資格が付与されます。
• 第 1 世代アプリケーション割り当て Assign-2 には、Farm-1 のアプリケーション app1、およびファーム Farm-2 の app3 があり、ユーザー User-2 には app1 および app3 の使用資格が付与されます。
• つまり、app1 には User-1 と User-2 の両方の使用資格が付与され、app2 には User-1 のみ、app3 には User-2 のみの使用資格が付与されます。

next-gen への移行後:

• Farm-1 という名前のプールと、そのプール用に作成された Farm-1 という名前のプール グループが表示されます。そのプール グループには、アプリケーション app1 および app2（その第 1 世代ファームのアプリケーション）が表示されます。
• また、Farm-2 という名前のプールと、そのプール用に作成された Farm-2 という名前のプール グループが表示されます。そのプール グループには、アプリケーション app3 が表示されます。
• 移行された資格は次のとおりです。
  • User-1 および User-2 の使用資格が付与されたプール グループ Farm-1 からの app1
  • User-1 の使用資格が付与されたプール グループ Farm-1 からの app2
  • User-2 の使用資格が付与されたプール グループ Farm-2 からの app3

移行後のアクティビティ - ファイナライズ

次世代環境が問題なく動作していることを確認したら、最後の移行後のアクションとして移行をファイナライズします。

ファイナライズ中に、第 1 世代ポッドが Azure サブスクリプションから使用している Azure リソースが削除されます。

ヒント: 次世代の Horizon Edge のリソースと第 1 世代ポッドのリソースの両方を並行して実行するコストを回避するには、できるだけ早く移行をファイナライズする必要があります。ファイナライズを実行すると、第 1 世代ポッドがまだ使用している Azure リソースが削除されるため、コストが削減されます。

ポッドが移行されると、Horizon Universal Console にログインするたびに、そのポッドの移行のファイナライズを求めるプロンプトがユーザー インターフェイスに表示されます。

移行のファイナライズ

移行のファイナライズは、第 1 世代の Horizon Cloud on Microsoft Azure ポッドを移行する最後の手順です。

ファイナライズのメリット

ファイナライズすると、

• 第 1 世代ポッドによって Azure で消費された残りのリソースが削除されるため、追加の Microsoft Azure コストを回避できます。
• システムは、メンテナンスウィンドウの開始時に専用デスクトップに配置された制限を解除します。
  • 専用デスクトップ仮想マシンの監視データが Workspace ONE Intelligence への公開を開始します。
  • 専用プールおよび仮想マシンでエージェントの更新およびエージェントの再インストール操作を実行できます。
• 第 1 世代ポッドへのロールバックに影響を与えることなく、移行されたイメージとプールを安全に更新できます。

終了すると、移行を next-gen 環境から第 1 世代のデプロイ状態にロールバックすることはできません。

ファイナライズ前 - 推奨される移行後のアクティビティを実行する

ファイナライズの前に、推奨される移行後のアクティビティが完了していることを確認する必要があります。これらのアクティビティについては、「移行後のアクティビティを実行して移行の成功を確認する」ページで説明します。

ベスト プラクティス - 移行後数日以内にファイナライズする

次の要因があるため、移行プロセスが完了してから数日以内に各ポッドの移行を完了することをお勧めします。

• 移行を終了して第 1 世代ポッドが削除されるまでは、ポッド マネージャ インスタンスや Unified Access Gateway インスタンスを含む第 1 世代リソースを実行するための Microsoft Azure サブスクリプション コストが発生します。
• 移行が完了するまで、次世代 Horizon Universal Console では、専用プール グループでエージェントの更新操作を使用したり、専用仮想マシンでエージェントの再インストールを使用したりできなくなります（[エージェント] > [エージェントの更新] または [エージェント] > [再インストール]）。
  注目: 次世代環境で移行が完了していない場合、コンソールでは、第 1 世代から移行されたものであるか、次世代環境で新しく作成されたものであるかに関係なく、すべての専用プール グループおよび専用仮想マシンに対するエージェントの更新およびエージェントの再インストール操作を実行できません。このシナリオでは、移行を完了する必要についてのガイダンス メッセージがコンソールに表示されます。

  移行が完了するまでエージェントの更新とエージェントの再インストールを防止する理由は、デスクトップ内のエージェントに変更を加えると、ロールバック時に問題が発生する可能性があるためです。次世代環境から第 1 世代のデプロイ状態への移行をロールバックしようとするときに、エージェントが次世代環境で変更された場合、ロールバックされた第 1 世代の展開でデスクトップが適切に動作しないことがあります。

• 時間が経過し、ユーザーと VDI 管理者が次世代環境で変更を加えると、移行された環境をエンド ユーザーを満足させる第一世代の展開状態にロールバックする機能が低下します。たとえば、次世代環境で専用デスクトップ プールを拡張し、エンド ユーザーを新しいデスクトップに割り当ててから、第 1 世代ポッドにロールバックしようとすると、第 1 世代側の新しいデスクトップで問題が発生することがあります。

ファイナライズの手順

次世代コンソールの [移行] ページで [ファイナライズ] アクションを使用して移行を完了します。

[ファイナライズ] をクリックすると、ソースの第 1 世代ポッドの削除を承認するための承認ウィンドウがコンソールに表示されます。

移行プロセスを完了し、第 1 世代のポッドを削除できることをシステムに確認するには、[承認] をクリックします。

ファイナライズ後 - App Volumes アプリケーション ストレージ アカウントのプライベート エンドポイントのステータスを確認し、必要に応じて構成します

終了したら、App Volumes アプリケーション ストレージ アカウントに Microsoft Azure プライベート エンドポイントを構成することを強くお勧めします。Horizon Edge 用にまだ構成されていない場合は、このエンドポイントを使用することをお勧めします。

移行された環境はこのプライベート エンドポイント構成なしで動作しますが、プライベート エンドポイントを構成すると、このストレージ アカウントのセキュリティがさらに強化されます。本書の執筆時点では、移行プロセスで新しい Horizon Edge がデプロイされると、このストレージ アカウントのデフォルト構成では、すべてのネットワークからパブリック ネットワーク アクセスが有効になります。（このデフォルトは、第 1 世代ポッドの設定とは異なります）。

次世代 Horizon Universal Console のステータスを確認するには、Horizon Edge の詳細に移動し、[App Volumes アプリケーション ストレージ] セクションを見つけます。

[構成されていません] と表示されてい場合は、次世代使用ガイドの次の場所に記載されているガイダンスに従ってください。

• 「App Volumes アプリケーション ストレージ アカウントの Azure プライベート エンドポイント」ページ
• 「デプロイされた Horizon Edge の表示」ページの「App Volumes アプリケーション ストレージ アカウントのプライベート エンドポイントの構成」セクション内の手順。

例として、次のスクリーンショットは、単一のストレージ アカウントと、プライベート エンドポイントが構成されているかどうかを確認できるユーザー インターフェイスを示しています。この場合、プライベート エンドポイントはこのストレージ アカウント用にまだ構成されていません。

次のスクリーンショットは、プライベート エンドポイントを構成するためのメニューの場所を示しています。構成の選択をクリックすると、画面上のガイダンスに従います。手順は、「App Volumes アプリケーション ストレージ アカウントのプライベート エンドポイントの構成」に記載されています。

注： 必要に応じて、プライベート エンドポイントで Horizon Edge Gateway の管理サブネットとは異なるサブネットを使用し、必要に応じて別の VNet で使用することができます。その場合は、プライベート エンドポン用に選択した VNet と、Edge Gateway の管理サブネットを持つ VNet とデスクトップ プールのサブネットの VNet 間でネットワーク ピアリングが確立されていることを確認する必要があります(これらのサブネットが Edge Gateway の管理サブネットと異なる VNet にある場合)。詳細については、 「App Volumes アプリケーション ストレージ アカウントの Azure プライベート エンドポイント」ページを参照してください。

次のスクリーンショットは、プライベート エンドポイントが構成されている場合を示しています。

ポッドの移行の完了

完了した移行は正常な移行です。おめでとうございます。

Day-2 操作の詳細については、『VMware Horizon Cloud Service - next-gen の使用』ガイドを参照してください。

注意: [スケジュール設定] ページの サイト関連情報のセクションで説明したように、第 1 世代テナントですでに設定されているユーザーおよびグループのサイト関連の構成は変更しないでください。最初のポッドの移行を完了し、その後、第 1 世代環境でサイト関連情報を変更すると、次のポッドの移行まで、これらの変更は次世代環境に表示されることはありません。