第 1 世代のポッド デプロイ ウィザードを実行する前に、環境がこれらの前提条件を満たしていることを確認してください。ポッド デプロイ ウィザードで要求された値を指定し、ウィザードの指示に従って進めるために、次の項目を用意しておく必要があります。

重要： この情報は、第 1 世代の制御プレーンで第 1 世代のテナント環境にアクセスできる場合にのみ適用されます。 KB-92424 で説明されているように、第 1 世代の制御プレーンは提供終了 (EOA) となりました。詳細については、該当記事を参照してください。
重要： ポッド デプロイ ウィザードを起動してポッドのデプロイを開始する前に、以下の要件に加えて、次の重要な点に注意する必要があります。
  • ポッドを正常にデプロイするには、ユーザーまたは IT チームが Microsoft Azure 環境で設定したどの Microsoft Azure ポリシーも、ポッドのコンポーネントの作成をブロック、拒否、または制限しないようにすることが必要です。また、Microsoft Azure ポリシーの組み込みポリシー定義がポッドのコンポーネントの作成をブロック、拒否、または制限しないことを確認する必要があります。許可する必要がある項目の 2 つの例として、ユーザーと IT チームは、Microsoft Azure ポリシーが Azure ストレージ アカウントでのコンポーネントの作成をブロック、拒否、または制限することがないことを確認し、Microsoft Azure ポリシーで Microsoft.MarketplaceOrdering/* の resourceType が許可されていることを確認する必要があります。ポッドのデプロイ プロセスは、VMware の vmware-inc publisherID からの Azure Marketplace オファーの受け入れに依存します。Azure ポリシーの詳細については、Azure ポリシーのドキュメントを参照してください。サービスが Microsoft.MarketplaceOrdering/* リソース タイプを使用する方法については、IT またはセキュリティ組織に Azure Marketplace オファーまたはマーケットプレイスの注文の使用に関する制限がある場合を参照してください。
  • ポッド デプロイヤでは、Azure ストレージ アカウントでそのデプロイヤがサブスクリプション内のポッドのリソース グループに Azure StorageV2 アカウント タイプを作成できるようにする必要があります。このストレージ アカウントは、ポッドの App Volumes 機能に使用されます。ポッドのデプロイ中は、Microsoft Azure ポリシーが、Azure StorageV2 アカウント タイプを必要とするコンテンツの作成を制限したり、拒否したりしないようにします。
  • すべてのクラウド接続されたポッドは、それらのポッドをデプロイするときに、Active Directory ドメインの同じセットに接続されている必要があります。

すべてのデプロイの前提条件

  • 他のポッドをもう 1 台追加する場合は、以前のポッドで使用したものと同じサブスクリプションを使用するか、組織で必要な場合は別のサブスクリプションを使用することができます。別のサブスクリプションを使用しようとする場合は、『デプロイ ガイド』に記載されている手順を実行して、サブスクリプション ID、ディレクトリ ID、アプリケーション ID、およびアプリケーション キーを取得する必要があります。使用するサブスクリプションが、確実にそのガイドに記載されている要件を満たしている必要があります。特に、サービス プリンシパルに、サブスクリプション内の該当するレベルで付与される適切なロールの権限が付与されていることが必要です。「Horizon Cloud のドキュメント」ページから、オンラインのスタート ガイド ドキュメントに移動することができます。
  • テナントが Microsoft Azure のポッドに対して Universal Broker を使用するように構成されている場合、ポッド デプロイ ウィザードを実行して新しいポッドを追加するときに、サイトを指定する必要があります。既存のサイトを選択するか、新しいサイトを指定できます。
  • ポッドをデプロイするリージョンに VNet があり、VNet がMicrosoft Azure で必要な仮想ネットワークを構成するに記載されている要件を満たしているかを確認します。
    重要： 一部の Microsoft Azure リージョンでは、GPU が有効な仮想マシンはサポートされません。GPU 対応のデスクトップまたはリモート アプリケーションでポッドを使用する場合は、使用する NV シリーズ、NVv4 シリーズ、NCv2 シリーズの仮想マシン タイプが、ポッド用に選択した Microsoft Azure のリージョンで提供されていることと、この Horizon Cloud リリースでサポートされていることを確認します。詳細については、 https://azure.microsoft.com/ja-jp/regions/services/ にある Microsoft のドキュメントを参照してください。
  • VNet が、外部アドレスを解決できる DNS を参照するように構成されていることを確認します。ポッド デプロイヤは、ポッド ソフトウェアを Microsoft Azure 環境に安全にダウンロードするために Horizon Cloud 制御プレーンの外部アドレスに到達できる必要があります。
  • 第 1 世代テナント - Horizon Cloud on Microsoft Azure のデプロイ - ホスト名解決の要件、DNS 名および第 1 世代テナント - Horizon Cloud ポッド - ポートとプロトコルの要件の説明どおりに、ポッド デプロイヤの DNS、ポート、およびプロトコルの要件が満たされていることを確認します。
  • アウトバウンド インターネット アクセスでプロキシを使用する必要がある場合は、プロキシ設定のためのネットワーク情報および必要な認証情報（使用する場合）があることを確認します。ポッドのデプロイ プロセスには、アウトバウンド インターネット アクセスが必要です。
    重要： ポッドが Microsoft Azure にデプロイされた後にポッドのプロキシ設定を編集または更新することは、現在サポートされていません。また、プロキシ設定なしでデプロイされたデプロイ済みポッドにプロキシ構成を追加することは、現在サポートされていません。
  • ポッド マネージャ インスタンスおよび Unified Access Gateway インスタンスで時刻の同期に使用する少なくとも 1 台の NTP サーバの情報があることを確認します。NTP サーバは、パブリック NTP サーバ、またはこの目的で設定する独自の NTP サーバです。指定する NTP サーバは、ポッド マネージャ インスタンスおよび Unified Access Gateway インスタンスをデプロイする予定の仮想ネットワークからアクセスできる必要があります。IP アドレスではなくドメイン名を使用して NTP サーバを使用する場合は、仮想ネットワークに対して構成された DNS が NTP サーバの名前を解決できることも確認してください。
    注： ポッド マネージャ インスタンス、 Unified Access Gateway インスタンス、および Active Directory サーバに同じ NTP サーバを使用することがベスト プラクティスです。タイム スキューは、これらのインスタンスが異なる NTP サーバを使用する場合に発生する可能性があります。このようなタイム スキューにより、後でゲートウェイがデスクトップおよびアプリケーションに対してエンド ユーザー セッションを認証しようとしたときに、エラーが発生する可能性があります。
  • デプロイヤが必要なサブネットを自動的に作成するようにしたくない場合は、必要なサブネットが事前に作成されていて VNet 上に存在していることを確認します。必要なサブネットを事前に作成する手順については、第 1 世代テナント - ポッドのデプロイの前に、Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブネットを作成するおよび第 1 世代テナント - Microsoft Azure で Horizon Cloud ポッド用に既存のサブネットを使用する場合を参照してください。
    注意： ポッドのデプロイのために VNet 上に事前に手動で作成したサブネットは空のままである必要があります。これらのサブネットの IP アドレスを使用しているアイテムを持つ既存のサブネットを再利用しないでください。IP アドレスがサブネットですでに使用されている場合、ポッドがデプロイに失敗したり、その他のダウンストリーム IP アドレスの競合の問題などの問題が発生する可能性が高くなります。これらのサブネットに何らかのリソースを投入したり、IP アドレスを使用したりしないでください。この警告通知には Horizon Cloud からデプロイされたポッドが含まれています。すでにデプロイされているポッドがあるサブネットを再利用しないでください。
    重要： 最初のポッドをデプロイした後に追加ポッドをデプロイする際、既存のポッドですでに使用されている既存のサブネットを再使用しないでください。ポッドですでに使用されているサブネットを共有しようとしないでください。別のポッドがすでに使用しているサブネットを選択すると、その既存のポッドとそのサブネットを使用してデプロイするポッドの操作が中断されます。

    ポッドごとに個別の VNet を使用することをお勧めします。この推奨事項は、Horizon Cloud の使用前および使用中に知っておくべきことで説明されている、単一のサブスクリプションにデプロイするポッドの数に関して考慮すべきガイダンスに基づいています。単一のサブスクリプション内の Microsoft Azure の制限を回避するために、サブスクリプションごとに 1 つのポッドがある場合は、これらの制限に達する可能性を回避します。Microsoft Azure では各サブスクリプションに専用の VNet が必要であるため、サブスクリプションごとに 1 つのポッドを使用するベスト プラクティスに従う場合は、各ポッドに個別の VNet を使用するベスト プラクティスに自動的に準拠することになります。

  • デプロイヤで必要なサブネットを作成する場合、ウィザードの管理サブネット、デスクトップ サブネット、および DMZ サブネットに入力するアドレス範囲を把握していることを確認します。外部 Unified Access Gateway 構成を使用する場合は、DMZ サブネットが必要です。また、これらの範囲が重複しないことを確認します。アドレス範囲は、CIDR 表記（クラスレス ドメイン間ルーティング表記）で入力します。入力したサブネット範囲が重複していると、ウィザードがエラーを表示します。管理サブネット範囲の場合、少なくとも /27 の CIDR が必要です。DMZ サブネット範囲の場合、少なくとも /28 の CIDR が必要です。管理および DMZ サブネットの範囲を同じ場所に共存させたいのであれば、IP アドレスを指定して DMZ サブネット範囲を管理サブネットと同様のものに指定することができます。たとえば、管理サブネットが 192.168.8.0/27 の場合、一致する DMZ サブネットは 192.168.8.32/27 になります。
    重要： ウィザード フィールドに入力する CIDR は、プリフィックスとビットマスクの各組み合わせが、プリフィックスを開始 IP アドレスとする IP アドレス範囲になるように定義する必要があります。Microsoft Azure では、CIDR プリフィックスを範囲の先頭にする必要があります。たとえば、192.168.182.48/28 という正しい CIDR の場合、IP アドレス範囲は 192.168.182.48 ～ 192.168.182.63 になり、プリフィックスは開始 IP アドレス (192.168.182.48) と同じになります。ただし、192.168.182.60/28 という間違った CIDR の場合、IP アドレス範囲は 192.168.182.48 ～ 192.168.182.63 になり、開始 IP アドレスは 192.168.182.60 のプリフィックスと同じになりません。CIDR は、開始 IP アドレスが CIDR プリフィックスと一致する IP アドレス範囲になるように定義してください。
  • デプロイヤによって必要なサブネットを作成する場合、このアドレス範囲を持つサブネットが VNet 上に存在しないことを確認してください。この場合、デプロイヤ自体がウィザードで指定するアドレス範囲を使用してサブネットを自動的に作成します。ウィザードが既にこれらの範囲が存在するサブネットを検出した場合は、ウィザードにアドレスの重複に関するエラーが表示され、それ以降に進まなくなります。VNet がピアリングされている場合、ウィザードに入力するつもりの CIDR アドレス空間がすでに VNet のアドレス空間に含まれていることを確認します。

Unified Access Gateway 構成の前提条件

ポッドで Unified Access Gateway の構成を使用することを計画している場合、次の情報を入力する必要があります。

  • サービスへのアクセスでエンド ユーザーが使用する完全修飾ドメイン名 (FQDN)。外部ゲートウェイと内部ゲートウェイの両方の構成に同じ FQDN を使用することを計画している場合は、ポッドをデプロイした後、適切なゲートウェイ ロード バランサにルーティングするようにエンドユーザー クライアントの受信トラフィックを設定する必要があります。目標は、インターネットからのクライアント トラフィックが外部ゲートウェイの Microsoft Azure パブリック ロード バランサにルーティングされ、イントラネットからのクライアント トラフィックが内部ゲートウェイの Microsoft Azure 内部ロード バランサにルーティングされるようにルーティングを設定することです。このシナリオでは、両方のゲートウェイで同じ FQDN を使用するため、スプリット DNS（スプリット Domain Name System）を構成して、エンド ユーザー クライアントの DNS クエリのオリジン ネットワークに応じて、外部ゲートウェイまたは内部ゲートウェイのいずれかにゲートウェイ アドレスを解決します。次に、エンド ユーザー クライアントで使用されているのと同じ FQDN で、クライアントがインターネット上にある場合は外部ゲートウェイにルーティングし、クライアントが内部ネットワーク上にある場合は内部ゲートウェイにルーティングできます。
    重要： この FQDN には、アンダー スコアを含めることはできません。このリリースでは、FQDN にアンダー スコアが含まれていると、 Unified Access Gateway インスタンスへの接続が失敗します。
  • その FQDN に基づいた署名付きの SSL サーバ証明書（PEM 形式）。Unified Access Gateway 機能には、Unified Access Gateway 製品マニュアルに記載されているようにクライアント接続のための SSL が必要です。証明書には、信頼された証明書認証局 (CA) の署名が必要です。単一の PEM ファイルに完全な証明書チェーンおよびプライベート キーが含まれている必要があります。たとえば、単一の PEM ファイルに SSL サーバ証明書、必要な中間 CA 証明書、ルート CA 証明書、およびプライベート キーが含まれている必要があります。OpenSSL は、PEM ファイルの作成に使用できるツールです。
    重要： 証明書チェーン内のすべての証明書が有効期限内である必要があります。 Unified Access Gateway 仮想マシンでは、任意の中間証明書を含む、チェーン内のすべての証明書が有効期限内である必要があります。チェーン内のいずれかの証明書が期限切れの場合、後で Unified Access Gateway 構成に証明書がアップロードされる際に予期しない障害が発生する可能性があります。
  • 外部の Unified Access Gateway 構成でデプロイする場合、DMZ（非武装地帯）サブネットを指定する必要があります。2 つの方法で、この DMZ サブネットを指定することができます。
    • DMZ サブネットを VNet で事前に作成する。この方法を使うと、管理サブネットおよびデスクトップ テナント サブネットも事前に作成する必要があります。第 1 世代テナント - ポッドのデプロイの前に、Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブネットを作成するの手順を参照してください。
    • デプロイの際に、デプロイヤに DMZ サブネットを自動的に作成させる。この方法では、ウィザードに入力する DMZ サブネット用のアドレス範囲を決定し、その範囲が管理サブネットおよびデスクトップ テナント サブネットの範囲と重複しないことを確認する必要があります。アドレス範囲は、CIDR 表記（クラスレス ドメイン間ルーティング表記）で入力します。入力したサブネット範囲が重複していると、ウィザードがエラーを表示します。DMZ サブネット範囲の場合、少なくとも /28 の CIDR が必要です。管理および DMZ サブネットの範囲を同じ場所に共存させるには、IP アドレスを指定して DMZ サブネット範囲を管理サブネットと同一のものに指定することができます。たとえば、管理サブネットが 192.168.8.0/27 の場合、一致する DMZ サブネットは 192.168.8.32/27 になります。IP アドレスの範囲に、プリフィックスを開始 IP アドレスとするプリフィックスとビット マスクの組み合わせが必要なことに関する、すべてのデプロイの前提条件の重要な注意事項も参照してください。
  • 外部 Unified Access Gateway 構成でデプロイし、構成のロード バランサにパブリック IP アドレスを使用しないようにする場合、DNS 設定でエンド ユーザーが Horizon Client の PCoIP 接続に使用する FQDN にマッピングした IP アドレスを指定する必要があります。

Unified Access Gateway で必要な PEM ファイルに関する考慮事項の詳細については、第 1 世代テナント - 第 1 世代 Horizon Cloud ポッドのデプロイに必要な PEM 形式への証明書ファイルの変換を参照してください。

ポッドの VNet またはサブスクリプションとは別の専用の VNet またはサブスクリプションを使用して外部 Unified Access Gateway 構成でデプロイする場合の前提条件

注： 専用の VNet を使用して外部ゲートウェイをデプロイすると、ゲートウェイ コネクタ仮想マシンがデプロイされます。 Horizon Cloud ポッドのポートとプロトコルの要件では、ゲートウェイ コネクタ仮想マシンのポートとプロトコルについて説明するセクションに、このゲートウェイ コネクタ仮想マシンの説明も含まれており、ゲートウェイ コネクタ仮想マシンの名前に vmw-hcs-ID のような部分を含む名前が付くことが示されています。この場合の、 ID はゲートウェイのデプロイヤ ID、および node 部分になります。

Unified Access Gateway 構成でデプロイする場合の上記の前提条件に加えて、これらの前提条件は、外部ゲートウェイを専用の VNet または専用のサブスクリプションにデプロイする使用事例に固有です。専用のサブスクリプションの使用は専用の VNet の使用の特殊な事例です。それは、VNet の適用範囲はサブスクリプションであるため、個別のサブスクリプションには専用の VNet が必要になるためです。

2 要素認証構成でデプロイする際の前提条件

2 要素認証機能を使用する予定や、それをオンプレミスの 2 要素認証サーバで使用する予定がある場合は、認証サーバの構成からの次の情報があることを確認し、[ポッドの追加] ウィザードの必須フィールドにその情報を指定できるようにします。

使用しているタイプに応じて、次の情報を取得します。

RADIUS

プライマリおよび補助 RADIUS サーバの両方の設定を構成している場合は、それぞれの情報を取得します。

  • 認証サーバの IP アドレスまたは DNS 名
  • 認証サーバのプロトコル メッセージで暗号化および復号化のために使用される共有シークレット
  • 認証ポート番号。通常 RADIUS の場合は 1812/UDP。
  • 認証プロトコルのタイプ。認証タイプには、PAP（パスワード認証プロトコル）、CHAP（チャレンジ ハンドシェイク認証プロトコル）、MSCHAP1 および MSCHAP2（Microsoft チャレンジ ハンドシェイク認証プロトコル、バージョン 1 および 2）があります。
    注： RADIUS ベンダーの推奨する認証プロトコルについては、RADIUS ベンダーのドキュメントを確認し、指定したプロトコル タイプに従ってください。RADIUS の 2 要素認証をサポートするポッドの機能は、Unified Access Gateway インスタンスによって提供され、Unified Access Gateway が PAP、CHAP、MSCHAP1、MSCHAP2 をサポートします。PAP のセキュリティは、通常 MSCHAP2 のものよりも低くなっています。また PAP は MSCHAP2 よりシンプルなプロトコルです。結果として、RADIUS ベンダーのほとんどはよりシンプルな PAP プロトコルと互換性がありますが、一部の RADIUS ベンダーはよりセキュリティの高い MSCHAP2 との互換性を有していません。
RSA SecurID
注： RSA SecurID タイプは、マニフェスト 3139.x 以降を実行している Horizon Cloud on Microsoft Azure デプロイでサポートされます。2022 年 3 月中旬以降の [ポッドの追加] ウィザードと [ポッドの編集] ウィザードでは RSA SecurID タイプを指定するユーザー インターフェイス オプションが表示され、選択できるようになります。
  • RSA SecurID Authentication Manager サーバのアクセス キー。
  • RSA SecurID 通信ポート番号。通常は 5555 で、RSA SecurID 認証 API に対する RSA Authentication Manager システム設定で設定されています。
  • RSA SecurID Authentication Manager サーバのホスト名。
  • RSA SecurID Authentication Manager サーバの IP アドレス。
  • RSA SecurID Authentication Manager サーバまたはそのロード バランサ サーバに自己署名証明書がある場合は、[ポッドの追加] ウィザードで CA 証明書を指定する必要があります。証明書は PEM 形式である必要があります（ファイル タイプ .cer、 .cert、または.pem）。