最初にゲートウェイなしで、または 1 つのタイプのゲートウェイのみを使用して Horizon Cloud ポッドを Microsoft Azure にデプロイした場合、[ポッドの編集] ワークフローを使用して、後からゲートウェイ構成をポッドに追加できます。このワークフローは、ポッドの詳細ページから起動します。

ヒント: コンソールは動的です。ポッドの現在の構成や環境全体の構成に基づいて、意味のある適切なワークフローおよびトグルやフィールドのみが、ユーザー インターフェイスで利用できるようになります。

Microsoft Azure 内の Horizon Cloud ポッドの概要に記載されているように、ポッドには内部/外部のゲートウェイ構成のどちらか 1 つまたは両方を設定できます。このワークフローを使用して、ポッドにまだないタイプを追加できます。ポッドを編集してゲートウェイ構成を追加するのと同時に、そのゲートウェイに対して 2 要素認証設定を指定することもできます。

重要: これらの手順を使用してポッドを変更するときは、次の点に注意してください。
  • 外部ゲートウェイ構成を最初に設定した後は、外部ゲートウェイのロード バランサの IP 設定を変更できないことに注意してください。外部ゲートウェイ構成を追加するときに、ゲートウェイのロード バランサ用にパブリック IP アドレスではなくプライベート IP アドレスを使用するように選択できます。デフォルトでは、パブリック IP アドレスを使用します。
  • システムがポッドの構成を変更している場合、変更が完了するまでは次の制限が適用されます。
    • ポッドでは管理タスクを実行できません。
    • ポッドによってサービスが提供される、デスクトップまたはリモート アプリケーションにセッションを接続していないエンド ユーザーは、接続を試みると失敗します。
    • ポッドによってサービスが提供されるセッションを接続しているエンド ユーザーに対して、それらのアクティブなセッションが切断されることになります。データの損失は発生しません。構成の変更が完了した後に、これらのユーザーは再接続できます。

前提条件

注: ポッドの高可用性が有効になっていて、ポッド マネージャ仮想マシンの 1 つがオフラインの場合、システムによってポッドへのゲートウェイの追加が妨げられます。 [保存して終了] をクリックすると、このメッセージが表示されます。ゲートウェイを追加するには、Microsoft Azure ポータルを使用してオフラインのポッド マネージャ仮想マシンをオンラインに戻す必要があります。

Microsoft Azure の既存のポッドにゲートウェイ構成を追加するときに、[ポッドの編集] ウィザードのフィールドの入力を完了するには、Unified Access Gateway 構成の前提条件に記載されている情報を入力する必要があります。ゲートウェイを追加しているときと同時に 2 要素認証の設定も行う場合は、2 要素認証構成でデプロイする際の前提条件に記載されている情報を入力する必要があります。外部ゲートウェイ構成を追加し、独自のサブスクリプションを使用する場合はそのサブスクリプション情報も必要です。追加するゲートウェイに使用する VNet が VNet の要件を満たしていることを確認します。これらの VNet 要件については、Microsoft Azure で必要な仮想ネットワークを構成するを参照してください。

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

手順

  1. コンソールで [設定] > [キャパシティ] に移動し、ポッドの名前をクリックしてその詳細ページを開きます。
  2. ポッドの詳細ページで、[編集] をクリックします。
  3. [サブスクリプション] の手順で、外部ゲートウェイ構成を追加し、ポッドとは別のサブスクリプションを使用する場合は、[外部ゲートウェイに別のサブスクリプションを使用] を有効にして、サブスクリプション情報を入力します。
  4. [ゲートウェイ設定] の手順に到達するまで [次へ] をクリックします。
    この手順には、外部ゲートウェイ構成のセクションと、内部ゲートウェイ構成のセクションが含まれています。ユーザー インターフェイスには、ポッドの現在の構成と、すでに存在するゲートウェイ設定が反映されます。
  5. 外部ゲートウェイを追加するには、[外部 UAG を有効にしますか? ] トグルをオンに切り替えて、[外部 UAG] セクションのフィールドに入力します。
    オプション 説明
    [外部ゲートウェイを有効にしますか?] ポッドに外部ゲートウェイ構成があるかどうかを制御します。外部構成を使用すると、企業のネットワークの外部にいるユーザーがデスクトップおよびアプリケーションにアクセスできるようになります。ポッドには、このアクセスを提供する Microsoft Azure ロード バランサ リソースと Unified Access Gateway インスタンスが含まれています。
    注: デフォルトの有効になっている設定にしておくことをお勧めします。

    このトグルをオフにすると、クライアントはポッドと統合された Workspace ONE Access を介して、またはポッド マネージャのロード バランサに直接接続するか、内部ゲートウェイ構成を介して接続する必要があります。クライアントがポッドに統合された Workspace ONE Access を介して、または直接接続する場合、いくつかのデプロイ後の手順が必要です。 この場合、ポッドがデプロイされた後、Horizon Cloud ポッドのマネージャ仮想マシンでの SSL 証明書の構成の手順に従います。

    [FQDN] サービスへのアクセスでエンド ユーザーが使用する完全修飾ドメイン名 (FQDN) を入力します(例:ourOrg.example.com)。このドメイン名を所有し、その FQDN を検証可能な PEM 形式の証明書を取得する必要があります。
    重要: この FQDN には、アンダー スコアを含めることはできません。このリリースでは、FQDN にアンダー スコアが含まれていると、 Unified Access Gateway インスタンスへの接続が失敗します。
    [DNS アドレス] オプションで、Unified Access Gateway が名前解決に使用できる追加の DNS サーバのアドレスを、カンマ区切りで入力します。オンプレミスの RADIUS サーバで 2 要素認証を使用するためにこの外部 Unified Access Gateway 構成を設定するときは、オンプレミスの RADIUS サーバの名前を解決できる DNS サーバのアドレスを指定します。

    デプロイの前提条件 で説明したように、最初に DNS サーバをサブスクリプション内にセットアップし、外部名を解決できるように構成する必要があります。Unified Access Gateway インスタンスは、デフォルトではその DNS サーバを使用します。このフィールドにアドレスを指定する場合、デプロイした Unified Access Gateway インスタンスは、サブスクリプションの仮想ネットワークで構成した前提条件の DNS サーバに加えて、アドレスを使用します。

    [ルート] オプションで、デプロイした Unified Access Gateway インスタンスが、エンド ユーザー アクセス用のネットワークのルーティングを解決するために使用する、追加のゲートウェイへのカスタム ルートを指定します。指定したルートは、Unified Access Gateway が 2 要素認証の RADIUS サーバなどにネットワーク ルーティングを解決できるようにするために使用されます。

    このポッドをオンプレミスの RADIUS サーバで 2 要素認証を使用するように構成する場合は、Unified Access Gateway インスタンスが RADIUS サーバに接続するための正しいルートを入力する必要があります。たとえば、オンプレミスの RADIUS サーバがその IP アドレスとして 10.10.60.20 を使用している場合、10.10.60.0/24 とデフォルト ルートのゲートウェイ アドレスをカスタム ルートとして入力することになります。この環境で使用している Express ルートまたは VPN 構成からデフォルト ルートのゲートウェイ アドレスを取得します。

    形式 ipv4-network-address/bits ipv4-gateway-address で、カンマ区切りリストとしてカスタム ルートを指定します(例:192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2)。

    [仮想マシン モデル] Unified Access Gateway インスタンスに使用するモデルを選択します。このポッドに指定した Microsoft Azure サブスクリプションが、選択したモデルの 2 台の仮想マシンのキャパシティを確実に満たすようにする必要があります。
    [証明書] Microsoft Azure で実行中の Unified Access Gateway インスタンスへの接続をクライアントが信頼できるようにするために、Unified Access Gateway で使用される PEM 形式の証明書をアップロードします。証明書は、入力した FQDN に基づいたものにして、信頼されている認証局 (CA) によって署名されている必要があります。PEM ファイルに、SSL 証明書の中間証明書、ルート CA 証明書、プライベート キーを含む、完全な証明書チェーンが含まれている必要があります。

    このゲートウェイの Microsoft ロード バランサの設定を指定します。

    オプション 説明
    [パブリック IP アドレスを有効にしますか?] このゲートウェイのロード バランシング タイプがプライベートとして構成されるか、パブリックとして構成されるかを制御します。オンに切り替えると、デプロイされた Microsoft Azure ロード バランサ リソースがパブリック IP アドレスで構成されます。オフに切り替えると、Microsoft Azure ロード バランサ リソースがプライベート IP アドレスで構成されます。
    重要: このリリースでは、外部ゲートウェイのロード バランシング タイプを後でパブリックからプライベートに、またはプライベートからパブリックに変更することはできません。この変更を行う唯一の方法は、デプロイされたポッドからゲートウェイ構成を完全に削除してから、ポッドを編集して逆の設定で追加することです。

    このトグルを無効にすると、[Horizon FQDN のパブリック IP アドレス] フィールドが表示されます。

    [Horizon FQDN のパブリック IP アドレス] デプロイされた Microsoft Azure ロード バランサにパブリック IP を構成しないことを選択した場合、エンド ユーザーの Horizon Client がゲートウェイとの PCoIP 接続に使用する FQDN に DNS でマッピングする IP アドレスを提供する必要があります。デプロイヤは、この IP アドレスを Unified Access Gateway 構成の設定で構成します。

    外部ゲートウェイのネットワーク設定を指定します。

    オプション 説明
    [別の仮想ネットワークを使用] このトグルは、外部ゲートウェイをポッドの VNet とは別の専用の VNet にデプロイするかどうかを制御します。

    次の行は、さまざまなケースを示しています。

    注: ウィザードの最初のステップで外部ゲートウェイに別のサブスクリプションを使用するように指定した場合、このトグルはデフォルトで有効になっています。その場合は、ゲートウェイの VNet を選択する必要があります。
    [別の仮想ネットワークを使用] — 無効 トグルを無効にすると、外部ゲートウェイがポッドの VNet にデプロイされます。この場合は、DMZ サブネットを指定する必要があります。
    • [DMZ サブネット] - ポッドのセットアップ ウィザード手順で [既存のサブネットを使用] を有効にすると、[DMZ サブネット] には [仮想ネットワーク] に対して選択された VNet 上で使用可能なサブネットが表示されます。ポッドの DMZ サブネットに使用する既存のサブネットを選択します。
      重要: 接続されているその他のリソースがない空のサブネットを選択します。サブネットが空でない場合、デプロイ プロセス中またはポッドの操作中に予期しない結果が発生する可能性があります。
    • [DMZ サブネット (CIDR)] - 前のウィザード手順で [既存のサブネットを使用] が無効になっている場合、DMZ(非武装地帯)ネットワークのサブネットを CIDR 表記で入力します。このネットワークは、Unified Access Gateway インスタンスをゲートウェイの Microsoft Azure パブリック ロード バランサに接続するように構成されます。
    [別の仮想ネットワークを使用] — 有効 トグルを有効にすると、外部ゲートウェイが専用の VNet にデプロイされます。この場合、使用する VNet を選択してから、必要な 3 つのサブネットを指定する必要があります。[既存のサブネットを使用] トグルを有効にして、指定した VNet で事前に作成したサブネットから選択します。そうでない場合は、サブネットを CIDR 表記で指定します。
    重要: 接続されているその他のリソースがない空のサブネットを選択します。サブネットが空でない場合、デプロイ プロセス中またはポッドの操作中に予期しない結果が発生する可能性があります。

    この場合、ゲートウェイの VNet とポッドの VNet がピアリングされます。ベスト プラクティスは、サブネットを事前に作成し、ここで CIDR エントリを使用しないことです。ポッドの VNet またはサブスクリプションとは別の専用の VNet またはサブスクリプションを使用して外部 Unified Access Gateway 構成でデプロイする場合の前提条件を参照してください。

    • 管理サブネット - ゲートウェイの管理サブネットに使用するサブネットを指定します。少なくとも /27 の CIDR が必要です。このサブネットにはサービス エンドポイントとして Microsoft.SQL サービスが構成されている必要があります。
    • バックエンド サブネット - ゲートウェイのバックエンド サブネットに使用するサブネットを指定します。少なくとも /27 の CIDR が必要です。
    • フロントエンド サブネット - Unified Access Gateway インスタンスをゲートウェイの Microsoft Azure パブリック ロード バランサに接続するように構成されるフロントエンド サブネットのサブネットを指定します。
  6. (オプション) [デプロイ] セクションで、トグルを使用して、必要に応じてデプロイヤが外部ゲートウェイ構成のリソースを展開する既存のリソース グループを選択します。
    このトグルは、ウィザードの最初のステップで外部ゲートウェイに別のサブスクリプションを使用するように指定した場合に表示されます。トグルを有効にすると、リソース グループを検索して選択するフィールドが表示されます。
  7. 内部ゲートウェイを追加するには、[内部 UAG を有効にしますか? ] トグルをオンに切り替えて、[内部 UAG] セクションのフィールドに入力します。
    オプション 説明
    [内部ゲートウェイを有効にしますか?] ポッドに内部ゲートウェイ構成があるかどうかを制御します。内部構成は、企業のネットワーク内に存在するユーザーが HTML Access (Blast) でデスクトップおよびアプリケーションに接続するときに信頼されたアクセスを提供します。ポッドには、このアクセスを提供する Azure ロード バランサ リソースと Unified Access Gateway インスタンスが含まれています。デフォルトでは、このゲートウェイのロード バランシング タイプはプライベートです。ロード バランサは、プライベート IP アドレスで構成されます。
    [FQDN] サービスへのアクセスでエンド ユーザーが使用する完全修飾ドメイン名 (FQDN) を入力します(例:ourOrg.example.com)。このドメイン名を所有し、その FQDN を検証可能な PEM 形式の証明書を取得する必要があります。

    外部ゲートウェイに FQDN を指定した場合は、ここで同じ FQDN を入力する必要があります。

    重要: この FQDN には、アンダー スコアを含めることはできません。このリリースでは、FQDN にアンダー スコアが含まれていると、 Unified Access Gateway インスタンスへの接続が失敗します。
    [DNS アドレス] オプションで、Unified Access Gateway が名前解決に使用できる追加の DNS サーバのアドレスを、カンマ区切りで入力します。オンプレミスの RADIUS サーバで 2 要素認証を使用するようにこの内部ゲートウェイ構成を設定するときは、オンプレミスの RADIUS サーバの名前を解決できる DNS サーバのアドレスを指定します。

    デプロイの前提条件 で説明したように、最初に DNS サーバをサブスクリプション内にセットアップし、名前を解決できるように構成する必要があります。Unified Access Gateway インスタンスは、デフォルトではその DNS サーバを使用します。このフィールドにアドレスを指定する場合、デプロイした Unified Access Gateway インスタンスは、サブスクリプションの仮想ネットワークで構成した前提条件の DNS サーバに加えて、アドレスを使用します。

    [ルート] オプションで、デプロイした Unified Access Gateway インスタンスが、エンド ユーザー アクセス用のネットワークのルーティングを解決するために使用する、追加のゲートウェイへのカスタム ルートを指定します。指定したルートは、Unified Access Gateway が 2 要素認証の RADIUS サーバなどにネットワーク ルーティングを解決できるようにするために使用されます。

    このポッドをオンプレミスの RADIUS サーバで 2 要素認証を使用するように構成する場合は、Unified Access Gateway インスタンスが RADIUS サーバに接続するための正しいルートを入力する必要があります。たとえば、オンプレミスの RADIUS サーバがその IP アドレスとして 10.10.60.20 を使用している場合、10.10.60.0/24 とデフォルト ルートのゲートウェイ アドレスをカスタム ルートとして入力することになります。この環境で使用している Express ルートまたは VPN 構成からデフォルト ルートのゲートウェイ アドレスを取得します。

    形式 ipv4-network-address/bits ipv4-gateway-address で、カンマ区切りリストとしてカスタム ルートを指定します(例:192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2)。

    [仮想マシン モデル] Unified Access Gateway インスタンスに使用するモデルを選択します。このポッドに指定した Microsoft Azure サブスクリプションが、選択したモデルの 2 台の仮想マシンのキャパシティを確実に満たすようにする必要があります。
    [証明書] Microsoft Azure で実行中の Unified Access Gateway インスタンスへの接続をクライアントが信頼できるようにするために、Unified Access Gateway で使用される PEM 形式の証明書をアップロードします。証明書は、入力した FQDN に基づいたものにして、信頼されている認証局 (CA) によって署名されている必要があります。PEM ファイルに、SSL 証明書の中間証明書、ルート CA 証明書、プライベート キーを含む、完全な証明書チェーンが含まれている必要があります。
  8. 追加しているいずれかのゲートウェイのセクションで、オプションで RADIUS 2 要素認証を使用するようにエンド ユーザーのデスクトップを構成する場合は、Horizon Cloud ポッドのゲートウェイでの 2 要素認証の有効化の手順に従います。
  9. [保存して終了] をクリックします。
    ワークフローの開始を確認するよう求める確認メッセージが表示されます。
  10. [はい] をクリックしてワークフローを開始します。

結果

ゲートウェイの要素をシステムがデプロイ完了するまで、ポッドのサマリ ページにおけるその構成タイプのセクションには、保留中 ステータスが表示されます。また、システムがゲートウェイをデプロイするアクションを完了するまで、追加の [ポッドを編集] ワークフロー関連のアクティビティを実行することはできません。

ワークフローが完了すると、ステータスには 準備完了 と表示され、ロード バランサの FQDN がページに表示されます。

注: Microsoft Azure China のポッドに対してこのワークフローを実行する場合、プロセスが完了するまでに 1 時間以上かかることがあります。このプロセスは地理的なネットワークの問題の影響を受け、バイナリがクラウドの制御プレーンからダウンロードされるときにダウンロードの速度が低下することがあります。

次のタスク

重要: エンド ユーザーが新たに追加されたゲートウェイの使用を開始できるようにするには、次のタスクを実行する必要があります。
  • 新しく追加されたゲートウェイ構成の場合、構成でデプロイされるロード バランサをデプロイ ウィザードで入力した FQDN にマッピングする CNAME レコードが DNS サーバにあることを確認します。詳細については、DNS サーバでマッピングするポッドのゲートウェイのロード バランサ情報の取得を参照してください。
  • 追加されたゲートウェイに 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 システムの更新を参照してください。