このワークフローでは、ポッド マネージャ ベースのポッドのデプロイから仮想デスクトップおよびアプリケーションの構成までの、第 1 世代 Horizon Universal Console の概要レベルの手順について説明します。エンド ユーザーが資格のある仮想デスクトップとアプリケーションを起動すると、手順は終了します。

重要: この情報は、第 1 世代の制御プレーンで第 1 世代のテナント環境にアクセスできる場合にのみ適用されます。 KB-92424 で説明されているように、第 1 世代の制御プレーンは提供終了 (EOA) となりました。詳細については、該当記事を参照してください。
注: このワークフローは、特に Horizon Cloud on Microsoft Azure のポッド マネージャ テクノロジーに基づいたポッドに関するもので、 Horizon Connection Server テクノロジーを使用した Horizon ポッドのデプロイに関するものではありません。
重要: 管理コンソールの表示は動的で、現在のサービス レベルで利用可能な機能が反映されます。ただし、ポッドのソフトウェアの最新レベルにまだ更新されていないクラウド接続されたポッドがある場合は、コンソールには最新のポッド ソフトウェア レベルに依存する機能は表示されません。また、特定のリリースでは、 Horizon Cloud に個別にライセンスされた機能または特定のテナント アカウント構成でのみ使用可能な機能が含まれる場合があります。お持ちのライセンスまたはテナント アカウント構成にそのような機能の使用が含まれる場合のみ、コンソールにその機能に関連する要素が動的に反映されます。例については、 Horizon Cloud での管理タスクに使用されるクラウドベースのコンソールのツアーを参照してください。

使用したい機能が管理コンソール内に見つからない場合は、VMware アカウントの担当者に問い合わせて、お持ちのライセンスおよびテナント アカウント構成にその機能を使用する資格が付与されているか確認してください。

  1. 前提条件に従って準備します。新しいポッド デプロイの VMware Horizon Cloud Service on Microsoft Azure 要件チェックリストを参照してください。
  2. Horizon Cloud 以外の準備タスクを実行します。Horizon Cloud ポッドを Microsoft Azure にデプロイする前の準備を参照してください。
  3. ポッドをデプロイするための DNS、ポート、およびプロトコルの要件に従います。Microsoft Azure での Horizon Cloud ポッドの DNS の要件および2019 年 9 月のリリースのマニフェスト以降での Horizon Cloud ポッドのポートとプロトコルの要件を参照してください。
  4. Horizon Universal Console にログインし、ウィザードを実行してポッドをデプロイします
  5. Horizon 制御プレーンで Active Directory ドメインを登録します。ここでは、サービス アカウントの名前を提供することも含まれます。これらのサービス アカウントが、Horizon Cloud の運用に必要なサービス アカウントで説明されている要件を満たしていることを確認します。
  6. 管理コンソールに対する認証と管理コンソールでの操作の実行について、組織内のメンバーに適切なロールを割り当てます。Horizon Cloud で使用されるロールには 2 つのタイプがあります。クラウドベースのコンソールを使用して Horizon Cloud 環境で作業するためにユーザーに付与する 2 種類のロールに関するベスト プラクティスを参照してください。
  7. テナントの Universal Broker 構成を完了します。Universal Broker 設定の構成を参照してください。
  8. DNS サーバに必要な CNAME レコードを作成します。Universal Broker に対するこれらの CNAME および CNAME レコード要件の目的については、DNS サーバでマッピングする Horizon Cloud ポッドのゲートウェイのロード バランサ情報の取得方法およびUniversal Broker 設定の構成を参照してください。
    注: 構成の Azure ロード バランサにプライベート IP アドレスを使用する外部ゲートウェイ構成がある場合は、そのプライベート IP アドレスへのインターネット トラフィックを管理するファイアウォールまたは NAT があることが必須です。そのファイアウォールまたは NAT は、パブリック IP アドレスを提供し、外部ゲートウェイ構成のデプロイ時に指定された FQDN がパブリックに解決可能になるように構成される必要があります。制御プレーンは、外部ゲートウェイに対して指定された FQDN と通信できる必要があります。
  9. オプション:Horizon Cloud テナント アカウントが VMware Cloud Services エンゲージメント プラットフォームにまだオンボーディングされていない場合は、ここでオンボーディングすることを推奨します。クラウドベースのコンソールを使用して Horizon Cloud テナントを VMware Cloud Services エンゲージメント プラットフォームにオンボーディングするを参照してください。
  10. ゴールド イメージを作成します。ゴールド イメージの作成は、マルチステップ プロセスで行います。Horizon Cloud テナントで使用できるゴールド イメージを作成するさまざまな方法の概要については、Microsoft Azure に Horizon Cloud ポッドのデスクトップ イメージを作成を参照してください。ゴールド イメージの作成は、ベース仮想マシンのインポートから開始します。このベース仮想マシンは、ビジネスおよびエンド ユーザーのニーズに合わせてカスタマイズします。
  11. イメージが最終的に意図するエンドユーザー割り当てのタイプに応じて、必要に応じて次の手順の 1 つ以上を実行します。
  12. そのイメージを、割り当て可能なイメージ(イメージのシーリングまたは公開とも呼ばれる)に変換します。構成済み仮想マシンを割り当て可能なイメージに変換するを参照してください。
  13. 公開済みのマルチセッション イメージからセッション デスクトップとリモート アプリケーションをプロビジョニングするには、次の手順を実行します。
    1. セッション デスクトップを提供するデスクトップ ファームを作成し、エンド ユーザーにこれらのデスクトップを使用する資格を付与するための割り当てを作成します。ファームの作成およびRDSH セッション デスクトップ割り当ての作成を参照してください。
    2. リモート アプリケーションを提供するアプリケーション ファームを作成し、アプリケーション インベントリにアプリケーションを追加してから、エンド ユーザーにこれらのリモート アプリケーションを使用する資格を付与するための割り当てを作成します。ファームの作成RDSH ファームからの新しいリモート アプリケーションのインポート、およびリモート アプリケーション割り当ての作成を参照してください。
  14. 公開済みの単一セッション VDI デスクトップ イメージから単一セッション VDI デスクトップをプロビジョニングするには、専用またはフローティング VDI デスクトップ割り当てを作成します。これらのデスクトップ割り当ての作成については、Microsoft Azure での Horizon Cloud 環境のポッドのデスクトップ割り当てについてとそのセクションを参照してください。
  15. App Volumes アプリケーションをエンドユーザーにプロビジョニングするには、App Volumes アプリケーションをアプリケーション インベントリに追加し、エンドユーザーにそれらのアプリケーションを使用する資格を与えるアプリケーション割り当てを作成します。次に、デスクトップ割り当てを作成し、エンド ユーザーにそれらのアプリケーションをベース デスクトップで使用できる資格を付与します。アプリケーション割り当てにより、ユーザーは資格が付与されたデスクトップの Windows オペレーティング システム内で、ユーザーに資格が割り当てられた App Volumes アプリケーションを使用できるようになります。App Volumes アプリケーション - 概要と前提条件を参照してください。
  16. デプロイに 2 要素認証構成がある場合は、次のタスクを実行する必要があります。
    • ポッドの外部ゲートウェイに 2 要素認証が構成され、ゲートウェイの Unified Access Gateway インスタンスがデプロイされているのと同じ VNet トポロジ内で 2 要素認証サーバにアクセスできない場合は、外部ゲートウェイのロード バランサの IP アドレスからの通信を許可するようにその 2 要素認証サーバを構成します。

      このシナリオでは、ゲートウェイ展開と同じ VNet トポロジ内で 2 要素認証サーバにアクセスできないため、Unified Access Gateway インスタンスは、そのロード バランサ アドレスを使用してそのサーバとの接続を試みます。その通信トラフィックを許可するには、その外部ゲートウェイのリソース グループにあるロード バランサ リソースの IP アドレスが、確実に 2 要素認証サーバの構成でクライアントまたは登録されたエージェントとして指定されているようにします。この通信を許可する方法の詳細については、お使いの 2 要素認証サーバのドキュメントを参照してください。

    • 同じ VNet トポロジ内で 2 要素認証サーバにアクセスできる場合は、Microsoft Azure でのデプロイの Unified Access Gateway インスタンス用に作成された適切な NIC からの通信を許可するように 2 要素認証サーバを構成します。

      ネットワーク管理者が、展開に使用される Azure VNet トポロジとそのサブネットに対する 2 要素認証サーバのネットワーク可視性を決定します。2 要素認証サーバは、ネットワーク管理者が 2 要素認証サーバにネットワークの可視性を与えたサブネットに対応する Unified Access Gateway インスタンスの NIC の IP アドレスからの通信を許可する必要があります。

      Microsoft Azure のゲートウェイのリソース グループには、そのサブネットに対応する 4 つの NIC があり、そのうち 2 つが 2 個の Unified Access Gateway インスタンスに対して現在アクティブです。もう 2 つはアイドル状態で、ポッドとそのゲートウェイが更新を完了した後にアクティブになります。

      実行中のポッド操作のため、および各ポッドの更新後のために、ゲートウェイと 2 要素認証サーバ間の通信トラフィックをサポートするには、これらの 4 つの NIC の IP アドレスがそのサーバ構成でクライアントまたは登録されたエージェントとして指定されていることを確認します。この通信を許可する方法の詳細については、お使いの 2 要素認証サーバのドキュメントを参照してください。

    これらの IP アドレスを取得する方法については、必要な Horizon Cloud ポッド ゲートウェイ情報での 2 要素認証システムの更新を参照してください。

上記のワークフローの手順が完了したら、Universal Broker の仲介 FQDN をエンド ユーザーに提供します。エンド ユーザーは Horizon Client または Horizon HTML Access(Web クライアント)でその仲介 FQDN を使用して、使用資格が付与されたデスクトップとリモート アプリケーションを起動します。

各ワークフロー手順を実行する方法の詳細については、上記の各手順にリンクされたトピックを参照してください。