EnglishFrançaisDeutschEspañolItaliano日本語한국어NederlandsPortuguês (Brasil)中文 (简体)中文 (繁體, 台灣)
Skip to main content

2026 年 9 月 1 日

第 1 世代テナント - 第 1 世代ポッドのデプロイ ウィザードを実行するための前提条件

第 1 世代のポッド デプロイ ウィザードを実行する前に、環境がこれらの前提条件を満たしていることを確認します。ポッドのデプロイ ウィザードで要求された値を指定してウィザードを続行するには、次の項目が必要です。

重要: この情報は、第 1 世代の制御プレーンで第 1 世代のテナント環境にアクセスできる場合にのみ適用されます。KB-92424 で説明されているように、第 1 世代の制御プレーンは提供終了 (EOA) となりました。詳細については、その記事を参照してください。

重要: ポッド デプロイ ウィザードを起動してポッドのデプロイを開始する前に、以下の要件に加えて、次の重要な点に注意する必要があります。

  • ポッドを正常にデプロイするには、ユーザーまたは IT チームが Microsoft Azure 環境で設定した Microsoft Azure ポリシーのいずれも、ポッドのコンポーネントの作成をブロック、拒否、または制限しないようにする必要があります。また、Microsoft Azure ポリシーの組み込みポリシー定義がポッドのコンポーネントの作成をブロック、拒否、または制限しないことを確認する必要があります。許可する必要がある項目の 2 つの例として、ユーザーと IT チームは、Microsoft Azure ポリシーが Azure ストレージ アカウントでのコンポーネントの作成をブロック、拒否、または制限しないことを確認し、Microsoft Azure ポリシーでMicrosoft.MarketplaceOrdering/*``resourceTypeが許可されていることを確認する必要があります。ポッドのデプロイ プロセスは、 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、およびアプリケーション キーを取得する必要があります。使用するサブスクリプションが、このガイドに記載されている要件を満たしていることを確認する必要があります。特に、サービス プリンシパルにサブスクリプションの関連するレベルで付与された適切なロール権限が付与されている必要があります。

  • テナントが Microsoft Azure のポッドに対して Universal Broker を使用するように構成されている場合、ポッド デプロイ ウィザードを実行して新しいポッドを追加するときに、サイトを指定する必要があります。既存のサイトを選択するか、新しいサイトを指定できます。

  • ポッドをデプロイするリージョンに VNet があり、VNet がMicrosoft Azure で必要な仮想ネットワークを構成するに記載されている要件を満たしていることを確認します。

    重要: 一部の Microsoft Azure リージョンでは、GPU 対応の仮想マシンはサポートされません。GPU 対応のデスクトップまたはリモート アプリケーションでポッドを使用する場合は、使用する NV シリーズ、NVv4 シリーズ、NCv2 シリーズの仮想マシン タイプが、ポッド用に選択した Microsoft Azure リージョンで提供され、この Horizon Cloud リリースでサポートされていることを確認します。詳細については、 https://azure.microsoft.com/en-us/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 の使用前および使用中に知っておくべきことで説明されている、単一のサブスクリプションにデプロイするポッドの数について考慮すべきガイダンスに基づいています。サブスクリプションごとに 1 つのポッドがある場合は、単一のサブスクリプション内で Microsoft Azure の制限を回避するため、これらの制限に達する可能性を回避します。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 プリフィックスを範囲の先頭にする必要があります。たとえば、正しい CIDR が 192.168.182.48/28 の場合、IP アドレス範囲は 192.168.182.48 から 192.168.182.63 となり、プリフィックスは開始 IP アドレス (192.168.182.48) と同じになります。ただし、CIDR が誤って 192.168.182.60/28 の場合、IP アドレス範囲は 192.168.182.48 から 192.168.182.63 になります。この場合、開始 IP アドレスは 192.168.182.60 のプリフィックスと同じではありません。CIDR の結果、IP アドレス範囲の開始 IP アドレスが CIDR プレフィックスと一致することを確認します。

  • デプロイヤによって必要なサブネットを作成する場合は、これらのアドレス範囲を持つサブネットが 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) によって署名されている必要があります。1 つの PEM ファイルに完全な証明書チェーンとプライベート キーが含まれている必要があります。たとえば、単一の PEM ファイルに SSL サーバ証明書、必要な中間 CA 証明書、ルート CA 証明書、およびプライベート キーが含まれている必要があります。OpenSSL は、PEM ファイルの作成に使用できるツールです。

    重要: 証明書チェーン内のすべての証明書には、有効期間が設定されている必要があります。Unified Access Gateway 仮想マシンでは、中間証明書を含むチェーン内のすべての証明書の有効期間が設定されている必要があります。チェーン内のいずれかの証明書が期限切れの場合、後で証明書が Unified Access Gateway 構成にアップロードされるときに予期しない障害が発生する可能性があります。

  • 外部 Unified Access Gateway 構成を使用してデプロイする場合は、DMZ(非武装地帯)サブネットを指定する必要があります。この DMZ サブネットを指定するには、次の 2 つの方法があります。

    • 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 ポッドのポートとプロトコルの要件では、ゲートウェイ コネクタ仮想マシンのポートとプロトコルを説明するセクションに、このゲートウェイ コネクタ仮想マシンの説明もあります。このゲートウェイ コネクタ仮想マシンには、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 ベンダーはより安全な PAP プロトコルとの互換性がありません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 認証マネージャ システム設定で設定されます。
    • RSA SecurID Authentication Manager サーバのホスト名。
    • その RSA SecurID Authentication Manager サーバの IP アドレス。
    • RSA SecurID Authentication Manager サーバまたはそのロード バランサ サーバに自己署名証明書がある場合は、[ポッドの追加] ウィザードで CA 証明書を指定する必要があります。証明書は PEM 形式(ファイル タイプは .cer または .cert または .pem) である必要があります

このページは役に立ちましたか?

このトピックについてフィードバックを送信

このトピックは役に立ちましたか?

個人情報や機密情報は入力しないでください。

リンクを生成しています…