このトピックでは、Horizon Cloud テナントのブローカ移行プロセスと、移行を実行することで得られるメリットについて説明します。シングルポッド ブローカと Universal Broker 環境の違い、およびブローカの移行前、移行中、移行後に想定される点について説明します。
ブローカの移行プロセスについて
ブローカの移行が完了すると、Horizon Cloud テナント環境はシングルポッド仲介の使用から Universal Broker の使用に変わり、エンドユーザー割り当てからリソースを仲介します。新しいテナント全体のブローカとして、Universal Broker はユーザーの接続要求を管理し、要求された割り当てから最適なリソースにルーティングします。
ブローカ移行プロセスでは、エンド ユーザーの割り当てに次の変更が加えられます。
- VDI デスクトップ割り当ては、Universal Broker によって仲介されるマルチクラウド割り当てに変換されます。マルチクラウド割り当てには、複数のポッドからの VDI デスクトップを含めることができます。
- セッションベースのデスクトップとアプリケーションの割り当ては変更されません。セッションベースのデスクトップまたはアプリケーションの割り当てには、シングル ポッドのリソースのみを含めることができますが、割り当ては Universal Broker によって仲介されるようになりました。
移行機能は、環境で現在シングルポッド仲介を使用しており、 Horizon Cloud - Universal Broker に移行するためのシステム要件に記載されている前提条件を満たしている場合に使用できます。
Universal Broker への移行が必要な理由
Universal Broker の使用に移行すると、主に次のようなメリットが得られます。
- 複数のポッドからの VDI デスクトップを使用したエンド ユーザー割り当て
シングルポッド仲介では、VDI 割り当て内のすべてのデスクトップが同じポッドから取得されている必要があります。デスクトップ仲介はポッドごとに行われます。
Universal Broker を使用すると、マルチクラウド割り当てとも呼ばれる複数のポッドからの VDI デスクトップの割り当てを作成できます。エンド ユーザーは割り当てにアクセスし、その割り当てに含まれる任意のポッドからデスクトップを受信できます。詳細については、 Horizon Service Universal Broker の概要 とそのサブトピックを参照してください。
セッションベースのデスクトップとアプリケーションの割り当てを以前と同様に引き続き使用することもできます。違いは、これらの割り当てからのセッションベースのデスクトップとアプリケーションが、ポッドごとの仲介ではなく、Universal Broker によって仲介されることです。
- すべてのリモート リソースに対する単一の接続 FQDN
シングルポッド仲介を使用する場合、エンド ユーザーは各ポッドの完全修飾ドメイン名 (FQDN) に個別に接続して、そのポッドからの割り当てにアクセスする必要があります。仲介はポッドごとに行われます。
Universal Broker を使用すると、ユーザーは 1 つの FQDN に接続することですべての割り当てにアクセスできます。FQDN は Universal Broker 構成で定義します。ユーザーは、単一の FQDN を使用して、環境内の任意のサイトから参加しているすべてのポッド(Microsoft Azure の Horizon Cloud ポッドとvSphereベースの 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 テナントと Omnissa Access の間に既存の統合がある場合は、Universal Broker の使用に合わせて統合を更新する必要があります。詳細な手順については、 Universal Broker を使用した Horizon Cloud 環境 - テナントを Omnissa Access および Intelligent Hub サービスと統合するを参照してください。
メモ: Access 製品チームが確認したように、Universal Broker が Horizon Cloud on Microsoft Azure デプロイで使用されている場合、Access 製品の仮想アプリケーションのコレクション機能はその構成でサポートされません。これは、Universal Broker が古いスタイルのポッドごとの仲介よりも新しい仲介テクノロジーであるためです。つまり、Universal Broker と 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 デプロイで Access および Intelligent Hub サービスを使用する予定の場合、コンソールの クリーンアップ アクションの一部としての統合プロセスで、これらのデプロイに含まれる既存の仮想アプリケーションのコレクションをクリーンアップする必要があります。クリーンアップ アクティビティを完了すると、統合された Universal Broker と Access および Intelligent Hub サービスの最新機能を使用して、同じアプリケーションが 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 テナントと Access の間に既存の統合がある場合は、すべてのポッドがマニフェスト 2474.0 以降で実行されている必要があります。ブローカの移行が完了したら、 Universal Broker を使用した Horizon Cloud 環境 - テナントを 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 要素認証を使用する場合は、すべてのポッドのすべての外部 Unified Access Gateway インスタンスを同じ RADIUS 認証サービスを使用するように構成する必要があります。これには、管理対象状態にあるテナントの Horizon ポッドがすべて含まれます。
メモ: ポッドに内部 Unified Access Gateway インスタンスのみが含まれている場合、Universal Broker は [ブローカ] ページの ネットワーク範囲 タブで定義されたネットワーク ポリシーをオーバーライドし、IP アドレスに関係なく、すべてのユーザーをその Unified Access Gateway インスタンスにルーティングします。
Universal Broker をサポートするための DNS、ポート、およびプロトコルの要件
次の要件を確認します。
- 各ポッドは、地域の Universal Broker インスタンスに必要な DNS 名が解決可能であり、アクセス可能であるように構成されています。Microsoft Azure の Horizon Cloud ポッドの DNS 要件の「ポッドのデプロイと操作の DNS の要件」の表を参照してください。
- 各ポッドは、 Horizon Cloud ポッドのポートとプロトコルの要件の「Universal Broker で必要なポートとプロトコル」セクションの説明に従って、必要なポートとプロトコルで構成されます。
Universal Broker をサポートするための FQDN の要件
シングルポッド仲介では、エンド ユーザーは各ポッドの完全修飾ドメイン名 (FQDN) に個別に接続して、そのポッドからの割り当てにアクセスします。
Universal Broker への移行後、ユーザーは Universal Broker クラウド サービスの 1 つの FQDN に接続することで、環境内の任意のサイトの任意のポッドから任意の割り当てにアクセスできます。Universal Broker は、要求を処理できる最も適切なポッドの個々の FQDN に、各ユーザーの要求をルーティングします。
シングル Universal Broker から Universal Broker への移行のスケジュール設定と完了の説明に従って、Universal Broker 構成設定で Universal Broker FQDN を指定します。標準システム提供のドメインに有効なサブドメインをプリフィックス付けて FQDN を作成するか、完全にカスタムの FQDN を構成することができます。
メモ: カスタム FQDN を構成する場合は、この FQDN が会社または組織を表すことに注意してください。ユーザーがカスタム FQDN で指定されたドメイン名の所有者であり、そのドメインを検証する証明書を提供でき、カスタム FQDN を使用するための適切な権限を持っていることを確認します。Universal Broker のカスタム FQDN は一意であり、ポッド内のすべての Unified Access Gateway インスタンスの FQDN とは異なるものにする必要があります。
ブローカ移行の計画と準備
ブローカの移行には、ネットワークと割り当てのワークフローへの重要な変更が含まれるため、新しいワークフローに備えて環境とユーザーを準備するために必要なアクションを実行してください。移行のユースケースに基づいた適切な準備と変更管理手順については、次のプランニング ガイドを参照してください。
| 移行の使用事例 | 計画と準備の手順 |
|---|---|
| 環境が単一のポッドで構成されており、そのポッドの既存の FQDN を Universal Broker FQDN として使用する |
|
| 環境が複数のポッドで構成されており、新しい FQDN を Universal Broker FQDN として構成したい |
|
シングルポッド ブローカから Universal Broker への移行をスケジュール設定して完了する
このトピックでは、Universal Broker への移行のスケジュール設定、準備、完了の手順について説明します。Universal Broker サービスを設定し、移行の開始日時を定義し、プロセスの段階を円滑に移動して移行を成功させる方法については、次の手順を参照してください。
ブローカの移行をスケジュール設定する準備ができると、Horizon Universal Console の上部に スケジュール ボタンを含む通知バナーが表示されます。
メモ: バナーにエラー状態が表示され、移行がスケジュール設定できない場合、移行の前提条件の 1 つ以上を満たしていない可能性があります。バナーの エラーの表示 をクリックし、ブローカ ページの 移行が必要 リンクの横にあるエラー アイコンをクリックして、エラー状態の詳細を表示します。移行をスケジュール設定する前に、エラー状態をクリアするための必要な手順を実行する必要があります。
前提条件
テナント環境が、 Universal Broker に移行するための Horizon Cloud - システム要件に記載されているすべての前提条件を満たしていることを確認します。
手順
- ブローカ移行の通知バナーで スケジュール をクリックします。
このアクションにより、[ブローカ] ページにリダイレクトされます。このページには、現在テナントでシングルポッド ブローカが有効になっていることが示され、ブローカの移行をスケジュール設定するためのリンクが表示されます。
![移行前の [ブローカ] ページ。](images/GUID-3F644679-6C60-4799-A0B5-7EB5CE16D36C-low.png "移行前の [ブローカ] ページ。")
- ブローカ ページで、スケジュール リンクをクリックします。
Universal Broker の構成ウィザードが表示されます。Microsoft Azure のポッドに Universal Broker を設定し、Universal Broker への移行をスケジュール設定するには、このウィザードの手順を完了する必要があります。
- ウィザードの FQDN ページで、仲介接続の FQDN を構成します。これらの設定は、エンド ユーザーが Universal Broker によって割り当てられたリソースにアクセスするために使用する専用接続アドレスを定義します。
メモ: サブドメインまたは FQDN 設定を変更すると、すべての DNS サーバで変更が有効になるまでに時間がかかることがあります。
-
タイプ には、 Omnissa 提供 または カスタム の完全修飾ドメイン名 (FQDN) を選択します。
-
選択した FQDN タイプの追加設定を指定します。
- Omnissa が提供 タイプを選択した場合は、次のように設定を指定します。
| 設定 | 説明 |
|---|---|
| サブドメイン | 会社または組織を表すネットワーク構成内の有効なサブドメインの一意の DNS 名を入力します。このサブドメインは、仲介の FQDN を形成するためにシステム提供のドメインの先頭に付けられます。
注: 一部の文字列は、システムによって禁止または予約されています。この文字列のカテゴリには、 ただし、許可されていない名前をこのフィールドに入力すると、システムはその時点で入力を検証しません。ウィザードの最終サマリ手順に到達したときにのみ、システムはここで入力した名前を検証し、入力が禁止された名前のいずれかと一致する場合はエラーを表示します。その場合は、より一意の名前をここに入力します。 |
| 仲介の FQDN | この読み取り専用フィールドには、構成済みの FQDN が表示されます。FQDN は https://your-sub-domain.firstgen.omnissahorizon.com の形式を使用します。
この FQDN をエンド ユーザーに提供して、エンド ユーザーが Horizon Client を使用して Universal Broker サービスに接続できるようにします。Universal Broker は、この FQDN の DNS および SSL 検証を管理します。 |
- カスタム タイプを選択した場合は、次のように設定を指定します。
| 設定 | 説明 |
|---|---|
| 仲介の FQDN | エンド ユーザーが Universal Broker サービスへのアクセスに使用するカスタムの FQDN を入力します。カスタム FQDN は、 サービスへの接続を完了する自動生成されたシステム提供の FQDN のエイリアスとして機能します。
カスタム FQDN で指定されたドメイン名の所有者であり、そのドメインを検証できる証明書を提供する必要があります。 注: カスタム FQDN は、接続 URL とも呼ばれ、会社または組織を表します。このカスタム FQDN を使用するための適切な権限があることを確認します。
注: カスタム FQDN は一意で、ポッド内のすべての Unified Access Gateway インスタンスの FQDN とは異なるものにする必要があります。
重要: カスタム FQDN を Universal Broker サービスの内部接続アドレスを表すシステム提供の FQDN にマッピングする CNAME レコードを DNS サーバに作成する必要があります。たとえば、レコードは |
| 証明書 |
参照 をクリックし、仲介の FQDN を検証する証明書(パスワード保護された PFX 形式)をアップロードします。証明書は次の基準をすべて満たす必要があります。
Universal Broker サービスは、この証明書を使用して、クライアントとの信頼された接続セッションを確立します。 |
| パスワード | PFX 証明書ファイルのパスワードを入力します。 |
| Omnissa 提供の FQDN | この読み取り専用フィールドには、仲介サービス用に自動的に生成されるシステム提供の FQDN が表示されます。FQDN の形式は https://auto-generated-string.firstgen.omnissahorizon.com です。
このシステム提供の FQDN はエンド ユーザーには表示されず、Universal Broker サービスの内部接続アドレスを表します。カスタム FQDN は、このシステム提供の FQDN のエイリアスとして機能します。 重要: カスタム FQDN をシステム提供の FQDN にマッピングする CNAME レコードを DNS サーバに作成して、エイリアスの関連付けを設定する必要があります。たとえば、レコードは |
-
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 インスタンスを削除すると、ユーザーは参加しているポッドからプロビジョニングされたリソースにアクセスできません。
| 設定 | 説明 |
|---|---|
| 2 要素認証 | 2 要素認証を使用するには、このトグルを有効にします。 トグルを有効にすると、2 要素認証を構成するための追加オプションが表示されます。 |
| ユーザー名を維持 | Universal Broker への認証中にユーザーの Active Directory ユーザー名を維持するには、このトグルを有効にします。有効にすると、次のようになります。
|
| タイプ |
Active Directory のユーザー名とパスワードに加えて、Universal Broker がエンド ユーザーで使用する認証方法を指定します。ユーザー インターフェイスには、 RADIUS と RSA SecurID の 2 つの選択肢が表示されます。
この設定は、テナント全体に適用されます。エンドユーザー クライアントでの動作は、次のように、テナントのポッド フリートの構成と、ポッドのゲートウェイで構成されている 2 要素認証タイプによって異なります。
|
| ヒント テキストを表示 | このトグルを有効にすると、クライアントのログイン画面に表示されるテキスト文字列を構成して、ユーザーに追加の認証方法の認証情報の入力を求めることができます。 |
| カスタム ヒントのテキスト |
クライアントのログイン画面に表示するテキスト文字列を入力します。指定されたヒントは、エンド ユーザーに DisplayHint のユーザー名とパスワードを入力してください として表示されます。ここで、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というプロンプトが表示されます。 |
| 2 要素認証をスキップ |
Universal Broker サービスに接続している内部ネットワーク ユーザーの 2 要素認証をバイパスするには、このトグルを有効にします。Universal Brokerの内部ネットワーク範囲の定義の説明に従って、内部ネットワークに属するパブリック IP アドレス範囲が指定されていることを確認します。
|
| パブリック IP アドレス範囲 | このフィールドは 2 要素認証をスキップ が有効になっている場合に表示されます。 [ブローカ] ページの [ネットワーク範囲] タブで 1 つ以上のパブリック IP アドレス範囲がすでに指定されている場合、このフィールドは読み取り専用で、それらの IP アドレス範囲が一覧表示されます。 [ブローカ] ページの [ネットワーク範囲] タブにパブリック IP アドレス範囲がまだ指定されていない場合は、このフィールドを使用して、内部ネットワークを表すパブリック IP アドレス範囲を指定し、それらの範囲からのトラフィックの 2 要素認証プロンプトをスキップできます。Universal Broker は、これらのいずれかの範囲内の IP アドレスから接続しているユーザーを内部ユーザーと見なします。 これらの範囲を指定する目的の詳細については、 Universal Broker の内部ネットワーク範囲の定義を参照してください。 |
2 要素認証の構成が完了したら、 次へ をクリックしてウィザードの次のページに進みます。
- 構成ウィザードの 設定 ページで、Horizon Client の 期間 設定を構成します。
これらのタイムアウト設定は、Universal Broker によって割り当てられたデスクトップと Horizon Client 間の接続セッションに適用されます。これらの設定は、割り当てられたデスクトップのゲスト OS へのユーザーのログイン セッションには適用されません。Universal Broker は、これらの設定で指定されたタイムアウト条件を検出すると、ユーザーの Horizon Client 接続セッションを終了します。
| 設定 | 説明 |
|---|---|
| クライアントのハートビート間隔 | Horizon Client ハートビートの間隔(分単位)とユーザーの Universal Broker への接続状態を制御します。これらのハートビートは、Horizon Client 接続セッション中に経過したアイドル時間を Universal Broker に報告します。 アイドル時間は、Horizon Client を実行しているエンドポイント デバイスとの対話式処理がない場合に測定されます。このアイドル時間は、ユーザーに割り当てられたデスクトップの基盤となるゲスト OS へのログイン セッションが非アクティブ状態であることの影響を受けません。 大規模なデスクトップ展開では、 Client ハートビート間隔 を増やすと、ネットワーク トラフィックが減少し、パフォーマンスが向上する場合があります。 |
| クライアント アイドル ユーザー | Horizon Client と Universal Broker 間の接続セッションで許可される最大アイドル時間 (分単位)。 最大時間に達すると、ユーザーの認証期間が期限切れになり、Universal Broker はアクティブなすべての Horizon Client セッションを閉じます。接続セッションを再度開くには、ユーザーは Universal Broker ログイン画面で認証情報を再入力する必要があります。 注: 割り当てられたデスクトップからユーザーが予期せず切断されないようにするには、 Client アイドル ユーザー タイムアウトを Client ハートビート間隔の少なくとも 2 倍の値に設定します。 |
| クライアント ブローカ セッション | ユーザーの認証の有効期限が切れるまでに Horizon Client 接続セッションに許可される最大時間(分)。この時間は、ユーザーが Universal Broker に対して認証される時点から開始します。セッション タイムアウトが発生しても、ユーザーは割り当てられたデスクトップで作業を続行できます。ただし、Universal Broker との通信を必要とするアクション(設定の変更など)を実行すると、Horizon Client は Universal Broker 認証情報を再入力するように求めます。 注:Client ブローカ セッション のタイムアウトは Client ハートビート間隔 値と Client アイドル ユーザー のタイムアウトの合計以上にする必要があります。 |
| クライアント認証情報のキャッシュ タイムアウト | ユーザーのログイン認証情報をクライアント システムのキャッシュに保存するかどうかを制御します。キャッシュにユーザー認証情報を保存するには、 1 と入力します。キャッシュにユーザー認証情報を保存しない場合は、 0 を入力します。 |
期間の設定が完了したら、 次へ をクリックしてウィザードの次のページに進みます。
- ウィザードの スケジュール ページで、コントロールを使用して、ブローカの移行を実行する 日付 および 開始時刻 を指定します。
![Universal Broker 構成ウィザードの [スケジュール] ページ。](images/GUID-735C4B6E-1055-4E09-A0B9-F2531DEBF598-low.png "Universal Broker 構成ウィザードの [スケジュール] ページ。")
現在の現地時間より少なくとも 1 時間早く、現在の日付から最大 3 か月前の開始時刻をスケジュール設定できます。開始時刻は正時に発生する必要があります。
開始時刻を設定するときは、移行が中断されることなく進行するために十分な時間を確保してください。
完了したら、 次へ をクリックして、Universal Broker 構成ウィザードの次の手順に進みます。
メモ: 指定した開始時刻が使用できないことを示すメッセージがコンソールに表示された場合は、 日付 と 開始時刻 の設定に戻り、移行の別の時間を指定します。
- [サマリ] ページで設定を確認し、終了 をクリックして Universal Broker の設定とスケジュール設定を保存します。
移行が正常にスケジュール設定されたことを確認するメッセージが表示されます。
![移行をスケジューリングした後の通知バナーと [ブローカ] ページ。](images/GUID-25CA5AE1-C9A9-4FEE-A0E1-833BE669A20F-low.png "移行をスケジューリングした後の通知バナーと [ブローカ] ページ。")
移行がスケジュール設定された後:
- [ブローカ] ページには、今後の移行に関する詳細が表示されます。開始時刻が 1 時間以上離れている場合は、 スケジュール設定 リンクをクリックして移行のスケジュールを再設定できます。
- スケジュール設定された移行をキャンセルする場合、または 1 時間以内に開始される移行のスケジュールを変更する場合は、Horizon Cloud サポートにお問い合わせください。Horizon Cloud サポートは、15 分以内に開始される移行をキャンセルまたは再スケジュールすることはできません。
- コンソールには、開始時刻に達するまで、今後の移行に関する通知バナーが表示され続けます。バナーの 詳細表示 をクリックすると、ブローカ ページにリダイレクトされます。
- 今後の移行に関する通知メッセージとリマインダ メッセージは、テナントに登録されているプライマリ メール アカウントに送信されます。
- 移行が開始する少なくとも 15 分前までに、次の準備タスクを完了してください。移行中は、コンソールの編集操作にアクセスできません。
- コンソールで進行中のすべての操作を完了し、保持する変更を保存します。
- すべての構成ウィザードとダイアログ ボックスを閉じます。 重要: 移行期間中、Microsoft Azure のすべての Horizon Cloud ポッドがオンラインで、健全な準備完了の状態であることを確認します。Universal Broker サービスは、移行のブローカ有効化ステージを完了するために、ポッドと通信し、ポッドでいくつかの構成手順を実行する必要があります。いずれかのポッドがオフラインまたは使用できない場合、移行は失敗します。
重要: Microsoft Azure の Horizon Cloud ポッドと vSphere ベースの SDDC プラットフォームの Horizon ポッドの両方で構成されるハイブリッド環境がある場合、移行中は Horizon ポッドで Universal Broker サービスを使用できません。また、この間、Horizon ポッドの状態を監視対象から管理対象に変更することはできません。
- 移行が始まる少し前に、画面のプロンプトの指示に従ってコンソールからログアウトし、再度ログインします。
- 移行の第 1 段階を中断せずに続行できるようにします。
移行のこの段階では、次のようになります。
- コンソールの編集コントロールにアクセスできず、コンソールには移行が進行中であることを示すバナーが表示されます。
- Microsoft Azure のすべてのポッドは、 Default-Site という名前のサイトに追加されます。
- VDI デスクトップ割り当ては、Universal Broker によって仲介されるマルチクラウド割り当てに変換されます。デフォルトの割り当て設定では、接続のアフィニティは 最も近いサイト に設定され、範囲は サイト内 に設定されています。
- セッションベースのデスクトップとアプリケーションの割り当ては変更されません。移行後、これらの割り当て内のリソースは Universal Broker によって仲介されます。
- この間、すべての割り当ては引き続きエンド ユーザーが使用でき、すべてのアクティブなユーザー セッションは開いたままで完全に機能します。 メモ: 移行のこの段階には通常約 10 分かかりますが、テナント環境に多数の割り当てが含まれている場合はさらに長くかかることがあります。進行状況を監視するには、通知バナーの ステータスの表示 をクリックします。この段階が 1 時間以内に完了しない場合、移行はタイムアウトになり、障害としてマークされます。
移行のこの段階が完了すると、次のメッセージが表示されます。
メモ: 移行のこの段階で障害が発生した場合、Horizon Cloud サポートは自動通知を受け取り、障害の原因を調査して修正します。詳細については、[ブローカ] ページ、およびテナントに登録されているプライマリ メール アカウントに送信される通知メッセージで確認できます。Horizon Cloud サポートが障害の原因を修正した後、[ ブローカ] ページのリンクを使用して移行を再スケジュールできます。
- コンソールに再度ログインしたら、Universal Broker サービスがセットアップ プロセスを完了し、完全に有効になります。
DNS レコードはすべてのグローバル リージョンの DNS サーバ間で伝達されるため、通常、Universal Broker サービスで構成設定が完全に有効になるまでに最大 30 分かかります。ただし、システムとネットワークの状態、および環境内の割り当ての総数と専用のユーザーからデスクトップへのマッピングによっては、このプロセスが完了するまでに数時間かかる場合があります。プロセスが 4 時間以内に完了しない場合、移行はタイムアウトになり、失敗としてマークされます。
移行のこの段階では、割り当ての作成と編集を除く、コンソールのすべての編集操作にアクセスできます。また、割り当ての仲介を行うこの間、Universal Broker サービスは使用できません。
セットアップが正常に完了すると、コンソールのベル アイコンの下に通知メッセージが表示され、 設定 > ブローカ ページに 有効 ステータスが緑色のドットで表示されます。
これで、割り当てが Universal Broker によって仲介され、移行が完了しました。
![Universal Broker が有効になっている [ブローカ] ページ。](images/GUID-67116750-F476-41A1-9FE5-EEF03B644F5E-low.png "Universal Broker が有効になっている [ブローカ] ページ。")
重要: Universal Brokerのセットアップに失敗すると、 設定 > ブローカ ページに赤のアラート アイコンで エラー ステータスが表示されます。構成エラーを修正して Universal Broker サービスを設定するには、 ナレッジベースの記事 2006985 の説明に従ってサポート リクエストを発行します。
次のタスク
- Horizon Cloud テナントと Access の間に既存の統合がある場合は、Universal Broker の使用に合わせて統合を更新する必要があります。詳細な手順については、 Universal Broker を使用した Horizon Cloud 環境 - テナントを 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 によって仲介されるマルチクラウド割り当てに変換されます。デフォルトの割り当て設定では、接続のアフィニティは 最も近いサイト に設定され、範囲は サイト内 に設定されています。
メモ: 特定のユーザーは、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 のデプロイに Access との移行前の既存の統合がある場合は、Universal Broker の使用に対応するために統合を移行後の状態に更新する必要があります。詳細な手順については、 Universal Broker を使用した Horizon Cloud 環境 - テナントを Omnissa Access および Intelligent Hub サービスと統合するを参照してください。
この統合を更新する場合は、Horizon Universal Console のクリーンアップ ワークフローを使用して、これらの環境に含まれる既存の仮想アプリケーションのコレクションをクリーンアップする必要があることに注意してください。クリーンアップ ワークフローでは、レガシーのポッドごとの仮想アプリケーションのコレクション機能ではなく、統合された Universal Broker および Access および Intelligent Hub サービスの最新機能を使用して、同じアプリケーションが Access および Intelligent Hub サービスで引き続き機能するようになります。Access 製品チームが確認したように、Universal Broker が Horizon Cloud on Microsoft Azure デプロイで使用されている場合、Access 製品の仮想アプリケーションのコレクション機能はその構成でサポートされません。これは、Universal Broker が古いスタイルのポッドごとの仲介よりも新しい仲介テクノロジーであるためです。つまり、Universal Broker と Access の統合は、レガシーのポッドごとの仮想アプリケーションのコレクションの使用よりも優先されます。したがって、Universal Broker には、Horizon Cloud on Microsoft Azure デプロイの仮想アプリケーションのコレクションの概念はありません。
重要: ポッドがマニフェスト 2474.0 より前のバージョンで実行されている場合、インベントリ停止の削除保護機能はサポートされません。この機能を使用するには、ポッドをマニフェスト 2474.0 以降にアップグレードする必要があります。
たとえば、ポッドがマニフェスト 2474.0 より前のバージョンで実行されていて、移行前に削除保護が有効になっている場合、この機能は移行後に機能を停止します。その後、ポッドをマニフェスト 2474.0 以降にアップグレードすると、削除保護機能が再び機能します。
このページは役に立ちましたか?