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

重要: ポッド デプロイ ウィザードを起動してポッドのデプロイを開始する前に、以下の要件に加えて、次の重要な点に注意する必要があります。
  • 2020 年 7 月以降のサービス リリースでは、新しい環境で、少なくとも 1 つのゲートウェイ構成を使用して新しいポッドをデプロイする必要があります。カスタマー アカウントが 2020 年 7 月リリースより前に作成されていて、最初のポッドをデプロイしていない場合、最初のポッドのデプロイでは、ポッドのデプロイ時に少なくとも 1 つのゲートウェイ構成を指定する必要があります。
  • ポッドのデプロイを成功させるには、ユーザーまたは IT チームが Microsoft Azure 環境で設定したどの Microsoft Azure ポリシーも、ポッドのコンポーネントの作成をブロック、拒否、または制限しないようにすることが必要です。また、Microsoft Azure ポリシーの組み込みポリシー定義がポッドのコンポーネントの作成をブロック、拒否、または制限しないことを確認する必要があります。たとえば、ユーザーおよび IT チームは、Microsoft Azure ポリシーが Azure ストレージ アカウントでのコンポーネントの作成をブロック、拒否、または制限しないことを確認する必要があります。Azure ポリシーの詳細については、Azure ポリシーのドキュメントを参照してください。
  • ポッド デプロイヤでは、デプロイヤによる Azure StorageV1 および StorageV2 アカウント タイプの使用を Azure ストレージ アカウントで許可されていることが必要です。Microsoft Azure ポリシーが、Azure StorageV1 および StorageV2 アカウント タイプを必要とするコンテンツの作成を制限したり拒否したりしないようにします。
  • デプロイ ウィザードでカスタム リソース タグを指定しない場合、ポッドおよびゲートウェイのデプロイ プロセスの一部として、Horizon Cloud はタグが付いていないリソース グループ (RG) を Microsoft Azure サブスクリプションに作成します。これには、これらのデプロイ プロセスをオーケストレーションする一時ジャンプ ボックス用に作成される初期リソース グループが含まれます。2020 年 10 月 8 日の時点で、デプロイ ウィザードには、デプロイヤで作成されたリソース グループに適用するカスタム リソース タグを指定する機能があります。カスタム リソース タグが指定されておらず、Microsoft Azure サブスクリプションに何らかの種類のリソース タグ要件がある場合、そのサブスクリプションにポッドをデプロイしようとすると、ポッドのデプロイが失敗します。または、ポッドの更新時やポッドにゲートウェイ構成を追加する際に、ポッドのデプロイが失敗します。デプロイ ウィザードの [カスタム リソース タグ] 機能を使用する予定がない場合は、Microsoft Azure ポリシーによって、ポッドのタグなしリソース グループをターゲット サブスクリプションで作成できることを確認する必要があります。デプロイヤが作成する RG のリストについては、『管理ガイド』のMicrosoft Azure にデプロイされたポッド用に作成されたリソース グループトピックを参照してください。
  • すべてのクラウド接続されたポッドは、それらのポッドをデプロイするときに、Active Directory ドメインの同じセットに接続されている必要があります。

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

  • Horizon Cloud ポッドを Microsoft Azure にデプロイする前の準備に記載されている準備作業がすべて完了していることを確認します。
  • サブスクリプション情報がHorizon Cloud ポッドのデプロイ ウィザードのためのサブスクリプション関連情報に記載のとおりであることを確認します。
  • Microsoft Azure で必要な仮想ネットワークを構成で説明したように、Microsoft Azure サブスクリプションで、ポッドを追加するリージョンに仮想ネットワークがあることを確認します。
    重要: 一部の Microsoft Azure リージョンでは、GPU が有効な仮想マシンはサポートされません。GPU 対応のデスクトップまたはリモート アプリケーションでポッドを使用する場合は、使用する NV シリーズの仮想マシン タイプが、ポッド用に選択した Microsoft Azure のリージョンで提供されていることと、この Horizon Cloud リリースでサポートされていることを確認します。詳細については、 https://azure.microsoft.com/ja-jp/regions/services/ にある Microsoft のドキュメントを参照してください。
  • VNet が、外部アドレスを解決できる DNS を参照するように構成されていることを確認します。ポッド デプロイヤは、ポッド ソフトウェアを Microsoft Azure 環境に安全にダウンロードするために Horizon Cloud 制御プレーンの外部アドレスに到達できる必要があります。
  • Microsoft の Horizon Cloud ポッドおよび関連サービス機能の DNS 要件および2019 年 9 月のリリースのマニフェスト以降の Horizon Cloud ポッドのポートとプロトコルの要件の説明どおりに、ポッド デプロイヤの DNS、ポート、およびプロトコルの要件が満たされていることを確認します。
  • アウトバウンド インターネット アクセスでプロキシを使用する必要がある場合は、プロキシ設定のためのネットワーク情報および必要な認証情報(使用する場合)があることを確認します。ポッドのデプロイ プロセスには、アウトバウンド インターネット アクセスが必要です。
  • ポッドで時刻の同期に使用する少なくとも 1 つの NTP サーバの情報があることを確認します。NTP サーバは、パブリック NTP サーバ、またはこの目的で設定する独自の NTP サーバです。指定する NTP サーバは、構成した仮想ネットワークからアクセス可能である必要があります。IP アドレスではなくドメイン名を使用して NTP サーバを使用する場合は、仮想ネットワークに対して構成された DNS が NTP サーバの名前を解決できることも確認してください。
  • デプロイヤが必要なサブネットを自動的に作成するようにしたくない場合は、必要なサブネットが事前に作成されていて VNet 上に存在していることを確認します。必要なサブネットを事前に作成する手順については、ポッドのデプロイの前に、Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブネットを作成するおよびMicrosoft Azure で Horizon Cloud ポッド用の既存のサブネットを使用する場合を参照してください。
    注意: ポッドのデプロイのために VNet 上に事前に手動で作成したサブネットは空のままである必要があります。これらのサブネットの IP アドレスを使用しているアイテムを持つ既存のサブネットを再利用しないでください。IP アドレスがサブネットですでに使用されている場合、ポッドがデプロイに失敗したり、その他のダウンストリーム IP アドレスの競合の問題などの問題が発生する可能性が高くなります。これらのサブネットに何らかのリソースを投入したり、IP アドレスを使用したりしないでください。この警告通知には Horizon Cloud からデプロイされたポッドが含まれています。すでにデプロイされているポッドがあるサブネットを再利用しないでください。
  • デプロイヤで必要なサブネットを作成する場合、ウィザードの管理サブネット、デスクトップ サブネット、および 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 で事前に作成する。この方法を使うと、管理サブネットおよびデスクトップ テナント サブネットも事前に作成する必要があります。ポッドのデプロイの前に、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 ファイルに関する考慮事項の詳細については、証明書ファイルをポッドのデプロイに必要な PEM 形式に変換するを参照してください。

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

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

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

  • ゲートウェイの VNet は、ポッドの VNet とピアリングする必要があります。
  • 必要なサブネットが事前に作成されて VNet に存在すること、またはウィザードに入力する予定の CIDR アドレス空間が VNet のアドレス空間にすでに含まれていることを確認します。VNet はピアリングされているため、VNet のアドレス空間にまだ含まれていない CIDR アドレス空間をウィザードに入力すると、デプロイヤは VNet を自動的に拡張できません。その場合、デプロイ プロセスは失敗します。
    ヒント: ベスト プラクティスは、事前にサブネットを作成することです。必要なサブネットを事前に作成する手順については、 ポッドのデプロイの前に、Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブネットを作成するおよび Microsoft Azure で Horizon Cloud ポッド用の既存のサブネットを使用する場合を参照してください。
  • 外部ゲートウェイに個別のサブスクリプションを使用している場合は、Horizon Cloud ポッドのデプロイ ウィザードのためのサブスクリプション関連情報で説明するようにサブスクリプション情報があることを確認します。
  • 外部ゲートウェイに別個のサブスクリプションを使用しており、デプロイヤにリソース グループを自動作成させるのではなく、作成した名前付きリソース グループにゲートウェイをデプロイしようとしている場合は、そのサブスクリプションにおいてそのリソース グループが作成済みであることを確認します。そのリソース グループは、ウィザードにおいて名前で選択します。また、Microsoft Azure サブスクリプションでの Horizon Cloud によって要求される操作で説明するように、そのリソースグループに対して、デプロイヤが動作するために必要なアクセス権が付与されていることを確認します。

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

2 要素認証機能を使用する予定や、それをオンプレミスの 2 要素認証サーバと使用する予定がある場合は、認証サーバの構成で次の情報が使用されていることを確認して、ポッド デプロイ ウィザードの適切なフィールドにその情報を提供できるようにします。プライマリおよびセカンダリ サーバの両方がある場合は、それぞれの情報を取得します。

  • 認証サーバの IP アドレスまたは DNS 名
  • 認証サーバのプロトコル メッセージで暗号化および復号化のために使用される共有シークレット
  • 認証ポートの番号、通常は 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 との互換性を有していません。