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

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

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

  1. 前提条件に従って準備します。新しいポッド デプロイの VMware Horizon Cloud Service on Microsoft Azure 要件チェックリストを参照してください。
  2. Horizon Cloud 以外の準備タスクを実行します。VMware Horizon Cloud Service on Microsoft Azure スタート ガイド』を参照してください。
  3. ポッドをデプロイするための DNS、ポート、およびプロトコルの要件を満たしていることを確認します。Microsoft Azure での Horizon Cloud ポッドの DNS の要件および2019 年 9 月のリリースのマニフェスト以降の Horizon Cloud ポッドのポートとプロトコルの要件を参照してください。
  4. ポッドをデプロイします。VMware Horizon Cloud Service on Microsoft Azure スタート ガイド』を参照してください。
  5. デプロイ済みのポッドで Active Directory ドメインを登録します。ここでは、ドメイン参加アカウントの名前を提供することも含まれます。Horizon Cloud 環境での最初の Active Directory ドメイン登録の実行を参照してください。
  6. ドメイン参加アカウントをメンバーとして含む Active Directory グループに Horizon Cloud スーパー管理者の役割を付与します。
    重要: ドメインの登録時に入力したドメイン参加アカウントが、 Horizon Cloud スーパー管理者の役割を割り当てる Active Directory グループの 1 つの中に確実に入っている必要があります。ポッドを使用したシステムのドメイン参加の操作は、 Horizon Cloud スーパー管理者の役割を持つドメイン参加アカウントによって異なります。 Active Directory グループへの Horizon Cloud 管理ロールの割り当てを参照してください。
  7. ポッドによってプロビジョニングされたリソースをエンドユーザーに仲介するときに、テナントのポッドで使用する仲介のタイプを選択します。Universal Broker とシングルポッド ブローカの概要 および関連するトピックとサブトピックを参照してください。
  8. ポッドで 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 を設定する必要があります。

    ただし、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 内部ロード バランサを使用しています。

  9. 前の手順で説明したユースケースのいずれかまたは両方を使うことを予定している場合は、管理コンソールのポッドの [サマリ] ページを使用して、SSL 証明書をポッドに直接アップロードします。Horizon Cloud ポッドのマネージャ仮想マシンでの SSL 証明書の構成を参照してください。
    ヒント: ポッドの Unified Access Gateway インスタンスに接続されたロード バランサを介してそれらのインスタンスに接続するというアクセスのユースケースのみをサポートする場合、ポッドに直接 SSL 証明書をアップロードする必要はありません。それでも、上記の手順とこの手順を実行することが推奨されるのは、その FQDN をユーザーに配信して、ユーザーが自分の Horizon Clients で入力したときに、それらのクライアントで信頼された接続が確立されるからです。また、上記の手順とこの手順を実行すると、FQDN がマッピングされ、SSL 証明書がポッドに配置されているため、ポッドをより早く Workspace ONE Access に統合することができます。
  10. 基本イメージをインポートします。[インポートされた仮想マシン] ページで、[エージェント ペアリングをリセット] アクションを使用して、新しいイメージを Horizon Cloud とペアリングします。Microsoft Azure に Horizon Cloud ポッドのデスクトップ イメージを作成を参照してください。
    注: Tech Preview:App Volumes での Microsoft Windows 10 Enterprise マルチセッション オペレーティング システムの使用は、現在 Tech Preview になっています。この使用事例の基本イメージをインポートするには、 Tech Preview - この Horizon Cloud リリースの App Volumes 機能で使用するための Microsoft Windows 10 マルチセッション イメージの構成方法の手順を代わりに使用します。
  11. エンドユーザーの割り当てのタイプに応じて、最終的にイメージが使用されます。必要に応じて、次の 1 つ以上の手順を実行します。
    • VDI デスクトップまたはネイティブ アプリケーションのプロビジョニングに使用されるイメージ仮想マシンで、エンド ユーザーに提供するサードパーティ アプリケーションをインストールし、デスクトップ壁紙の設定、(GPU 対応のイメージのための)NVIDIA GPU のドライバのインストールなどのその他の適用可能なカスタマイズを設定します。イメージのインポート プロセスの一部として実行されていない場合、Microsoft Sysprep のベスト プラクティスに従ってイメージを最適化することもできます。
      ヒント: イメージ仮想マシンをさらに調整して、VDI の使用事例で VMware Blast Extreme を使用するための構成を改善するには、 VMware Blast Extreme 最適化ガイドを読み、そのガイドのコーデック オプションに関する推奨事項に従って、イメージ内のコーデック オプションの追加のチューニングを実行することがベスト プラクティスです。
    • RDSH ベースのセッション デスクトップとリモート アプリケーションのプロビジョニングに使用される RDS 対応イメージで、その RDS イメージからエンド ユーザーに提供するサードパーティ アプリケーションをインストールし、デスクトップ壁紙の設定、(GPU 対応のイメージのための)NVIDIA GPU のドライバのインストールなどの適用可能なその他のカスタマイズを設定します。イメージのインポート プロセスの一部として実行されていない場合、Microsoft Sysprep のベスト プラクティスに従ってイメージを最適化することもできます。インポートされた仮想マシンが、デフォルトで Office 365 ProPlus を含む Microsoft Windows 10 Enterprise マルチセッション システムの 1 つを実行している場合、Microsoft ドキュメントのトピック「Office 365 ProPlus に対する共有コンピューターのライセンス認証の概要」で説明されているように、仮想マシンが Office 365 ProPlus の共有コンピュータのアクティベーション用に構成されていることを確認する必要があります。インポートされた仮想マシンで Office 365 ProPlus が共有コンピュータのアクティベーション用に構成されていない場合は、状況に適した Microsoft ドキュメントに記載されている方法を使用してください。
      ヒント: イメージ仮想マシンをさらに調整して、VDI の使用事例で VMware Blast Extreme を使用するための構成を改善するには、 VMware Blast Extreme 最適化ガイドを読み、そのガイドのコーデック オプションに関する推奨事項に従って、イメージ内のコーデック オプションの追加のチューニングを実行することがベスト プラクティスです。
  12. そのイメージを、割り当て可能なイメージ(イメージのシーリングまたは公開とも呼ばれる)に変換します。構成済みのマスター仮想マシンを割り当て可能デスクトップ イメージに変換を参照してください。
  13. 公開済みのサーバ イメージからセッションベースの RDSH デスクトップとリモート アプリケーションをプロビジョニングするには:
    1. セッション デスクトップを提供するデスクトップ RDSH ファームを作成し、エンド ユーザーにこれらのデスクトップを使用する資格を付与するために割り当てを作成します。Horizon Cloud のファームRDSH セッション デスクトップ割り当ての作成を参照してください。
    2. リモート アプリケーションを提供するためにアプリケーション RDSH ファームを作成し、アプリケーション インベントリにアプリケーションを追加してから、エンド ユーザーにこれらのリモート アプリケーションを使用する資格を付与するために割り当てを作成します。Horizon Cloud のファームリモート アプリケーション - Microsoft Azure の Horizon Cloud ポッドによってプロビジョニングされた RDSH ファームからのインポート、およびリモート アプリケーション - Microsoft Azure の Horizon Cloud ポッドによってプロビジョニングされたリモート アプリケーションのリモート アプリケーション割り当ての作成を参照してください。
  14. 公開済みの VDI デスクトップ イメージから VDI デスクトップをプロビジョニングするには、専用またはフローティング VDI デスクトップ割り当てを作成します。Microsoft Azure のシングル ポッドによってプロビジョニングされるフローティング VDI デスクトップ割り当ての作成およびMicrosoft Azure のシングル ポッドによってプロビジョニングされる専用 VDI デスクトップ割り当ての作成を参照してください。
  15. App Volumes アプリケーションをエンドユーザーにプロビジョニングするには、App Volumes アプリケーションをアプリケーション インベントリに追加し、エンドユーザーにそれらのアプリケーションを使用する資格を与えるアプリケーション割り当てを作成します。次に、同じ公開イメージに基づいてデスクトップ割り当てを作成し、それらのエンドユーザーにアプリケーションを起動できるデスクトップの資格を付与します。App Volumes アプリケーション - 概要と前提条件を参照してください。
  16. ポッドがゲートウェイ構成でデプロイされている場合、デプロイ ウィザードで入力した完全修飾ドメイン名 (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.リージョン.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 サーバでマッピングするポッドのゲートウェイのロード バランサ情報の取得を参照してください。

  17. ポッドがポッドのゲートウェイに対して 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 または HTML Access で FQDN を使用して資格のあるデスクトップとリモート アプリケーションを起動できます。

各ワークフロー ステップを実行する方法の詳細については、上記の各手順にリンクされたトピックまたはコンパニオン ガイドを参照してください。VMware Horizon Cloud Service on Microsoft Azure スタート ガイド』を参照してください。