これは、ポッド デプロイヤを実行して、ポッド マネージャ ベースのポッドを Microsoft Azure のサブスクリプションにデプロイすることによって、最初のクラウド接続ポッドに到達したときの手順の大まかな概要を示しています。このポッド タイプは VMware Horizon Cloud ポッド マネージャ テクノロジーをベースとしています(Horizon Connection Server ソフトウェア コンポーネントをベースとした Horizon ポッドとは異なります)。最初のクラウド接続ポッドが完全にデプロイされ、ポッドの目的である Active Directory ドメインに Horizon Cloud を登録するための手順を完了すると、Horizon Cloud に提供されるすべての機能、特に VDI デスクトップのプロビジョニング、RDSH セッションベース デスクトップ、または RDSH ベースのリモート アプリケーションを、そのポッドからエンドユーザーに対して使用できます。Microsoft Azure のポッドで App Volumes の機能を使用するようにお客様のアカウントが構成されている場合は、これらの App Volumes 機能からアプリケーションをプロビジョニングし、エンドユーザーに付与することもできます。

重要: 以下のワークフローは、Azure VMware Solution (AVS) 上の Horizon ポッドには該当しません。AVS 上の Horizon ポッドは VMware SDDC 上の 1 つの Horizon ポッドになります。これは、Microsoft のドキュメント チュートリアル:Azure に Azure VMware Solution のプライベート クラウドをデプロイするに記載されているように、AVS が vSphere クラスタであることと、 vSphere クラスタが VMware SDDC (Software-Defined Data Center) の定義により VMware SDDC になることによります。Tech Zone の記事 Horizon on Azure VMware Solution Configurationおよび Horizon on Azure VMware Solution Architectureでは、AVS 上の Horizon ポッドの詳細について説明しています。

Microsoft Azure のポッドの概要については、Microsoft Azure 内の Horizon Cloud ポッドの概要を参照してください。

重要: 管理コンソールの表示は動的で、現在のサービス レベルで利用可能な機能が反映されます。ただし、ポッドのソフトウェアの最新レベルにまだ更新されていないクラウド接続されたポッドがある場合は、コンソールには最新のポッド ソフトウェア レベルに依存する機能は表示されません。また、特定のリリースでは、 Horizon Cloud に個別にライセンスされた機能または特定のテナント アカウント構成でのみ使用可能な機能が含まれる場合があります。お持ちのライセンスまたはテナント アカウント構成にそのような機能の使用が含まれる場合のみ、コンソールにその機能に関連する要素が動的に反映されます。例については、 Horizon Cloud での管理タスクに使用されるクラウドベースのコンソールのツアーを参照してください。

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

最初のクラウド接続ポッドをデプロイし、Horizon Universal Console のポッド デプロイ ウィザードを使用して Microsoft Azure にポッドをデプロイする場合は、次の手順を実行します。

  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. ポッドをデプロイします
  5. デプロイ済みのポッドで Active Directory ドメインを登録します。ここでは、サービス アカウントの名前を提供することも含まれます。これらのサービス アカウントが、Horizon Cloud の運用に必要なサービス アカウントで説明されている要件を満たしていることを確認します。
  6. 管理コンソールに対する認証と管理コンソールでの操作の実行について、組織内のメンバーに適切なロールを割り当てます。Horizon Cloud で使用されるロールには 2 つのタイプがあります。クラウドベースのコンソールを使用して Horizon Cloud 環境で作業するためにユーザーに付与する 2 種類のロールに関するベスト プラクティスを参照してください。
  7. まれな、通常ではない状況として、テナント環境に 1600.0 より古いマニフェストを実行している Microsoft Azure の Horizon Cloud ポッドがすでにある場合、ドメイン参加アカウントをメンバーとして含む Active Directory グループに Horizon Cloud スーパー管理者ロールを付与する必要があります。Active Directory グループの個人が Horizon Cloud テナント環境に対して認証された後、その個人に対して Horizon Universal Console のどの部分を有効にするかを制御するロールをそのグループに割り当てるを参照してください。
  8. ポッドによってプロビジョニングされたリソースをエンドユーザーに仲介するときに、テナントのポッドで使用する仲介のタイプを選択します。Universal Broker とシングルポッド仲介の概要のトピックおよびその関連トピックとサブトピックを参照してください。
    注目: 追加のポッドを Microsoft Azure にデプロイする前に、このブローカ選択手順を完了することをお勧めします。
  9. 前の手順に関連して、前の手順でシングルポッド ブローカ構成を選択し、ポッドで Workspace ONE Access を使用する予定がある場合、またはポッド ゲートウェイ構成を使用せずにポッドに直接接続する Horizon Clients がある場合は、次の手順を実行します。
    • DNS サーバで、完全修飾ドメイン名 (FQDN) をポッド マネージャの Microsoft Azure ロード バランサ IP アドレスにマッピングします。
    • そのマッピングされた FQDN に基づいて SSL 証明書を取得します。

    DNS でポッド マネージャの Microsoft Azure ロード バランサの IP アドレスにマッピングした FQDN に基づいて、SSL 証明書をポッドにアップロードします。これにより、ポッド マネージャ仮想マシンへの接続が信頼できる接続を確立します。このような接続には、マッピングした FQDN が付与されるユーザー用の Horizon Clients、および Workspace ONE Access とシングルポッド ブローカ構成のポッドを統合するときに使用される Workspace ONE Access Connector が含まれます。Workspace ONE Access Connector は、ポッド マネージャの Microsoft Azure ロード バランサ IP アドレスにマッピングされた FQDN を使用してポッドに接続する必要があります。

    注目: 環境がシングルポッド仲介用に構成され、 Workspace ONE Access をポッドと統合する場合は、ポッドに SSL 証明書をアップロードし、ポッドの Unified Gateway Access 構成ではなく、ポッドをポイントするように Workspace ONE Access Connector を構成する必要があります。

    ただし、DNS にマッピングされた FQDN に基づいて SSL 証明書をアップロードした場合、適切に構成された Workspace ONE Access を経由せずに、その FQDN をブラウザに直接入力して接続しようとすると、純粋な FQDN の使用がブラウザへの信頼されない接続として表示されることに注意してください。これは、単純にこの FQDN のブラウザへのロードは HTML Access (Blast) を使用した接続であり、HTML Access (Blast) がそのようにして動作するためです。その結果、この FQDN をブラウザにロードすると、信頼されていない証明書の一般的なエラーが表示されます。

    このタイプの構成に Workspace ONE Access がない場合に、HTML Access (Blast) を使用した接続(基本的にブラウザを使用)で、そのような信頼されていない証明書エラーが表示されるのを回避するには、ポッドにゲートウェイ構成を配置し、そのゲートウェイ構成のロード バランサと Unified Access Gateway インスタンスを使用する必要があります。インターネット上で FQDN を公開したくない場合は、内部 Unified Access Gateway 構成をデプロイできます。この内部 Unified Access Gateway 構成では、企業のネットワーク内にいるエンド ユーザーが接続できる Microsoft Azure 内部ロード バランサを使用しています。

  10. 前の手順で説明したユースケースのいずれかまたは両方を使うことを予定している場合は、管理コンソールのポッドの [サマリ] ページを使用して、SSL 証明書をポッドに直接アップロードします。Horizon Cloud ポッドのマネージャ仮想マシンでの SSL 証明書の構成を参照してください。
    ヒント: ポッドの Unified Access Gateway インスタンスに接続されたロード バランサを介してそれらのインスタンスに接続するというアクセスのユースケースのみをサポートする場合、ポッドに直接 SSL 証明書をアップロードする必要はありません。それでも、上記の手順とこの手順を実行することが推奨されるのは、その FQDN をユーザーに配信して、ユーザーが自分の Horizon Clients で入力したときに、それらのクライアントで信頼された接続が確立されるためです。また、上記の手順とこの手順を実行すると、FQDN がマッピングされ、SSL 証明書がポッドに配置されているため、シングルポッドブローカ環境のポッドをより早く Workspace ONE Access に統合することができます。
  11. オプション:Horizon Cloud テナント アカウントが VMware Cloud Services エンゲージメント プラットフォームにまだオンボーディングされていない場合は、ここでオンボーディングすることを推奨します。VMware Cloud Services エンゲージメント プラットフォームへのオンボーディングは、Microsoft Azure にデプロイされたポッドの Horizon インフラストラクチャの監視 機能を有効にするための前提条件です。クラウドベースのコンソールを使用して Horizon Cloud テナントを VMware Cloud Services エンゲージメント プラットフォームにオンボーディングするを参照してください。
  12. オプション:Horizon インフラストラクチャの監視 を有効にします。有効にするための前提条件は、Horizon Cloud テナントがVMware Cloud Services エンゲージメント プラットフォームにオンボーディングされていることです。Horizon インフラストラクチャの監視と Horizon Cloud 環境のポッドを参照してください。
  13. 基本イメージをインポートします。基本イメージをインポートするさまざまな方法については、Microsoft Azure に Horizon Cloud ポッドのデスクトップ イメージを作成を参照してください。
  14. Microsoft Azure に Horizon Cloud ポッドのデスクトップ イメージを作成で説明するように、基本イメージの作成に使用された方法によっては、新しいイメージ仮想マシンのエージェントが仮想マシンが作成されたポッド マネージャ仮想マシンとまだペアリングされていない場合があります。エージェントがペアリングされていないことを示すメッセージが表示された場合は、[インポートされた仮想マシン] ページの [エージェント ペアリングをリセット] アクションを使用してペアリングを完了します。
  15. イメージが最終的に意図するエンドユーザー割り当てのタイプに応じて、必要に応じて次の手順の 1 つ以上を実行します。
  16. そのイメージを、割り当て可能なイメージ(イメージのシーリングまたは公開とも呼ばれる)に変換します。構成済み仮想マシンを割り当て可能なイメージに変換するを参照してください。
  17. 公開済みのサーバ イメージからセッションベースの RDSH デスクトップとリモート アプリケーションをプロビジョニングするには:
    1. セッション デスクトップを提供するデスクトップ RDSH ファームを作成し、エンド ユーザーにこれらのデスクトップを使用する資格を付与するために割り当てを作成します。ファームの作成およびRDSH セッション デスクトップ割り当ての作成を参照してください。
    2. リモート アプリケーションを提供するためにアプリケーション RDSH ファームを作成し、アプリケーション インベントリにアプリケーションを追加してから、エンド ユーザーにこれらのリモート アプリケーションを使用する資格を付与するために割り当てを作成します。ファームの作成RDSH ファームからの新しいリモート アプリケーションのインポート、およびリモート アプリケーション割り当ての作成を参照してください。
  18. 公開済みの VDI デスクトップ イメージから VDI デスクトップをプロビジョニングするには、専用またはフローティング VDI デスクトップ割り当てを作成します。これらのデスクトップ割り当ての作成については、Microsoft Azure での Horizon Cloud 環境のポッドのデスクトップ割り当てについてとそのセクションを参照してください。
  19. App Volumes アプリケーションをエンドユーザーにプロビジョニングするには、App Volumes アプリケーションをアプリケーション インベントリに追加し、エンドユーザーにそれらのアプリケーションを使用する資格を与えるアプリケーション割り当てを作成します。次に、デスクトップ割り当てを作成し、エンド ユーザーにそれらのアプリケーションをベース デスクトップで使用できる資格を付与します。アプリケーション割り当てにより、ユーザーは資格が付与されたデスクトップの Windows オペレーティング システム内で、ユーザーに資格が割り当てられた App Volumes アプリケーションを使用できるようになります。App Volumes アプリケーション - 概要と前提条件を参照してください。
  20. ポッドがゲートウェイ構成でデプロイされている場合、デプロイ ウィザードで入力した完全修飾ドメイン名 (FQDN) をそのゲートウェイのポッドで構成されている適切な Microsoft Azure ロード バランサ リソースにマッピングする CNAME レコードを、DNS サーバに作成する必要があります。
    • パブリック IP アドレスが有効な外部ゲートウェイの場合は、デプロイ ウィザードで入力した FQDN を、ゲートウェイの Microsoft Azure ロード バランサ リソースの自動生成されたパブリック FQDN にマッピングします。DNS サーバ レコードは、Microsoft Azure ロード バランサの自動生成されたパブリック FQDN とエンド ユーザーが使用する FQDN をマッピングします。これは、アップロードされた証明書で使用されます。次のコード行は、例を示します。Active Directory ドメインを登録した後、コンソールのポッドの詳細ページから使用する ID を見つけます。外部ゲートウェイが専用の VNet にデプロイされていた場合は、[デプロイ ID] フィールドに表示されている ID を使用します。
      ourApps.ourOrg.example.com   vwm-hcs-ID-uag.region.cloudapp.azure.com
    • 内部ゲートウェイまたはパブリック IP アドレスがない外部ゲートウェイの場合は、デプロイ ウィザードで入力した FQDN を、ゲートウェイの Microsoft Azure ロード バランサ リソースのプライベート IP アドレスにマッピングします。DNS サーバ レコードは、Microsoft Azure ロード バランサの IP アドレスとエンド ユーザーが使用する FQDN をマッピングします。これは、アップロードされた証明書で使用されます。次のコード行は、例を示します。
      ourApps.ourOrg.example.com   Azure-load-balancer-private-IP

    ポッドがオンボーディングされ、管理コンソールの [キャパシティ] ページにアクセスできるようになったら、[キャパシティ] ページに移動して、DNS で FQDN をマッピングするために必要な vmw-hcs-ID-uag.region.cloudapp.azure.com 値を確認します。コンソールで Microsoft Azure ロード バランサの FQDN を特定する方法の詳細については、DNS サーバでマッピングするポッド ゲートウェイのロード バランサ情報の取得を参照してください。

  21. ポッドがポッドのゲートウェイに対して RADIUS 2 要素認証を使用するようにデプロイされている場合は、次のタスクを実行する必要があります。
    • RADIUS 設定を使用して外部ゲートウェイを構成し、ポッドで使用される VNet と同じ VNet 内で、または外部ゲートウェイを専用の VNet に展開した場合は、ピアリングされた VNet トポロジ内でその RADIUS サーバにアクセスできない場合、その RADIUS サーバが、外部ゲートウェイのロード バランサの IP アドレスからのクライアント接続を許可するように構成します。外部ゲートウェイ構成では、Unified Access Gateway インスタンスは、そのロード バランサのアドレスを使用して、RADIUS サーバとの通信を試みます。接続を許可するには、その外部ゲートウェイのリソース グループにあるロード バランサ リソースの IP アドレスが、確実に RADIUS サーバ構成でクライアントとして指定されているようにします。
    • 内部ゲートウェイを構成した場合や、外部ゲートウェイを構成してポッドで使用される VNet と同じ VNet 内で RADIUS サーバにアクセスできる場合は、RADIUS サーバと通信する必要がある、Microsoft Azure でのゲートウェイのリソース グループで作成された適切な NIC からの接続を許可するように RADIUS サーバを構成します。ネットワーク管理者が、ポッドの Azure 仮想ネットワークおよびサブネットに対する RADIUS サーバのネットワーク可視性を決定します。RADIUS サーバは、ネットワーク管理者によって RADIUS サーバへのネットワーク可視性が付与されたサブネットに対応するゲートウェイ NIC の IP アドレスからの、クライアント接続を許可する必要があります。Microsoft Azure のゲートウェイのリソース グループには、そのサブネットに対応する 4 つの NIC があり、そのうち 2 つが 2 個の Unified Access Gateway インスタンスに対して現在アクティブです。もう 2 つはアイドル状態で、ポッドが更新を完了した後にアクティブになります。実行中のポッド操作のため、および各ポッドの更新後のために、ゲートウェイと RADIUS サーバ間の接続をサポートするには、これらの 4 つの NIC の IP アドレスが RADIUS サーバ構成でクライアントとして指定されていることを確認します。

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

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

  • Universal Broker で構成された環境では、クライアントで Universal Broker 仲介の FQDN を使用します。
  • シングルポッド仲介を使用して構成された環境では、クライアントで FQDN を使用します。これは、DNS で CNAME レコードを使用してマッピングしたものです。

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