シングルポッドブローカから Universal Broker への移行について

このトピックでは、Horizon Cloud テナントのブローカ移行プロセスについてと移行を実行して得られるメリットについて紹介します。シングルポッドブローカと Universal Broker の環境の違い、およびブローカの移行前、移行中、移行後に想定可能な点について説明します。

ブローカ移行プロセスについて

ブローカの移行が完了すると、Horizon Cloud テナント環境でエンドユーザーの割り当てからリソースを仲介する方法が、シングルポッド仲介から Universal Broker の使用に変わります。新しいテナント全体のブローカとして、Universal Broker が接続要求を管理し、要求された割り当てから利用可能な最適なリソースにルーティングします。

ブローカ移行プロセスにより、エンドユーザー割り当てに次の変更を行います。

VDI デスクトップ割り当ては、Universal Broker によって仲介されるマルチクラウド割り当てに変換されます。マルチクラウド割り当てには、複数のポッドの VDI デスクトップを含めることができます。
セッションベースのデスクトップとアプリケーションの割り当ては変更されません。セッションベースのデスクトップまたはアプリケーションの割り当てには、シングルポッドからのリソースのみを含めることができますが、割り当ては現在、Universal Broker によって仲介されています。

移行機能は、環境が現在シングルポッド仲介を使用し、Horizon Cloud - Universal Broker に移行するためのシステム要件に記載されている前提条件を満たす場合にのみ利用できます。

Universal Broker に移行するべき理由

VMware が提供する最新のクラウドベースの仲介テクノロジーである Universal Broker の使用に移行すると、主に次のようなメリットが得られます。

複数のポッドからの VDI デスクトップを使用したエンドユーザー割り当て

シングルポッド仲介では、VDI 割り当て内のすべてのデスクトップが同じポッドから取得されている必要があります。デスクトップ仲介はポッドごとに行われます。

Universal Broker を使用すれば、マルチクラウド割り当てとも呼ばれる複数のポッドからの VDI デスクトップの割り当てを作成できます。エンドユーザーは割り当てにアクセスし、その割り当てに含まれる任意のポッドからデスクトップを受信できます。詳細については、VMware Horizon Service Universal Broker についておよびそのサブトピックを参照してください。

セッションベースのデスクトップ割り当てとアプリケーション割り当てを引き続き使用できます。違う点は、これらの割り当てからのセッションベースのデスクトップとアプリケーションが、ポッドごとの仲介ではなく Universal Broker によって仲介されることです。

すべてのリモートリソースの単一の接続 FQDN

シングルポッド仲介を使用する場合、エンドユーザーは各ポッドの完全修飾ドメイン名 (FQDN) に個別に接続して、そのポッドからの割り当てにアクセスする必要があります。仲介はポッドごとに行われます。

Universal Broker を使用すると、ユーザーは 1 つの FQDN に接続してすべての割り当てにアクセスできます。FQDN は、Universal Broker 設定で定義します。単一の FQDN を介して、ユーザーは環境内の任意のサイトから、参加しているすべてのポッド（Microsoft Azure の Horizon Cloud ポッドと VMware SDDC ベースのプラットフォーム上の Horizon ポッドの両方を含む）の割り当てにアクセスできます。ポッド間の内部ネットワークは必要ありません。

最適なパフォーマンスのためのグローバルポッド接続と認識

Universal Broker は、マルチクラウド割り当てに参加しているすべてのポッドとの直接接続を維持し、各ポッドの可用性ステータスを引き続き認識します。その結果、 Universal Broker はエンドユーザーの接続要求を管理し、これらのポッドから直接仮想リソースにルーティングできます。パフォーマンスの低下や遅延の問題の原因となる、グローバルサーバロードバランシング (GSLB) やポッド間のネットワーク通信を行う必要はありません。

スマート仲介

Universal Broker は、地理的サイトとポッドトポロジの認識に基づいて、最短のネットワークルートに沿って割り当てからエンドユーザーにリソースを仲介できます。

移行しない場合の理由

今回のリリースの Universal Broker には、機能上いくつかの既知の制限があります。ユースケースで、Universal Broker がサポートしていない機能が必要な場合は、Universal Broker がその機能をサポートするまで、シングルポッド仲介を使用してテナント環境を維持することを検討してください。現在の Universal Broker 制限事項のリストについては、Universal Broker - 機能に関する注意事項と既知の制限を参照してください。

ブローカの移行中に何が起きますか?

移行ワークフローは、いくつかの段階で構成されます。移行を実行する手順の詳細については、シングルポッドブローカから Universal Broker への移行をスケジューリングして完了するを参照してください。

移行前と移行中に発生するプロセスの概要を以下に示します。

ワークフローを開始するには、まず、移行が実行される日時をスケジューリングする必要があります。このスケジューリングタスクに沿って、移行中に Universal Broker サービスの設定に使用する構成オプションを定義します。
スケジュールリングされた開始時刻の少なくとも 15 分前に、コンソールで進行中のすべての操作を完了し、保持する変更をすべて保存します。すべての構成ウィザードとダイアログボックスを閉じます。さらに、Microsoft Azure 内のすべてのポッドがオンラインで、健全な準備完了の状態であることを確認します。
移行を開始すると、コンソールからログアウトして再度ログインするように求めるプロンプトが表示されます。
移行の最初の段階では、次の状態が予測されます。
- コンソールの編集コントロールにアクセスできません。コンソールには、移行が進行中であることを示すバナーが表示されます。
- Microsoft Azure のすべてのポッドは、[Default-Site] という名前のサイトに追加されます。
- VDI デスクトップ割り当ては、Universal Broker によって仲介されるマルチクラウド割り当てに変換されます。デフォルトの割り当て設定では、接続アフィニティは [最も近いサイト] に設定され、範囲は [サイト内] に設定されます。
- セッションベースのデスクトップとアプリケーションの割り当ては変更されません。移行後、これらの割り当て内のリソースは、Universal Broker によって仲介されます。
- この間、すべての割り当てはエンドユーザーが引き続き利用でき、すべてのアクティブなユーザーセッションは開いたままで完全に機能します。
注：移行のこの段階には通常約 10 分かかりますが、テナント環境に多数の割り当てが含まれている場合は最大 1 時間かかることがあります。
移行のこの段階が完了すると、コンソールからログアウトして再度ログインするように求めるプロンプトが表示されます。
移行の第 2 段階では、Universal Broker サービスがセットアッププロセスを完了し、完全に有効になります。割り当ての作成と編集を除いた、コンソールのすべての編集操作にアクセスできます。
注：移行のこの段階には通常、最大で 30 分かかります。ただし、システムとネットワークの状態、および環境内の割り当ての総数と専用のユーザーからデスクトップへのマッピングによっては、この段階が完了するまでに数時間かかる場合があります。
移行のこの段階が完了すると、[設定] > [ブローカ] ページに [有効] のステータスが緑色のドットで表示されます。
この時点で、ブローカ全体の移行が完了します。

ブローカの移行後に想定されることについて

ブローカの移行後にテナント環境に加えられる変更の詳細なリストについては、Universal Broker への移行後のテナント環境の最新情報を参照してください。

移行が完了したら、Universal Broker 環境で提供されるメリットを利用できるようになります。次のリストに、次の手順の概要と詳細ページへのリンクを示します。

サイトとマルチクラウド VDI 割り当ての設定を変更して、Universal Broker 機能をフル活用します。たとえば、既存の割り当てにポッドを追加したり、サイト設定を調整して、Universal Broker のユーザーへのリソースの割り当て方法を微調整することができます。詳細については、Universal Broker 環境での割り当ての作成および管理およびUniversal Broker 環境でのサイトの操作を参照してください。
Horizon Cloud テナントと Workspace ONE Access の間に既存の統合がある場合は、Universal Broker の使用に合わせて統合を更新する必要があります。詳しい手順については、Universal Broker を使用した Horizon Cloud 環境 - テナントを Workspace ONE Access および Intelligent Hub サービスと統合するを参照してください。
注： VMware Workspace ONE Access 製品チームが確認したように、 Universal Broker が Horizon Cloud on Microsoft Azure 展開で使用される場合、 VMware Workspace ONE Access 製品の仮想アプリケーションのコレクション機能はその構成でサポートされません。この理由は、 Universal Broker が古いスタイルのポッドごとの仲介よりも新しい仲介テクノロジーであるためです。つまり、 Universal Broker と Workspace ONE Access の統合は、 Horizon Cloud on Microsoft Azure 展開ではレガシーのポッドごとの仮想アプリケーションのコレクションよりも優先して使用されます。したがって、 Universal Broker には、 Horizon Cloud on Microsoft Azure 展開向けの仮想アプリケーションのコレクションの概念はありません。このため、 Universal Broker および Horizon Cloud on Microsoft Azure 構成での仮想アプリケーションのコレクションの使用はサポートされません。
Universal Broker が Horizon Cloud on Microsoft Azure 展開に構成され、これらの Horizon Cloud on Microsoft Azure 展開で Workspace ONE Access および Intelligent Hub サービスを使用する場合、コンソールの [クリーンアップ] アクションの一部である統合プロセスで、これらの展開に含まれる既存の仮想アプリケーションのコレクションをクリーンアップする必要があります。クリーンアップアクティビティを完了すると、統合された Universal Broker と Workspace ONE Access および Intelligent Hub サービスの最新機能を使用して、同じアプリケーションが Workspace ONE Access および Intelligent Hub サービスで引き続き機能するようになります。

Horizon Cloud - Universal Broker に移行するためのシステム要件

この記事では、シングルポッド仲介の使用から Universal Broker へのテナントの移行をスケジューリングして完了する前に、Horizon Cloud テナント環境が満たす必要のある要件について説明します。また、Universal Broker の新しい接続 FQDN をサポートするための計画および準備の手順についても説明します。

移行後に Universal Broker によって仲介されるマルチクラウド割り当ての移行プロセスと継続的な運用をサポートするには、テナント環境が次の要件を満たしていることを確認します。

注意：テナントのポッドフリートに、 Universal Broker をすでに使用している Horizon ポッドとシングルポッド仲介を使用する Horizon Cloud ポッドが混在している場合は、すでに構成されている Universal Broker 設定の 2 要素認証設定が Horizon Cloud ポッドと一致することを特に注意する必要があります。

Horizon Cloud ポッドがテナント環境での最小ポッドマニフェストと RSA SecurID オプションの有効化の基準を満たしている場合を除き、これらのポッドは RADIUS 認証のみをサポートします。（詳細については、Universal Broker 環境で 2 要素認証を実装する際のベストプラクティスを参照してください。）
Horizon Cloud ポッドが外部ゲートウェイで RSA SecurID を構成するための基準を満たしていない場合、フリート内のすべてのポッド（Horizon ポッドと Horizon Cloud ポッドの両方）で 2 要素認証を使用するには、各ポッドに RADIUS 2 要素認証が構成された外部 Unified Access Gateway が必要です。

Horizon Cloud ポッドの要件

Microsoft Azure の Horizon Cloud ポッドが次の要件を満たしていることを確認します。

テナントに少なくとも 1 つの Horizon Cloud ポッドがあります。Horizon Cloud ポッドは、Microsoft Azure で実行されているポッドマネージャテクノロジーに基づいています
テナントのすべての Horizon Cloud ポッドは、ポッドマニフェスト 2298.0 以降で実行されています。特定のユースケースでは、次の要件も適用されます。
- Horizon Cloud テナントと Workspace ONE Access の間に既存の統合がある場合は、すべてのポッドがマニフェスト 2474.0 以降で実行されている必要があります。ブローカの移行が完了した後、Universal Broker を使用した Horizon Cloud 環境 - テナントを Workspace ONE Access および Intelligent Hub サービスと統合するの説明に従って、Universal Broker の使用に合わせて統合を更新する必要があります。
- ブローカの移行後にタスクキャンセル機能または削除保護機能を使用する場合は、すべての Horizon Cloud ポッドがマニフェスト 2474.0 以降で実行されている必要があります。ポッドがマニフェスト 2474.0 より前のマニフェストで実行されている場合、これらの機能はサポートされません。
重要：すべての Horizon Cloud ポッドがオンラインで、健全な準備完了の状態であることを確認します。移行プロセスを完了するために、 Universal Broker サービスはポッドとの通信を行い、ポッドでいくつかの構成手順を実行する必要があります。オフラインまたは使用できないポッドがある場合は、移行をスケジューリングできません。移行をスケジュールリングしても、いずれかのポッドが後でオフラインになるか、移行の進行中に使用できなくなると、 Universal Broker のセットアップは失敗します。
移行と同時にポッドのアップグレードがスケジューリングされることはありません。
ポッドの場所は、ポッド構成ウィザードのメニューオプションから有効な場所を選択することによって構成されます。テキストフィールドに手動で入力してポッドの場所を構成した場合、移行は失敗します。
注：手動で入力した場所に関連するこの問題は、2019 年 3 月（サービスリリース 1.9）より前に最初にデプロイされたポッドで発生する可能性が高くなります。2019 年 3 月のリリース以降、場所はシステムの世界の市区町村名データベース内の値からメニューで選択する必要があります。
ポッドの構成された場所が原因で移行が失敗するシナリオに遭遇する可能性を減らすには、コンソールの [キャパシティ] ページに移動し、各 Horizon Cloud ポッドの [場所] 列の値を調べます。[場所] 列の値が手動で入力した名前のように表示される場合は、ポッドの [編集] アクションを使用して、[ポッドの詳細] 手順に移動し、[場所] フィールドを編集して、その値をシステムの市区町村名の値のいずれかに設定します。
移行ワークフローで、テナントにポッドフリート内の Horizon ポッドからの Universal Broker 設定がない場合、コンソールに Universal Broker 設定を求めるプロンプトが表示されます。Universal Broker 設定で 2 要素認証設定を構成する場合は、各ポッドに外部 Unified Access Gateway インスタンスが必要で、そのインスタンスは適切な 2 要素認証タイプで構成されている必要があります。（背景情報については、Universal Broker 環境で 2 要素認証を実装する際のベストプラクティスを参照してください。）
要件は、Horizon Cloud ポッドが外部ゲートウェイで RSA SecurID タイプを構成するための基準を満たしているかどうかによって異なります。
- Horizon Cloud ポッドが最小ポッドマニフェストおよびテナント環境での RSA SecurID オプションの有効化の条件を満たしている場合は、すべてのポッドにまたがるすべての外部 Unified Access Gateway インスタンスを同じ認証サービスを使用するように構成します。これには、管理対象状態にあるテナントの Horizon ポッドがすべて含まれます。その結果、すべてが一致する認証タイプを使用するようになります（すなわち、すべてが RADIUS またはすべてが RSA SecurID を使用）。
- Horizon Cloud ポッドが、外部ゲートウェイで RSA SecurID を構成するための条件を満たしていないときに、フリート内のすべてのポッド（Horizon ポッドと Horizon Cloud ポッドの両方）で 2 要素認証を使用する必要がある場合、同じ RADIUS 認証サービスを使用するには、すべてのポッドにまたがるすべての外部 Unified Access Gateway インスタンスを構成する必要があります。これには、管理対象状態にあるテナントの Horizon ポッドがすべて含まれます。

注：ポッドに内部 Unified Access Gateway インスタンスだけが含まれる場合、 Universal Broker は [ブローカ] ページの [ネットワーク範囲] タブで定義されたネットワークポリシーを上書きし、IP アドレスに関係なく、すべてのユーザーをその Unified Access Gateway インスタンスにルーティングします。

Universal Broker をサポートするための DNS、ポート、およびプロトコル要件

次の要件を確認します。

各ポッドが、地域の Universal Broker インスタンスに必要な DNS 名が解決可能であり、アクセス可能であるように構成されていること。Microsoft Azure での Horizon Cloud ポッドの DNS の要件の「ポッドのデプロイと操作に関する DNS の要件」の表を参照してください。
各ポッドが必要なポートとプロトコルで構成されている（2019 年 9 月リリースのマニフェスト以降の Horizon Cloud ポッドのポートとプロトコルの要件の「Universal Broker で必要なポートとプロトコル」セクションを参照）。

Universal Broker をサポートするための FQDN 要件

シングルポッド仲介を使用する場合、エンドユーザーは各ポッドの完全修飾ドメイン名 (FQDN) に個別に接続して、そのポッドからの割り当てにアクセスします。

Universal Broker への移行後、ユーザーは Universal Broker クラウドサービスの 1 つの FQDN に接続することで、環境内の任意のサイトの任意のポッドから任意の割り当てにアクセスできます。Universal Broker は、要求を処理できる最も適切なポッドの個々の FQDN に各ユーザー要求をルーティングします。

シングルポッドブローカから Universal Broker への移行をスケジューリングして完了するの説明に従って、Universal Broker 構成設定で Universal Broker FQDN を指定します。有効なサブドメインを VMware が提供する標準ドメインの前に付けることで FQDN を作成するか、完全にカスタムの FQDN を構成することができます。

注：カスタム FQDN を構成する場合は、この FQDN が自分の会社または組織を表すことに注意してください。カスタム FQDN で指定されたドメイン名の所有者であり、そのドメインを検証する証明書を提供でき、カスタム FQDN を使用するための適切な承認を持っていることを確認してください。 Universal Broker のカスタム FQDN は、ポッド内のすべての Unified Access Gateway インスタンスの FQDN とは異なる一意の値でなければなりません。

ブローカ移行の計画と準備

ブローカの移行にはネットワークと割り当てのワークフローへの重要な変更が含まれるため、新しいワークフローに向けて環境とユーザーを準備するために必要なアクションを実行するようにしてください。移行の使用事例に基づく適切な準備と変更管理手順については、次のプランニングガイドを参照してください。


移行の使用事例	計画と準備の手順
環境が単一のポッドで構成されており、そのポッドの既存の FQDN を Universal Broker の FQDN として使用する	移行のスケジュールリングプロセスの構成段階で、ポッドの既存の FQDN を Universal Broker サービスのカスタム FQDN として指定します。エンドユーザーの割り当てワークロードへの影響を最小限に抑える日時で移行をスケジューリングします。予定された移行に備え、エンドユーザーに通知して準備します。移行時間が近づくにつれて、作業を保存し、アクティブな接続セッションからログアウトします。移行の直前に、新しい IP アドレスと FQDN をポッドに割り当てます。移行が完了したら、ポッドの以前の FQDN（現在は Universal Broker の FQDN）を使用して接続セッションを再開できることをエンドユーザーに通知します。
環境が複数のポッドで構成されており、そのポッドの新しい FQDN を Universal Broker の FQDN として構成する	移行プロセスの前、移行中、および移行後に実行する必要がある手順を含めるには、手順を更新します。移行のスケジュールリングプロセスの構成段階で、Universal Broker サービスの新しい FQDN を構成します。エンドユーザーの割り当てワークロードへの影響を最小限に抑える日時で移行をスケジューリングします。ポッドのデプロイの規模に応じて、ユーザートレーニングとクライアントソフトウェアの再構成に十分な時間を確保します。予定された移行に備え、エンドユーザーに通知して準備します。移行時間が近づくにつれて、作業を保存し、アクティブな接続セッションからログアウトします。移行中または移行直後に、ユーザーのクライアントシステムの Horizon Client を再構成して、個々のポッドの FQDN ではなく、新しい Universal Broker FQDN に接続します。新しいブローカ接続 FQDN を使用する必要があり、その結果、環境内のすべてのポッドへのユニバーサルアクセスを取得できることをエンドユーザーに通知します。

シングルポッドブローカから Universal Broker への移行をスケジューリングして完了する

このトピックでは、Universal Broker への移行のスケジューリング、準備、完了の手順をご案内します。Universal Broker サービスを設定し、移行の開始日時を定義し、プロセスの各段階を円滑に移動して移行を成功する方法については、次の手順を参照してください。

ブローカの移行をスケジューリングする準備が整っている場合、[スケジュール] ボタンを含む通知バナーが Horizon Universal Console の上部に表示されます。

注：バナーにエラー状態が表示され、移行のスケジューリングができない場合は、移行の前提条件の 1 つ以上を満たすことができなかった可能性があります。バナーの [エラーの表示] をクリックし、 [ブローカ] ページの [移行が必要です] リンクの横にあるエラーアイコンをクリックして、エラー状態の詳細を表示します。移行をスケジューリングする前に、エラー状態をクリアするための必要な手順を実行する必要があります。

前提条件

テナント環境が Horizon Cloud - Universal Broker に移行するためのシステム要件に概要を記載したすべての前提条件を満たしていることを確認します。

手順

ブローカ移行の通知バナーの [スケジュール] をクリックします。

このアクションよって、ブローカページへリダイレクトされます。このページは、現在、テナントでシングルポッドブローカが有効であることを示し、ブローカ移行をスケジューリングするリンクを提供します。
[ブローカ] ページで、[スケジュール] をクリックします。
Universal Broker の構成ウィザードが表示されます。このウィザードの手順を実行して、Microsoft Azure のポッド用の Universal Brokerを設定し、 Universal Broker への移行をスケジューリングします。

ウィザードの [FQDN] ページで、仲介接続の FQDN を構成します。これらの設定は、エンドユーザーが Universal Broker によって割り当てられるリソースにアクセスするために使用する専用接続アドレスを定義します。

注：サブドメインまたは FQDN 設定を変更すると、すべての DNS サーバで変更が有効になるまでに時間がかかる場合があります。

[タイプ] には、[VMware が提供] または [カスタム] の完全修飾ドメイン名 (FQDN) を選択します。

選択した FQDN タイプの追加設定を指定します。

[VMware が提供] タイプを選択した場合、次のように設定を指定します。

設定説明

設定	説明
Sub Domain	会社または組織を表すネットワーク構成内の有効なサブドメインの一意の DNS 名を入力します。このサブドメインは、仲介の FQDN を形成するために、VMware が提供するドメインの先頭に付けられます。注：一部の文字列は、システムによって禁止または予約されています。そのような文字列のカテゴリには、 `book` のような一般的な語句、 `gmail` のような有名企業が所有している既知の用語、プロトコル、コーディング、オープンソースの用語（たとえば `php` や `sql`）などがあります。またシステムは、 `mail0`、 `mail1`、 `mail2` など、これらの文字列のパターンのカテゴリを禁止します。ただし、このフィールドに禁止されている名前を入力すると、システムはその時点での入力を検証しません。ウィザードの最終サマリステップに到達した時点で初めて、システムはここで入力した名前を検証し、入力が禁止された名前のいずれかに一致した場合はエラーが表示されます。その場合は、より一意の名前をここで入力します。
Brokering FQDN	この読み取り専用フィールドには、構成された FQDN が表示されます。FQDN は https://`<your sub-domain>`vmwarehorizon.com の形式を使用します。この FQDN をエンドユーザーに提供し、Horizon Client を使用して Universal Broker サービスに接続できるようにします。 Universal Broker は、この FQDN の DNS および SSL 検証を管理します。

Sub Domain

会社または組織を表すネットワーク構成内の有効なサブドメインの一意の DNS 名を入力します。このサブドメインは、仲介の FQDN を形成するために、VMware が提供するドメインの先頭に付けられます。

注：一部の文字列は、システムによって禁止または予約されています。そのような文字列のカテゴリには、 book のような一般的な語句、 gmail のような有名企業が所有している既知の用語、プロトコル、コーディング、オープンソースの用語（たとえば php や sql）などがあります。またシステムは、 mail0、 mail1、 mail2 など、これらの文字列のパターンのカテゴリを禁止します。

ただし、このフィールドに禁止されている名前を入力すると、システムはその時点での入力を検証しません。ウィザードの最終サマリステップに到達した時点で初めて、システムはここで入力した名前を検証し、入力が禁止された名前のいずれかに一致した場合はエラーが表示されます。その場合は、より一意の名前をここで入力します。

Brokering FQDN

この読み取り専用フィールドには、構成された FQDN が表示されます。FQDN は https://<your sub-domain>vmwarehorizon.com の形式を使用します。

この FQDN をエンドユーザーに提供し、Horizon Client を使用して Universal Broker サービスに接続できるようにします。

Universal Broker は、この FQDN の DNS および SSL 検証を管理します。

[カスタム] タイプを選択した場合、次のように設定を指定します。

設定	説明
Brokering FQDN	エンドユーザーが Universal Broker サービスへのアクセスに使用するカスタムの FQDN を入力します。カスタム FQDN は、サービスへの接続を完了する自動生成された VMware 提供の FQDN のエイリアスとして機能します。カスタム FQDN 内で指定されたドメイン名の所有者であること、またそのドメインを検証できる証明書を指定することが必要です。注：カスタム FQDN は、接続 URL とも呼ばれ、会社または組織を表します。このカスタム FQDN を使用するための適切な権限があることを確認します。注：カスタム FQDN は、ポッド内のすべての Unified Access Gateway インスタンスの FQDN とは異なる一意の値でなければなりません。重要：カスタム FQDN を Universal Broker サービスの内部接続アドレスを表す VMware 提供の FQDN にマッピングする CNAME レコードを DNS サーバに作成する必要があります。たとえば、レコードは `vdi.examplecompany.com` を `<自動生成文字列>.vmwarehorizon.com` にマッピングすることがあります。
Certificate	[参照] をクリックして、仲介の FQDN を検証する証明書（パスワード保護された PFX 形式）をアップロードします。証明書は以下の条件をすべて満たす必要があります。 90 日以上有効である信頼されている認証局 (CA) によって署名されている証明書の共通名 (CN) またはそのサブジェクト代替名 (SAN) のいずれかが FQDN と一致している証明書の内容が標準の X.509 形式に準拠している PFX ファイルに、ドメイン証明書、中間証明書、ルート CA 証明書、プライベートキーを含む、完全な証明書チェーンが含まれている必要があります。 Universal Broker サービスは、この証明書を使用して、クライアントとの信頼された接続セッションを確立します。
Password	PFX 証明書ファイルのパスワードを入力します。
VMware Provided FQDN	この読み取り専用フィールドには、仲介サービス用に自動的に作成される VMware 提供の FQDN が表示されます。FQDN は https://`<auto-generated string>`.vmwarehorizon.com の形式を使用します。 VMware 提供の FQDN はエンドユーザーには表示されず、Universal Broker サービスの内部接続アドレスを表します。カスタム FQDN は、VMware 提供の FQDN のエイリアスとして機能します。重要：カスタム FQDN を VMware 提供の FQDN にマッピングする CNAME レコードを DNS サーバに作成して、エイリアスの関連付けを設定する必要があります。たとえば、レコードは `vdi.examplecompany.com` を `<自動生成文字列>.vmwarehorizon.com` にマッピングすることがあります。

カスタム FQDN 設定が入力された Universal Broker 構成ウィザード

FQDN 設定の構成が完了したら、[次へ] をクリックしてウィザードの次のページに進みます。

（オプション）ウィザードの [認証] ページで、2 要素認証を構成します。

デフォルトでは、 Universal Broker は Active Directory のユーザー名とパスワードのみを使用してユーザーを認証します。追加の認証方法を指定することで、2 要素認証を実装できます。詳細については、 Universal Broker 環境で 2 要素認証を実装する際のベストプラクティスを参照してください。

重要： Universal Broker に 2 要素認証を使用するには、まず、参加しているすべてのポッドの各外部 Unified Access Gateway インスタンスで適切な認証サービスを構成する必要があります。外部 Unified Access Gateway インスタンスの構成は、参加しているポッド内およびポッド間で同一でなければなりません。

たとえば RADIUS 認証を使用する場合は、参加しているすべての Horizon ポッドおよび Microsoft Azure のポッドにわたって、各外部 Unified Access Gateway インスタンスに RADIUS サービスを構成する必要があります。

参加しているポッド内の Unified Access Gateway インスタンスを削除しないでください。Universal Broker は、Horizon Client と仮想リソース間のプロトコルトラフィックの Unified Access Gateway に依存しているため、参加しているポッドの Unified Access Gateway インスタンスを削除すると、ユーザーはそのポッドからプロビジョニングされたリソースにアクセスできません。

設定	説明
Two-Factor Authentication	2 要素認証を使用するには、このトグルを有効にします。トグルを有効にすると、2 要素認証を構成するための追加オプションが表示されます。
Maintain User Name	Universal Broker への認証中にユーザーの Active Directory ユーザー名を維持する場合はこのトグルを有効にします。有効になっている場合：ユーザーは、Universal Broker に対する Active Directory 認証の場合と同じユーザー名認証情報を追加の認証方法でも利用できる必要があります。ユーザーは、クライアントログイン画面でユーザー名を変更することができません。このトグルがオフになると、ユーザーはログイン画面で別のユーザー名を入力することができます。
Type	Active Directory のユーザー名とパスワードに加えて、Universal Broker がエンドユーザーで使用する認証方法を指定します。ユーザーインターフェイスには、[RADIUS] と [RSA SecurID] の 2 つの選択肢が表示されます。この設定は、テナント全体に適用されます。エンドユーザークライアントの動作は、以下のように、テナントのポッドフリートの構成と、ポッドのゲートウェイで構成されている 2 要素認証タイプによって異なります。 Horizon ポッドのみここで選択するタイプは、クライアントで使用されるタイプです。 Horizon Cloud ポッドのみポッドの外部ゲートウェイで構成されているタイプと一致するタイプを選択します。 Horizon ポッドと Horizon Cloud on Microsoft Azure デプロイの混在混合フリートでは、ここで [RADIUS] を選択すると、両方のポッドタイプの Unified Access Gateway インスタンスを介してユーザーの RADIUS 認証要求が試行されます。混合フリートでは、ここで [RSA SecurID] を選択すると、クライアントの動作は、Horizon Cloud on Microsoft Azure デプロイが外部ゲートウェイで RSA SecurID を使用して構成されているかどうかによって異なります。 Horizon Cloud on Microsoft Azure デプロイのゲートウェイで RSA SecurID タイプが構成されていない場合、ここで [RSA SecurID] を選択すると、Horizon ポッドの Unified Access Gateway インスタンスのみを介してユーザーの RSA 認証要求が試行されます。Active Directory のユーザー名とパスワードの認証要求は、Horizon ポッドまたは Horizon Cloud ポッドの Unified Access Gateway インスタンスを通じて試行されます。 Horizon Cloud on Microsoft Azure デプロイで RSA SecurID タイプが構成されている場合、ユーザーの RSA 認証要求は両方のポッドタイプの Unified Access Gateway インスタンスを介して試行されます。
Show Hint Text	このトグルを有効にすると、クライアントのログイン画面に表示されるテキスト文字列を構成して、ユーザーに追加の認証方法に対する認証情報の入力を求めることができます。
Custom Hint Text	クライアントのログイン画面に表示するテキスト文字列を入力します。指定されたヒントは、`Enter your DisplayHint user name and password` としてエンドユーザーに表示されます。ここで、`DisplayHint` はこのテキストボックスで指定するテキスト文字列です。注： Universal Broker のヒントテキストに、 `& < > ' "` の文字を含めることはできません。これらの許可されていない文字のいずれかをヒントテキストに含めると、ユーザーは Universal Broker FQDN への接続に失敗します。このヒントを参考にして、ユーザーは正しい認証情報を入力することができます。たとえば、`Company user name and domain password below for` のようなフレーズを入力すると、`Enter your Company user name and domain password below for user name and password` というプロンプトがエンドユーザーに表示されます。
Skip Two-Factor Authentication	Universal Broker サービスに接続している内部ネットワークユーザーの 2 要素認証をバイパスするには、このトグルを有効にします。Universal Broker の内部ネットワーク範囲の定義の説明に従って、内部ネットワークに属しているパブリック IP アドレス範囲を指定していることを確認します。このトグルが有効になると、内部ユーザーは、Universal Broker サービスに対して認証するために、Active Directory の認証情報のみを入力する必要があります。外部ユーザーは、Active Directory の認証情報と、追加の認証サービスの認証情報の両方を入力する必要があります。このトグルがオフになると、内部および外部の両方のユーザーは、Active Directory の認証情報と、追加の認証サービスの認証情報を入力する必要があります。
Public IP Ranges	このフィールドは、[2 要素認証をスキップ] が有効になっている場合に表示されます。 [ブローカ] ページの [ネットワーク範囲] タブで 1 つ以上のパブリック IP アドレス範囲がすでに指定されている場合、このフィールドは読み取り専用で、これらの IP アドレス範囲が一覧表示されます。 [ブローカ] ページの [ネットワーク範囲] タブにパブリック IP アドレス範囲がまだ指定されていない場合は、このフィールドを使用して、内部ネットワークを表すパブリック IP アドレス範囲を指定し、それらの範囲からのトラフィックの 2 要素認証プロンプトをスキップすることができます。Universal Broker は、これらのいずれかの範囲内の IP アドレスから接続しているユーザーを、内部ユーザーと見なします。これらの範囲を指定する目的の詳細については、Universal Broker の内部ネットワーク範囲の定義を参照してください。

2 要素認証の構成が完了したら、 [次へ] をクリックしてウィザードの次のページに進みます。

構成ウィザードの [設定] ページで、Horizon Client の [期間] 設定を構成します。

これらのタイムアウト設定は、 Horizon Client と Universal Broker によって割り当てられた割り当て済みのデスクトップ間の接続セッションに適用されます。これらの設定は、割り当てられたデスクトップのゲスト OS へのユーザーのログインセッションには適用されません。 Universal Broker がこれらの設定で指定されたタイムアウト状態を検出すると、ユーザーの Horizon Client 接続セッションを閉じます。

設定	説明
Client Heartbeat Interval	Horizon Client ハートビートの間隔（分）と、ユーザーの Universal Broker への接続状態を制御します。これらのハートビートは、Horizon Client 接続セッション中に経過したアイドル時間を Universal Broker にレポートします。 Horizon Client を実行しているエンドポイントデバイスとの相互作用が発生しない場合、アイドル時間が測定されます。このアイドル時間は、ユーザーに割り当てられたデスクトップの基盤となるゲスト OS へのログインセッションがアクティブでない状態であることの影響を受けません。大規模なデスクトップデプロイでは、[クライアントのハートビート間隔] を増やすとネットワークトラフィックが減少し、パフォーマンスが向上する場合があります。
Client Idle User	Horizon Client と Universal Broker 間の接続セッションで許可される最大アイドル時間（分）。最大時間に達すると、ユーザーの認証期間が期限切れになり、Universal Broker はすべてのアクティブな Horizon Client セッションを閉じます。接続セッションを再度開くには、ユーザーは Universal Broker ログイン画面で認証情報を再入力する必要があります。注：割り当てられたデスクトップからユーザーが予期せず切断されないようにするには、 [クライアントのアイドルユーザー] タイムアウトを [クライアントのハートビート間隔] の少なくとも 2 倍の値に設定します。
Client Broker Session	ユーザーの認証の有効期限が切れるまでの Horizon Client 接続セッションの最大許容時間（分）。この時間はユーザーが Universal Broker に対して認証されると開始します。セッションのタイムアウトが発生すると、ユーザーは割り当てられたデスクトップで作業を続行できます。ただし、Universal Broker との通信を必要とする設定の変更などのアクションを実行すると、Horizon Client によって Universal Broker の認証情報を再入力するように求められます。注： [Client ブローカセッション] のタイムアウトは、少なくとも [Client ハートビート間隔] 値と [Client アイドルユーザー] のタイムアウトの合計値以上にする必要があります。
Client Credential Cache	ユーザーのログイン認証情報をクライアントシステムキャッシュに保存するかどうかを制御します。キャッシュにユーザー認証情報を保存するには、`1` と入力します。キャッシュにユーザー認証情報を保存しない場合は、`0` と入力します。

期間設定の構成が完了したら、 [次へ] をクリックしてウィザードの次のページに進みます。

ウィザードの [スケジュール] ページで、コントロールを使用して、ブローカの移行を行う [日付] および [開始時刻] を指定します。

現在の現地時間より少なくとも 1 時間早く、現在の日付から 3 か月前までの開始時刻をスケジュールリングできます。開始時刻は、正時に発生する必要があります。

開始時刻を設定するときは、移行が中断することなく進行できるよう十分な時間をとってください。

開始時刻の設定が完了したら、 [次へ] をクリックして、 Universal Broker 構成ウィザードの次の手順に進みます。

注：指定した開始時刻が使用できないことを示すメッセージがコンソールに表示される場合は、 [日付] および [開始時刻] 設定に戻り、移行の別の時間を指定します。
[サマリ] ページで設定を確認し、[終了] をクリックして Universal Broker 構成を保存して適用します。
移行が正常にスケジューリングされたことを示すメッセージが表示されます。
移行がスケジューリングされた後：
- [ブローカ] ページには、今後の移行に関する詳細が表示されます。開始時刻が 1 時間以上離れている場合は、[スケジュール] リンクをクリックして移行のスケジュールを変更できます。
- スケジュールリングされた移行をキャンセルする場合、または 1 時間以内に開始する移行のスケジュール変更を行う場合は、VMware のサポートにお問い合わせください。VMware のサポートでは、15 分以内に開始される移行をキャンセルまたは再スケジューリングすることはできませんのでご注意ください。
- 開始時刻に達するまで、コンソールには今後の移行に関する通知バナーが表示されます。[詳細の表示] をクリックすると、[ブローカ] ページにリダイレクトされます。
- 今後の移行に関する通知メッセージとリマインダメッセージは、テナントに登録されているプライマリ E メールアカウントに送信されます。
移行が開始する少なくとも 15 分前に、次の準備タスクを完了してください。移行中は、コンソールの編集操作にアクセスできません。
- コンソールで進行中のすべての操作を完了し、保持する変更を保存します。
- すべての構成ウィザードとダイアログボックスを閉じます。
重要：移行期間中、Microsoft Azure のすべての Horizon Cloud ポッドがオンラインであり、正常で準備が整った状態であるようにしてください。 Universal Broker サービスは、ポッドと通信し、ポッドでいくつかの構成手順を実行して、移行のブローカ有効化段階を完了する必要があります。いずれかのポッドがオフラインまたは使用できない場合、移行は失敗します。

重要： Microsoft Azure の Horizon Cloud ポッドと VMware SDDC ベースのプラットフォームの Horizon ポッドの両方で構成されるハイブリッド環境がある場合、移行中は、Horizon ポッドで Universal Broker サービスを利用できません。また、この間、Horizon ポッドの状態を監視対象から管理対象に変更することはできません。
移行が始まる少し前に、画面のプロンプトの指示に従ってコンソールからログアウトし、再度ログインします。
移行の最初の段階を中断せずに続行できます。
移行のこの段階では、次の条件が発生します。
- コンソールの編集コントロールにアクセスできません。コンソールには、移行が進行中であることを示すバナーが表示されます。
- Microsoft Azure のすべてのポッドは、[Default-Site] という名前のサイトに追加されます。
- VDI デスクトップ割り当ては、Universal Broker によって仲介されるマルチクラウド割り当てに変換されます。デフォルトの割り当て設定では、接続アフィニティは [最も近いサイト] に設定され、範囲は [サイト内] に設定されます。
- セッションベースのデスクトップとアプリケーションの割り当ては変更されません。移行後、これらの割り当て内のリソースは、Universal Broker によって仲介されます。
- この間、すべての割り当てはエンドユーザーが引き続き利用でき、すべてのアクティブなユーザーセッションは開いたままで完全に機能します。
注：移行のこの段階には通常約 10 分かかりますが、テナント環境に多数の割り当てが含まれている場合はさらに長くかかることがあります。進行状況を監視するには、通知バナーの [View のステータス] をクリックします。この段階が 1 時間以内に完了しない場合、移行はタイムアウトになり、障害としてマークされます。

移行のこの段階が完了すると、次のメッセージが表示されます。

注：移行のこの段階で障害が発生した場合、VMware のサポートが自動通知を受け取り、障害の原因を調査して修正します。詳細について、 [ブローカ] ページと、テナントに登録されているプライマリ E メールアカウントに送信される通知メッセージで確認できます。VMware のサポートが原因を修正した後、 [ブローカ] ページのリンクを使用して移行を再スケジュールできます。
コンソールに再度ログインしたら、Universal Broker サービスがセットアッププロセスを完了し、完全に有効になります。
すべてのグローバルリージョンの DNS サーバ間で DNS レコードが伝達されるため、通常、構成設定が Universal Broker サービスで完全に有効になるまでに最大 30 分かかります。ただし、システムとネットワークの状態、および環境内の割り当ての総数と専用のユーザーからデスクトップへのマッピングによっては、このプロセスが完了するまでに数時間かかる場合があります。このプロセスが 4 時間以内に完了しない場合、移行はタイムアウトになり、障害としてマークされます。
移行のこの段階では、割り当ての作成と編集を除いた、コンソールのすべての編集操作にアクセスできます。また、割り当ての仲介を行っているこの時間において、Universal Broker サービスを使用することはできません。

セットアップが正常に完了すると、コンソールのベルアイコンの下に通知メッセージが表示され、[設定] > [ブローカ] ページに [有効] ステータスが緑色のドットで表示されます。

これで、割り当ては Universal Broker によって仲介されるようになり、移行が完了します。

重要： Universal Broker のセットアップが失敗した場合、 [設定] > [ブローカ] 画面には赤のアラートアイコンで [エラー] ステータスが表示されます。構成エラーを修正し、 Universal Broker サービスをセットアップするには、 VMware ナレッジベースの記事 KB2006985の説明に従って、VMware サポートにお問い合わせください。

次のタスク

Horizon Cloud テナントと Workspace ONE Access の間に既存の統合がある場合は、Universal Broker の使用に合わせて統合を更新する必要があります。詳しい手順については、Universal Broker を使用した Horizon Cloud 環境 - テナントを Workspace ONE Access および Intelligent Hub サービスと統合するを参照してください。
サイトとマルチクラウド VDI 割り当ての設定を変更して、Universal Broker 機能をフル活用します。たとえば、既存の割り当てにポッドを追加したり、サイト設定を調整して、Universal Broker ブローカの割り当て方法を微調整することができます。詳細については、Horizon Cloud テナント環境でのマルチクラウド割り当ての作成および管理および「Universal Broker 環境でのサイトの操作」を参照してください。

Universal Broker への移行後のテナント環境の最新情報

この記事では、シングルポッドブローカから Universal Broker への移行が正常に完了した後に、Horizon Cloud テナント環境に表示される変更について説明します。これらの変更には、いくつかの新機能の動作と一部の機能制限が含まれます。

Universal Broker 環境での特定の機能制限の詳細については、Universal Broker - 機能に関する注意事項と既知の制限を参照してください。

エンドユーザー割り当ての変更

Microsoft Azure のすべてのポッドは、[Default-Site] という名前のサイトに追加されます。
VDI デスクトップ割り当ては、Universal Broker によって仲介されるマルチクラウド割り当てに変換されます。デフォルトの割り当て設定では、接続アフィニティは [最も近いサイト] に設定され、範囲は [サイト内] に設定されます。
注：特定のユーザーは、1 つの割り当てに複数のポッドのデスクトップが含まれていても、Universal Broker によって仲介された専用割り当てから最大で 1 つの割り当てられたデスクトップを受信できます。

重要：ユーザーが以前にシングルポッドブローカ環境の専用割り当てから複数の割り当てられたデスクトップを受け取った場合、 Universal Broker 環境への移行後にこれらのデスクトップにアクセスすることはできません。割り当てられたデスクトップにアクセスするには、ユーザーは Universal Broker の FQDN を使用する代わりにポッドの FQDN に直接接続できます。
セッションベースのデスクトップとアプリケーションの割り当ては、Universal Broker によって仲介されるようになりました。

同一名のデスクトッププールへの変更

ブローカの移行前にポッド全体のデスクトッププールが同じ名前であった場合は、異なる名前を持つように編集されます。この変更により、異なるポッドから一意の名前のデスクトッププールを Universal Broker によって仲介される単一の割り当てに追加できるようになります。

たとえば、ブローカ移行の前に次のシナリオを実行したとします。

Pod1 には、[TestPoolName] という名前のプールが含まれていました。
Pod2 にも、[TestPoolName] という名前のプールが含まれていました。

移行後、この例のプール名は次のように変更されます。

Pod1 では、プール名は [TestPoolName] のままです。
Pod2 では、プール名が [TestPoolName1] に変更されています。

仮想マシン名プリフィックスの変更

移行前のシングルポッドブローカ環境では、プールの仮想マシン名プリフィックスの最大文字数はカスタマイズ可能な 11 文字です。プール名を形成するには、11 文字のプリフィックスに連続する数字（最大 4 桁）が追加されます。

Universal Broker への移行後、仮想マシン名のプリフィックスは最大 9 文字のカスタマイズ可能な文字で構成できます。以前は 9 文字を超えていた仮想マシン名プリフィックスは、移行後に自動的に切り詰められます。

Universal Broker 環境でプール名を形成するには、9 文字のプリフィックスに次の文字が追加されます：2 つのランダムな英数字またはアルファベット文字とその後に続く連続する数字（最大 4 桁）。

複数の割り当てで同じ仮想マシン名プリフィックスが使用されている場合、割り当ての 1 つを編集しようとするとエラーが発生する場合があります。エラーを解決するには、編集ウィザードで割り当ての仮想マシン名プリフィックスを変更してください。

注：デスクトッププールの構成で、 [デスクトップの最大数] オプションが 0 に設定されている場合、移行後に仮想マシン名のプリフィックスとプール名は変更されずに Horizon Universal Console に表示されます。コンソールを更新して新しい仮想マシン名プリフィックスとプール名を表示するには、編集ウィザードを使用して移行された割り当てを更新します。

移行後の機能に関する考慮事項

以下の考慮事項は、Universal Broker への移行後の特定の機能に該当するものです。

カスタマイズ割り当て（URL リダイレクト割り当てとも呼ばれる）はサポートされません。
ポッドがマニフェスト 2474.0 より前のバージョンで実行されている場合、タスクのキャンセル機能はサポートされません。この機能を使用するには、ポッドをマニフェスト 2474.0 以降にアップグレードする必要があります。
Horizon Cloud on Microsoft Azure 環境に Workspace ONE Access との既存の移行前統合がある場合は、Universal Broker の使用に対応するために、統合を移行後の状態に更新する必要があります。詳しい手順については、Universal Broker を使用した Horizon Cloud 環境 - テナントを Workspace ONE Access および Intelligent Hub サービスと統合するを参照してください。
この統合を更新する場合は、Horizon Universal Console の [クリーンアップ] ワークフローを使用して、それらの環境に含まれる既存の仮想アプリケーションのコレクションをクリーンアップする必要があることに注意してください。クリーンアップワークフローは、レガシーのポッドごとの仮想アプリケーションのコレクション機能ではなく、統合された Universal Broker と Workspace ONE Access および Intelligent Hub サービスの最新機能を使用して、同じアプリケーションが Workspace ONE Access および Intelligent Hub サービスで引き続き機能するようになります。VMware Workspace ONE Access 製品チームが確認したように、Universal Broker が Horizon Cloud on Microsoft Azure 展開で使用される場合、VMware Workspace ONE Access 製品の仮想アプリケーションのコレクション機能はその構成でサポートされません。この理由は、Universal Broker が古いスタイルのポッドごとの仲介よりも新しい仲介テクノロジーであるためです。つまり、Universal Broker と Workspace ONE Access の統合は、レガシーのポッドごとの仮想アプリケーションのコレクションよりも優先して使用されます。したがって、Universal Broker には、Horizon Cloud on Microsoft Azure 環境向けの仮想アプリケーションのコレクションの概念はありません。

重要：ポッドがマニフェスト 2474.0 より前のバージョンで実行されている場合、インベントリ停止の削除保護機能はサポートされません。この機能を使用するには、ポッドをマニフェスト 2474.0 以降にアップグレードする必要があります。

たとえば、ポッドがマニフェスト 2474.0 より前のバージョンで実行され、移行前に削除保護が有効になっている場合、この機能は移行後に機能を停止します。その後、ポッドをマニフェスト 2474.0 以降にアップグレードすると、削除保護機能が再度機能します。