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

Horizon Cloud 環境が有効になっている場合は、第 1 世代の Horizon Cloud Control Plane にある Horizon Cloud on Microsoft Azure デプロイから Horizon Cloud へのセルフサービス移行を開始できます。

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

はじめに

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

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

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

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

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

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

対応ブラウザ

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

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

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

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

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

「Horizon Cloud のオンボーディング」ページで説明されているオンボーディング手順を、Horizon Cloud リージョンを選択する手順を介して実行します。

組織の選択

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

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

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

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

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

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

Horizon Cloud リージョンの選択は、第 1 世代テナントに使用したリージョンと一致させることができます。これにより、使用している第 1 世代の制御プレーン領域を特定できます。

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

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

第 1 世代のリージョン名の先頭文字列	一致する Horizon Cloud リージョンの選択
cloud.horizon. または cloud-us-2.horizon.	米国
cloud-eu-central-1.horizon. または cloud-eu-2.horizon.	アイルランド
cloud-ap-southeast-2.horizon. または cloud-ap-2.horizon.	オーストラリア
cloud-jp.horizon.	日本
cloud-uk.horizon.	英国

リージョンの選択後

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

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

次の手順

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

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

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

**注：**Horizon Universal Console で手順を実行するには、Horizon Cloud 環境で Administrator ロールが必要です。Horizon Cloud ユーザー ガイドにある「管理ロールの割り当て」ページを参照してください。

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

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

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

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

ペアリング手順

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

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

1. 次のいずれかの方法を使用してペアリング コードを取得します。

   • コンソールに移行のバナーが表示されている場合は、バナーの [始めましょう] をクリックして [Horizon Cloud の移行] ウィザードを開始し、[使用開始] 手順で [はい] を選択して、次のスクリーンショットに示すようにペアリング コードを表示します。

     **注：**第 1 世代コンソールには、Horizon 移行チームが第 1 世代環境で有効にしている場合にのみ、このバナーとウィザードが表示されます。

     

   • コンソールに表示されているアカウント名をクリックし、[ペアリング コード] を選択します。

     

2. ペアリング コードをコピーします。次のスクリーンショットは、プライバシーのために編集されたコードを示しています。

   

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

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

3. Horizon Cloud 環境の [移行] ページに移動します。

   • [移行 - 使用開始] ウィザードで [開始] をクリックし、Horizon Cloud Console を起動して [移行] ページを表示します。

   • または、ブラウザ ウィンドウを開いてクラウド サービスにログインし、[Workspace ONE Cloud] タイルに移動し、設定されたサービス内でカードを見つけて [アクション] をクリックし、そこから Horizon Cloud Console を開きます。次に、左側のナビゲーション メニューの [移行] エントリを使用して、[移行] ページに移動します。

     

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

   

4. [テナントのペアリング] リンクをクリックします。

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

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

   

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

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

   

次の手順

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

フェーズ 3：Horizon Cloud 環境に必要な ID プロバイダ設定を構成する

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

簡単な紹介

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

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

注意：

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

準備

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

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

ID プロバイダ接続の作成

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

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

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

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

次の手順

Horizon Cloud Console で、[移行] ページに移動します。

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

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

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

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

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

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

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

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

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

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

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

☐	新しい Unified Access Gateway の項目： ウィザードのユーザー インターフェイスに入力する FQDN FQDN に一致する Unified Access Gateway 構成の SSL 証明書（PEM または PFX 形式） 重要： 証明書の共通名または FQDN が、ウィザードに入力する FQDN と正確に一致していることを確認します。ウィザードは、入力された FQDN を使用して証明書内のデータを検証します。一致しない場合、システムは移行のスケジュール設定を許可しないため、スケジュール設定ウィザードをキャンセルする必要があります。 第 1 世代ポッドに外部 Unified Access Gateway 構成と内部 Unified Access Gateway 構成の両方がある場合、移行後の Edge の Unified Access Gateway では外部 FQDN と内部 FQDN の両方がデフォルトで同じ FQDN（ここのウィザードに入力した FQDN）に設定されます。内部 FQDN を外部 FQDN とは別の値に設定する場合は、移行後に Edge の Unified Access Gateway の詳細を編集して内部 FQDN を別の FQDN に変更し、内部ユーザーを識別するためのネットワーク範囲を指定します。注：内部 FQDN を外部 FQDN とは別の値に設定する場合は、このスケジュール設定ウィザードで指定する SSL 証明書の証明書データに、予定している内部 FQDN が反映されていることを確認してください。それ以外の場合は、Edge の詳細を編集して一意の内部 FQDN を指定するときに、両方の FQDN を反映した証明書が必要になります。現時点では、ユーザー インターフェイスは単一の証明書を取得します。
☐ AKS デプロイ タイプを使用している場合	AKS タイプの場合、ウィザードは以下を要求します。 Horizon Edge の AKS クラスタの送信接続に使用される、管理サブネットに関連付けられた NAT ゲートウェイまたはルート テーブル ユーザーが割り当てた管理対象 ID Horizon Edge の AKS クラスタに使用する CIDR（サービス CIDR、ポッド CIDR） 注：AKS が制限された IP アドレスを回避するために、AKS タイプで使用する新しい VNet と管理サブネットを作成する必要がある場合は、ウィザードのユーザー インターフェイスで識別して選択できるように、それらの名前を確認してください。
☐ 単一仮想マシン デプロイ タイプを使用している場合	単一仮想マシン タイプの場合、ウィザードには単一仮想マシン デプロイ タイプに固有の必須の入力がありません。まれに、一部のシステム デフォルトと重複するネットワーク セグメントにすでにプロビジョニングされている Active Directory サーバのようなものがネットワークにある場合は、カスタム値を指定して、システムが設定したデフォルト値を置き換えることができます。詳細については、「単一仮想マシンのデプロイ タイプ」セクションを参照してください。
☐ ポッドの外部ゲートウェイがプライベート IP アドレスを使用している場合	第 1 世代ポッドの外部ゲートウェイ デプロイがプライベート IP アドレスを使用するように構成されている場合は、「第 1 世代 Horizon Cloud ポッドを移行するための前提条件」の説明に従って、Horizon Cloud Unified Access Gateway デプロイに使用する新しいパブリック IP アドレスを設定します。ウィザードがこの情報を要求します。

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

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

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

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

複数のポッドを含む割り当てがある場合

複数のポッドを含む第 1 世代の割り当てがある場合があります（第 1 世代のドキュメントでは、このような割り当てに「マルチクラウド割り当て」という用語を使用しています）。マルチクラウド割り当てに含まれるポッドを移行する場合は、注意が必要な重要事項があります。「第 1 世代の割り当てに複数のポッドがある場合：重要なポイント」を参照してください。

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

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

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

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

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

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

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

第 1 世代ポッドの選択

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

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

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

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

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

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

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

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

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

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

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

[既存のものを選択] を選択すると、ウィザードに環境の既存の 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 リージョン、異なる app ID（サービス プリンシパル）があります。システムは、第 1 世代ポッドのアプリケーション ID を選択された Horizon Edge のプロバイダに追加することによって、そのプロバイダをスケーリングします。
• 第 1 世代ポッドには、選択した Horizon Edge と異なるサブスクリプション、同じ Microsoft Azure リージョン、異なる app ID（サービス プリンシパル）があります。システムは、選択した Horizon Edge にセカンダリ プロバイダを追加します。

ボタン - 新規追加

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

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

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

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

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

[単一の仮想マシン] デプロイでは、次の「注」で説明するまれなシナリオを除き、必須フィールドはありません。このデプロイでは、Horizon Edge Gateway にポッドの管理サブネットを使用します。

**注：**まれなシナリオとして、ネットワーク セグメント上にすでにプロビジョニング済みの Active Directory サーバがあり、その IP アドレス空間がシステムのデフォルトと重複している場合があります。この場合、Edge Gateway モジュールが Active Directory に到達しようと試みるため、ネットワークの問題が発生する可能性があります。このような競合を回避するために、ウィザードの [詳細] セクションには、カスタム値を指定し、システムのデフォルトの内部ネットワーク範囲との競合を回避するためのフィールドが用意されています。詳細については、「オプションの詳細設定」を参照してください。

次は、Unified Access Gateway 情報です。

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

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

ユーザー インターフェイス フィールド	説明
クラスタ送信タイプ	NAT ゲートウェイ または ユーザー定義ルート の 2 つの選択肢があります。 ユーザーまたはユーザーの IT チームがこの要件を満たすために Azure で設定することを決定したものと一致する選択肢を選択します。詳細については、「AKS タイプ - NAT ゲートウェイまたはルート テーブルの設定と管理サブネットへの関連付け」セクションを参照してください。
ユーザーが割り当てた管理対象 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 に接続します。 第 1 世代ポッドに外部 Unified Access Gateway 構成と内部 Unified Access Gateway 構成の両方があり、それらの Gateway 構成に設定されている FQDN と証明書が異なる場合、移行後の Edge の Unified Access Gateway では外部 FQDN と内部 FQDN の両方がデフォルトで同じ FQDN（ここのウィザードに入力した FQDN）に設定されます。 移行後に、Edge の Unified Access Gateway の詳細を編集して、内部 FQDN を内部ユーザーに使用する FQDN に変更し、内部ユーザーを識別するようにネットワーク範囲を構成できます。 注：移行後に内部 FQDN を外部 FQDN とは別の値になるように更新する場合は、アップロードする証明書のデータに、ウィザードに入力した FQDN と、使用する予定の内部 FQDN の両方が反映されていることを確認してください。それ以外の場合は、移行後に外部 FQDN と内部 FQDN の両方を反映した証明書をアップロードする必要があります。
証明書タイプ	PEM または PFX の 2 つの選択肢があります。ユーザーまたはユーザーの IT チームがこのデプロイで取得した証明書と一致するタイプを選択します。これは、Unified Access Gateway の FQDN に一致します。 PFX の場合、PFX 証明書のパスワードを入力するための追加の パスワード フィールドが表示されます。
証明書	ボタンをクリックして、証明書をアップロードします。
手動パブリック IP アドレス	このフィールドは、第 1 世代ポッドの外部ゲートウェイのデプロイがプライベート IP アドレスを使用するように構成されていることをシステムが検出した場合に表示されます。「第 1 世代 Horizon Cloud ポッドを移行するための前提条件」の説明に従って、Horizon Cloud デプロイに使用するパブリック IP アドレスを入力します。 注：ロールバックが必要な場合に第 1 世代のデプロイ状態へのロールバックをサポートするため、このパブリック IP アドレスは、移行対象の第 1 世代デプロイですでに使用されているパブリック IP アドレスとは異なる必要があります。 プレビルド アクティビティの一環として、システムは、プライベート IP アドレスを使用して Horizon Cloud Unified Access Gateway デプロイのロード バランサをデプロイします。ロード バランサがデプロイされ、そのプライベート IP アドレスが認識されたら、このパブリック IP アドレスがトラフィックをデプロイされたロード バランサのプライベート IP アドレスに送信するようにルーティングを設定する必要があります。

オプションの詳細設定：単一仮想マシンの内部ネットワーク範囲

単一仮想マシン内には、内部ネットワーク範囲に使用する、システムが設定したデフォルト値があります。これらの内部ネットワークは、仮想マシン内の Kubernetes によって使用され、仮想マシンの外部からアクセスすることはできません。ユーザーの社内ネットワークと重複しない限り、システムが設定したデフォルト値のままにすることをお勧めします。まれな状況で、仮想マシンの内部範囲と重複する既存のネットワーク セグメントがある場合は、ウィザードの [詳細] セクションを使用してカスタム値を指定します。

「単一仮想マシンのデプロイ要件」の説明に従って、この特別なケースの要件を満たすようにユーザーまたは IT チームが決定した CIDR を入力します。

• サービス CIDR：/27 以上が必要です。
• ポッド CIDR：/21 以上が必要です。

ウィザードのすべての必須フィールドにエントリがある場合

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

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

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

選択した期間内：

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

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

• カレンダー ビューには、選択した第 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 リージョン、異なるサービス プリンシパルの app ID があります。システムは、第 1 世代ポッドのアプリケーション ID を選択された Horizon Edge のプロバイダに追加することによって、そのプロバイダをスケーリングします。
• 第 1 世代ポッドには、異なるサブスクリプション、同じ Microsoft Azure リージョン、異なるサービス プリンシパルの app 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 にマッピングするレコードを追加する必要があります。詳細については、Horizon Cloud ドキュメントの「Horizon Edge Gateway および Unified Access Gateway のデプロイ後に必要な DNS レコードを構成する」を参照してください。

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

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

次の手順

システムのプレビルド フェーズ中のほとんどの時間は、システムがプレビルド アクティビティを完了するのを待つことになります。

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

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

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

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

[移行] ページの機能

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

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

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

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

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

簡単な紹介

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

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

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

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

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

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

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

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

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

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

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

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

プレビルド中

ビルド前の実行中:

1. 移行で既存の Horizon Edge ではなく新しい Horizon Edge を使用する場合、システムは、フェーズ 4 の [移行のスケジュール設定] ユーザー インターフェイスで指定した入力を使用して、Horizon Cloud Horizon Edge をデプロイします。

2. システムはポッド レベルで第 1 世代の制御プレーンに保存されている第 1 世代の構成データを取得し、Horizon Cloud Control Plane の設計に一致するようにデータを変換し、変換されたデータを適切に保存します。

3. この移行が Horizon Cloud 環境への最初の移行である場合、システムは第 1 世代テナントの Active Directory (AD) ドメイン構成を取得し、Horizon Cloud 環境に同等のドメイン構成を作成します。

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

   **注：**Horizon Cloud 環境では、Horizon Cloud Active Directory ドメイン構成で、ドメイン バインド アカウントとドメイン参加アカウントの両方に対する補助アカウントが必要です。第 1 世代テナントの Active Directory ドメイン構成に、補助ドメイン バインド アカウントまたは補助ドメイン参加アカウントがない場合、システムはプライマリ アカウント情報を Horizon Cloud 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 時間以内に起動して実行されます。

**注：**第 1 世代ポッドに外部 Unified Access Gateway 構成と内部 Unified Access Gateway 構成の両方がある場合、結果として得られる Edge の Unified Access Gateway のアクセス タイプは [内部および外部アクセス] に設定され、外部 FQDN と内部 FQDN の両方がデフォルトで同じ FQDN（スケジュール設定ウィザードに入力した FQDN）に設定されます。内部アクセスに別の FQDN を使用する場合は、Edge の Unified Access Gateway の詳細を編集して、内部 FQDN を使用する予定の別の FQDN に変更します。証明書の情報には、その内部 FQDN が含まれている必要があります。

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

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

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

**注：**第 1 世代 RDSH アプリケーション サーバ ファーム用に作成されたテスト プールを事前に検証するには、Horizon Cloud 環境内のテスト プールに対する資格をユーザーまたはグループに明示的に付与する必要があります。第 1 世代 RDSH アプリケーション サーバ ファームの場合、プレビルド プロセスでは第 1 世代のユーザーまたはグループの資格がテスト プールにレプリケートされません。

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

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

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

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

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

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

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

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

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

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

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

次の手順

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

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

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

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

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

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

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

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

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

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

• 第 1 世代のデプロイのフローティング デスクトップ プールとファームをキャパシティを使用しなくなるまで縮小する。

• これに対応して、Horizon Cloud 環境でフローティング デスクトップ プールとファームを拡張して、第 1 世代のデプロイで使用していたキャパシティと一致させる。

• 第 1 世代のデプロイの専用デスクトップ プールからのデスクトップ仮想マシンを Horizon Cloud 環境とペアリングする。

  **注：**専用デスクトップの移行アクションでは、時間が専用デスクトップ プールの電源管理スケジュール外であっても、必要に応じてデスクトップ仮想マシンの電源が自動的にオンになる場合があります。移行の一環として、デスクトップ仮想マシンの Horizon Agent は、第 1 世代のデプロイからペアリングを解除し、Horizon Cloud 環境とペアリングする必要があります。これには、仮想マシンの電源投入が必要な場合があります。

  また、メンテナンス ウィンドウ中に Horizon Cloud Console にアクセスすると、プール ユーザー インターフェイスに、移行中の専用プールの Error ステータスが表示されることがあります。この動作は、メンテナンス ウィンドウ中に発生することが想定されます。

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

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

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

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

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

• 専用デスクトップ仮想マシンの監視データは、Omnissa Intelligence に公開されません。

• Horizon Cloud Console を使用すると、専用デスクトップ プールまたは専用デスクトップ仮想マシンのエージェントを更新または再インストールできなくなります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ブラウザ：「Horizon Web Client を使用したデスクトップの起動」と「Horizon Web Client を使用したアプリケーションの起動」
• ネイティブ Horizon Client：「Horizon Client でのデスクトップの起動 」と「Horizon Client でのアプリケーションの起動」。

Horizon Cloud 環境のエンド ユーザー クライアント URL をカスタマイズしていない場合、デフォルトの開始アドレスは cloud.omnissahorizon.com です。クライアント URL またはサブドメインがカスタマイズされている場合は、カスタム URL を使用します。カスタマイズについては、Horizon Cloud ドキュメントの「ブランディングを構成する」を参照してください。

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

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

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

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

Horizon Universal Console への管理アクセスは Omnissa Connect (connect.omnissa.com) を介して行います。

1. https://connect.omnissa.com/ にログインし、[マイ サービス] に移動して [Workspace ONE Cloud] カードを見つけます。

   

2. そのサービスを起動して、サービス間で表示されるカードを確認します。そのカードの [管理] をクリックして、Horizon Universal Console を起動します。

管理者パスワードが 12 文字未満のイメージを更新して再公開する

イメージの仮想マシンを複製し、管理者パスワードを 12 文字以上に変更して、仮想マシンを公開し、元の仮想マシンを削除します。

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

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

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

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

Active Directory ドメインの構成

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

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

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

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

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

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

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

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

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

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

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

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

第 1 世代の環境に複数のポッドを含むマルチクラウド割り当てがある場合は、「第 1 世代の割り当てに複数のポッドがある場合：重要な移行ポイント」の点からのガイダンスも参考にしてください。

App Volumes：移行後

移行後：

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

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

• App Volumes：ポッドの移行

  一定の期間にわたって Horizon Cloud ポッドを継続的に移行する際、システムは、第 1 世代ポッドから Horizon Cloud 環境へのすべての 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 があります。

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

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

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

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

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

移行後：

• 1 対 1 のマッピングは、第 1 世代のアプリケーション ファームと、Horizon Cloud で生成されたプールの間に保持されます。

• 移行されたファームごとに、ファームの名前を使用してプールが作成されます。

• 移行プロセスでは、プールの名前を使用してプールごとにプール グループも作成されます。これは、移行の場合は元のファームの名前でもあります。

• 各プール グループには、そのプール グループのプールに関連付けられているアプリケーションに応じて、第 1 世代アプリケーション割り当てから移行されたユーザー資格に関する情報が表示されます。

• 第 1 世代アプリケーション割り当て名は、Horizon Cloud Console に表示されません。第 1 世代アプリケーション割り当てに複数のファームからのリモート アプリケーションが含まれている場合、Horizon Cloud Console 内でリモート アプリケーションとエンド ユーザー資格を表示するには、ファーム名で作成された各プール グループを表示するか、コンソールの [デスクトップとアプリケーション カタログ] > [公開アプリケーション] を使用します。

  **注：**第 1 世代のファーム仮想マシンに手動アプリケーションを直接インストールした場合、移行プロセスの一環としてメタデータが移行されても、そのようなアプリケーションはデフォルトで Horizon Cloud 環境のプール仮想マシンにインストールされません。このようなアプリケーションの場合は、第 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 のみの使用資格が付与されます。

Horizon Cloud への移行後：

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

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

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

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

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

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

移行のファイナライズ

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

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

ファイナライズすると、

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

ファイナライズ後、移行を Horizon Cloud 環境から第 1 世代のデプロイ状態にロールバックすることはできません。

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

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

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

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

• 移行を終了して第 1 世代ポッドが削除されるまでは、ポッド マネージャ インスタンスや Unified Access Gateway インスタンスを含む第 1 世代リソースを実行するための Microsoft Azure サブスクリプション コストが発生します。

• 移行をファイナライズするまで、Horizon Cloud Horizon Universal Console では、専用プール グループでエージェントの更新操作を使用したり、専用仮想マシンでエージェントの再インストールを使用したりできなくなります（[エージェント] > [エージェントの更新] または [エージェント] > [再インストール]）。

  **重要：**Horizon Cloud 環境で移行がファイナライズされていない場合、コンソールでは、第 1 世代から移行されたものであるか、Horizon Cloud 環境で新しく作成されたものであるかに関係なく、すべての専用プール グループおよび専用仮想マシンに対するエージェントの更新およびエージェントの再インストール操作を実行できません。このシナリオでは、移行を完了する必要についてのガイダンス メッセージがコンソールに表示されます。

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

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

ファイナライズの手順

Horizon Cloud Console の [移行] ページで [ファイナライズ] アクションを使用して移行をファイナライズします。

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

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

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

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

移行された環境はこのプライベート エンドポイント構成なしで動作しますが、プライベート エンドポイントを構成すると、このストレージ アカウントのセキュリティがさらに強化されます。

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

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

• 「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 操作の詳細については、『Horizon Cloud の使用』ガイドを参照してください。

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