第 1 世代テナント - 検証と続行、およびポッドのデプロイ プロセスの開始

[検証と続行] をクリックした後、指定した値がシステムによって検証されます。すべてが検証されると、ウィザードに確認のための情報の概要が表示されます。次にデプロイ プロセスを開始します。

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

手順

1. [検証と続行] をクリックします。
   次のような指定した値がシステムによって検証されます。

   • これから作成されるサブネットのために指定したアドレス範囲が有効で、サブスクリプション内で選択したリージョンの他のアドレスと重複していないか。
   • サブスクリプションのクォータに、ポッドを構築するための十分な仮想マシン (VM) とコアがあるか。
   • アップロードされた証明書ファイルは正しい PEM 形式か。
   • 既存の管理サブネットを使用することを選択した場合、そのサブネットで Microsoft.Sql サービス エンドポイントが有効になっていますか。

   重要： 2019 年 9 月のサービス リリース以降、ポッドの Microsoft Azure PostgreSQL データベースの使用をサポートするために、新しいポッドのデプロイでは管理サブネットで Microsoft.Sql サービス エンドポイントが有効になっている必要があります。管理サブネットでエンドポイントを有効にする必要があることを示す検証エラーが表示された場合は、Microsoft Azure ポータルにログインし、サブネットで Microsoft.Sql サービス エンドポイントを有効にする必要があります。その後、ウィザードを再送信してポッドをデプロイできます。エンドポイントを有効にする方法の詳細については、 第 1 世代テナント - ポッドのデプロイの前に、Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブネットを作成するを参照してください。

   すべてが検証されると、[サマリ] ページが表示されます。

   ネットワーク アドレスの重複に関するエラー メッセージが表示される場合は、サブスクリプションに同じ値を使用している既存のサブネットがあるかどうかを確認します。

2. ウィザードの最終手順で、概要情報を確認して、[送信] をクリックします。
   Microsoft Azure 環境へのポッドのデプロイを開始します。
   

   

   
   

結果

Microsoft Azure Cloud と Horizon Cloud 制御プレーン間のネットワーク トラフィックによっては、デプロイに 30 ～ 45 分かかることがあります。

ポッドが正常にデプロイされるまで、進捗状況のアイコンがコンソールの [はじめに] 画面に表示されます。進捗状況を確認するときに、ブラウザ画面の更新が必要になる場合があります。ブラウザ ベースのユーザー インターフェイスは、約 30 分後にタイムアウトして、ログインし直すよう要求することができます。

重要： Microsoft Azure China クラウドにポッドをデプロイする場合、デプロイのプロセス全体が完了するまでに最大で 7 時間かかることがあります。このプロセスは、 DNS 要件ページに記載されているように、デプロイヤがアクセスする必要があるホスト名へのトラフィックが遅くなる可能性がある、地理的なネットワークの問題の影響を受けます。

20 分後にポッドが Pending から Downloading の状態に変化せず、またデプロイ先が Microsoft Azure China ではない場合、システムはポッドを自動的に Error 状態に設定します。また、ポッドをクラウド サービスに接続できないため、Microsoft Azure 環境のネットワーク接続状態を確認するように促すメッセージが表示されます。

ポッドが Error 状態であることが表示される場合、環境のネットワーク構成またはファイアウォールが、DNS 要件ページに記載されている 1 つ以上の必須ロケーションへのアクセスを拒否していることが原因であると思われます。たとえば、VNet の設定済み DNS が内部名または外部名を解決していない、必要なアウトバウンド ポートが開いていない、またはファイアウォールによってブロックされている可能性があります。*.azure.com ホスト名への接続が一時的に失われることがあります。いくつかのテストを実行し、ポッドの要件に対して環境ネットワークが適切に構成されているかどうかを検証することができます。ポッドのデプロイまたは初めてのドメイン バインドで問題が発生した場合のトラブルシューティングで始まるページのコンテンツを参照してください。

ポッドのデプロイ プロセス全体を通して、[はじめに] ページの [キャパシティ] セクションには、プロセスの現在のステージ（保留中、ダウンロード中、構築中、接続中など）が示されます。

次の表は、ポッドを構築するステージについての、およその期間の例をいくつか示しています。

重要： デプロイの進行状況で発生する実際の期間は、その時点で存在するネットワーク遅延によって異なります。

ステージ	期間の例
保留中	1 分または 2 分
ダウンロード中	1 分または 2 分
構成中	20 分
接続中	10 分

ポッドが正常にデプロイされた場合：

• Horizon Cloud が、対応する Horizon Cloud 顧客アカウント レコードで識別されるアカウント所有者に通知 E メールを送信します。この E メールには、ポッドのオンボーディングが完了したことが記載されています。
• [はじめに] 画面に緑色のチェックマークが表示されます。

この時点では、Active Directory ドメインがポッドにまだ登録されていないため、[管理] メニューで [ポッドを削除] オプションを使用できます。何らかの理由でデプロイ プロセスが失敗する場合、または使用した値が好ましくないため Active Directory ドメインを登録する前に再びやり直したい場合、[管理] > [ポッドを削除] の順にクリックしてデプロイされたアーティファクトを削除することができます。ポッドが正常に削除されたことが画面に示されたら、[管理] > [ポッドを追加] の順に再度クリックしてプロセスを再開することができます。次のスクリーンショットは、[管理] > [ポッドを削除] オプションの場所を示しています。

ネットワーク遅延のため、この時点でポッドを削除することを選ぶと、すべてポッド関連のアーティファクトが完全に Microsoft Azure 環境から削除される前に、[はじめに] ページでポッドが完全に削除されたことが示される可能性があります。新しいポッドを削除した後、ポッドのデプロイ ウィザードを再び実行する前に、次の手順を行います。

1. Horizon Cloud ユーザー インターフェイスからログアウトします。
2. Microsoft Azure ポータルにログインします。
3. 作成した VNet に移動します。
4. デプロイヤを使用してポッドのサブネットを自動作成した場合は、ポッドにより作成されたサブネットがないこと、およびそのポッドのサブネットに対して指定したアドレス範囲が VNet のアドレス空間から削除されていることを確認してください。

次に、 Horizon Cloud にログインし直して、ポッドのデプロイ ウィザードを再び実行します。

次のタスク

[はじめに] 画面の [全般的なセットアップ] を展開し、Active Directory ドメインの登録に必要な作業を完了します。次に必要な作業は Active Directory の登録です。ドメインを登録し、ドメイン グループのスーパー管理者ロールを設定すると、システムではすべてのコンソールにアクセスできるようになります。続いて、コンソールでこのポッドの管理を続行します。『Horizon Cloud 管理ガイド』のはじめにを参照してください。Active Directory ドメインを登録したら、[はじめに] ウィザードに従って、次に完了するタスクを確認します。

指定したゲートウェイのタイプに応じて、DNS サーバに適切な CNAME レコードを設定する必要があります。DNS サーバでマッピングする Horizon Cloud ポッドのゲートウェイのロード バランサ情報の取得方法に記載された CNAME の情報を参照してください。

外部および内部ゲートウェイ構成の両方に同じ FQDN を使用する場合は、ポッドのデプロイ後に、受信するエンドユーザー クライアントのトラフィックを、ゲートウェイのリソース グループ内の適切なロード バランサ リソースにルーティングするための設定を行う必要があります。目標は、インターネットからのクライアント トラフィックが外部ゲートウェイの Microsoft Azure パブリック ロード バランサにルーティングされ、イントラネットからのクライアント トラフィックが内部ゲートウェイの Microsoft Azure 内部ロード バランサにルーティングされるようにルーティングを設定することです。両方のゲートウェイで同じ FQDN を使用する場合、スプリット DNS（スプリット Domain Name System）を構成して、エンド ユーザー クライアントの DNS クエリのオリジン ネットワークに応じて、外部ゲートウェイまたは内部ゲートウェイのいずれかにゲートウェイ アドレスを解決します。

ポッドのゲートウェイ構成に 2 要素認証を指定した場合は、次のタスクを実行する必要があります。

• ポッドの外部ゲートウェイに 2 要素認証が構成され、ゲートウェイの Unified Access Gateway インスタンスがデプロイされているのと同じ VNet トポロジ内で 2 要素認証サーバにアクセスできない場合は、外部ゲートウェイのロード バランサの IP アドレスからの通信を許可するようにその 2 要素認証サーバを構成します。

  このシナリオでは、ゲートウェイ展開と同じ VNet トポロジ内で 2 要素認証サーバにアクセスできないため、Unified Access Gateway インスタンスは、そのロード バランサ アドレスを使用してそのサーバとの接続を試みます。その通信トラフィックを許可するには、その外部ゲートウェイのリソース グループにあるロード バランサ リソースの IP アドレスが、確実に 2 要素認証サーバの構成でクライアントまたは登録されたエージェントとして指定されているようにします。この通信を許可する方法の詳細については、お使いの 2 要素認証サーバのドキュメントを参照してください。

• 同じ VNet トポロジ内で 2 要素認証サーバにアクセスできる場合は、Microsoft Azure でのデプロイの Unified Access Gateway インスタンス用に作成された適切な NIC からの通信を許可するように 2 要素認証サーバを構成します。

  ネットワーク管理者が、展開に使用される Azure VNet トポロジとそのサブネットに対する 2 要素認証サーバのネットワーク可視性を決定します。2 要素認証サーバは、ネットワーク管理者が 2 要素認証サーバにネットワークの可視性を与えたサブネットに対応する Unified Access Gateway インスタンスの NIC の IP アドレスからの通信を許可する必要があります。

  Microsoft Azure のゲートウェイのリソース グループには、そのサブネットに対応する 4 つの NIC があり、そのうち 2 つが 2 個の Unified Access Gateway インスタンスに対して現在アクティブです。もう 2 つはアイドル状態で、ポッドとそのゲートウェイが更新を完了した後にアクティブになります。

  実行中のポッド操作のため、および各ポッドの更新後のために、ゲートウェイと 2 要素認証サーバ間の通信トラフィックをサポートするには、これらの 4 つの NIC の IP アドレスがそのサーバ構成でクライアントまたは登録されたエージェントとして指定されていることを確認します。この通信を許可する方法の詳細については、お使いの 2 要素認証サーバのドキュメントを参照してください。

これらの IP アドレスを取得する方法については、必要な Horizon Cloud ポッド ゲートウェイ情報での 2 要素認証システムの更新トピックを参照してください。