Microsoft Azure の第 1 世代 Horizon Cloud ポッドで使用する環境のネットワークが正しく構成されていないと、ポッドを構築するプロセスが PENDING 状態のままになる場合や、デプロイ後の Active Directory 環境へのドメイン バインドのアクションが失敗する可能性があります。必要な送信ポートを開くことができないことと、DNS が内部アドレスと外部アドレスの両方を解決できないことの 2 つが、最も一般的なネットワーク関連の原因です。ここで説明するトラブルシューティングの手順を実行することで、必要な送信ポートが開いていることと、DNS が内部アドレスと外部アドレスの両方を解決できることを確認するためのテストを実行できます。

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

ポッドを正常にデプロイするためのネットワーク全体の要件は、前提条件のチェックリストに示されていて、第 1 世代テナント - Microsoft Azure の Horizon Cloud ポッドに使用する VNet トポロジに必要な DNS サーバの設定および第 1 世代テナント - Horizon Cloud on Microsoft Azure のデプロイ - ホスト名解決の要件、DNS 名に記載されています。環境のネットワークがこれらの要件を満たしていない場合は、次のいずれかまたは両方の問題が発生します。

問題 一般的な原因
  • [はじめに] ページにポッドが保留状態であることが示され、接続状態にならない。通常、ポッドは約 10 分間保留状態になります（Microsoft Azure China クラウドにポッドを展開する場合は例外で、さらに時間がかかります）。
  • ポッドが正常にデプロイされた場合でも、Active Directory を登録しようとすると、ドメインバインドの手順がエラー「Unable to register Active Directory」で失敗する。
  • 必要な送信ポートが開いていないか、ファイアウォール環境によってブロックされています。必要な送信ポートが開いていない、またはファイアウォールによってブロックされている場合、ポッド ソフトウェアは Microsoft Azure クラウド環境に安全にダウンロードされず、Horizon Cloud クラウド制御プレーンに接続できません。その結果、保留状態のままになる問題が発生します。
  • VNet DNS サーバが、内部マシン名と外部マシン名の両方を解決できる有効な DNS サーバを参照するように適切に構成されていません。
  • VNet DNS サーバは DNS サーバを正しく参照していますが、DNS サーバは内部マシン名と外部マシン名の両方を解決できません。

外部マシン名の DNS 解決が VNet に提供されない場合、保留状態が続く問題とドメインバインドの問題が発生する可能性があります。たとえば、DNS がドメイン コントローラの Active Directory に解決できない場合、ドメインバインドの手順は失敗します。VNet の DNS 構成の詳細については、第 1 世代テナント - Microsoft Azure の Horizon Cloud ポッドに使用する VNet トポロジに必要な DNS サーバの設定を参照してください。

DNS 構成が内部名と外部名を解決できること、および必要な送信ポートが開いていることを確認するためのいくつかのテストを実行するには、Microsoft Azure サブスクリプションに小さなテスト用仮想マシン (VM) をデプロイし、その仮想マシンを使用してこれらのネットワーク テストを実行します。トラブルシューティング手順の概要は次のとおりです。

  1. SSH キー ペアを作成します。
  2. Microsoft Azure サブスクリプションにテスト用仮想マシンを作成します。
  3. テスト用仮想マシンに接続します。
  4. ネットワーク テストを実行します。
  5. テストが完了したら、テスト用仮想マシンと、このトラブルシューティングを行うために Microsoft Azure 環境で作成されたすべてのテスト関連のアーティファクトを削除します。
注： テスト関連のアーティファクトを削除せず、後でポッドを削除するためにコンソールの [削除] アクションを使用すると、予期しない結果が発生する可能性があります。ポッドを削除するときに、システムはサブネットに接続されているすべてのものがポッドの ID に応じてポッド自体に属していることを確認するために、ポッドのサブネットをチェックします。追加の仮想マシン、仮想マシンのディスク、IP、またはその他のアーティファクトがポッドのサブネットに接続されているとシステムによって判断された場合は、システムがポッドをクリーンに削除することはできません。

トラブルシューティング テストの実行の詳細については、次のセクションを参照してください。

重要： これらの手動テストはすべて成功しても、オンプレミス ネットワークを介してすべてのトラフィックを送信し、認証されたトラフィックのみを通過させ、ポッド デプロイ ウィザードでプロキシを使用するための値を指定しなかった場合、ポッドのデプロイは保留状態のままになることがあります。この説明が状況に一致する場合は、[はじめに] ページからポッドを削除し、ポッド デプロイ ウィザードを再実行し、必要なプロキシ情報を指定する必要があります。

Horizon Cloud ポッドのデプロイのトラブルシューティング - SSH キー ペアを作成する

このトラブルシューティングの一環として、テスト用 Linux 仮想マシンが Microsoft Azure サブスクリプションにデプロイされます。テスト用 Linux 仮想マシンに対して認証するには、SSH キー ペアが必要です。キー ペアはテスト用仮想マシンに SSH 接続するために使用するシステムで作成します。そのシステム上にすでにキー ペアがある場合、この手順はオプションです。

この SSH キー ペアを作成するには、Microsoft Windows または Linux システムのいずれかを使用できます。ここでは両方のタイプのシステムでの手順を説明します。実際の状況に適した手順を選択してください。

Microsoft Windows システム上で SSH キー ペアを作成する

Microsoft Windows システムを使用して、Microsoft Azure サブスクリプションにデプロイするテスト用 Linux 仮想マシン に SSH 接続する場合は、以下の手順を使用します。

Microsoft Azure でテスト用仮想マシンを作成する場合、生成されたパブリック キー ファイルの内容を使用します。テスト用仮想マシンに接続するために使用する Microsoft Windows システム上に既存の SSH キー ペアがある場合は、この手順をスキップし、Microsoft Azure サブスクリプションにテスト用仮想マシンを作成するでの説明に従ってテスト用仮想マシンの作成に進むことができます。

次の手順に従って、SSH キー ペアを生成し、パブリック キー ファイルの内容をコピーしてテスト用仮想マシンの作成時に使用できるようにし、プライベート キーを PuTTY Pageant ツールにロードします。Pageant は、プライベート キーをメモリに保持できる SSH 認証エージェントです。プライベート キーをメモリに保持することで、プライベート キーはその Microsoft Windows システムから SSH セッションに対して自動的に適用されるので、簡単に使用できるようになります。

前提条件

デフォルトでは、Microsoft Windows システムには、SSH キー ペア ソフトウェアがインストールされていません。使用する予定があるシステムに SSH キー ペア生成ソフトウェアがインストールされていることを確認します。任意の SSH キー ペア生成ソフトウェアを使用できます。以下の手順では、Microsoft Windows 上で PuTTY ソフトウェアを使用して SSH キー ペアを作成する方法について説明します。PuTTY ソフトウェアは、www.putty.org から取得できます。インストール後、PuTTY の一連のツールを使用できます。次のスクリーンショットは、[スタート] メニューの PuTTY ツールの例を示します。


Microsoft Windows 10 の [スタート] メニューに表示される PuTTY ツールのスクリーンショット

手順

  1. Microsoft Windows システムで、PuTTYgen（PuTTY キー ジェネレータ）を起動します。
    [PuTTY キー ジェネレータ] ウィンドウが表示されます。次のスクリーンショットで強調されているように、目標は SSH-2 RSA タイプで 2048 ビットのパブリック - プライベート キー ペアを生成することです。
    緑色の矢印がキー スポットを示す [PuTTY キー ジェネレータ] ウィンドウのスクリーンショット

  2. [SSH-2RSA] が選択され、ビット数に 2048 が設定されていることを確認し、[生成] をクリックします。ウィンドウは、進行状況バーを示す [キー] ウィンドウに変わります。
  3. 画面に表示される指示に従い、カーソルを進行状況バーの下の空白領域でランダムに動かします。PuTTY ユーザー インターフェイスで示すように、領域内でカーソルを移動すると、必要なランダム性がプロセスに追加されます。
  4. キーのパスフレーズを入力してシステムにプライベート キーを保存し、[プライベート キーを保存] をクリックします。
    注： キー パスフレーズを使用することは、オプションとしてのベスト プラクティスです。ただし、キーのパスフレーズを入力せずに [プライベート キーを保存] をクリックすると、キーのパスフレーズなしでプライベート キーを保存するかを確認するポップアップ ウィンドウが表示されます。
    プライベート キーが PPK ファイルとして保存されます。 [プライベート キーを保存] をクリックした後、ローカル システムのディレクトリを参照し、ファイル名を入力して、ファイルを保存することができます。
  5. [パブリック キーを保存] ボタンを使用して、テスト用仮想マシン の作成時にパブリック キーをコピーできる場所に保存します。
  6. PuTTY の SSH 認証エージェントである Pageant を起動します。
    Windows 10 システムでは、Pageant アイコンがシステム トレイにロードされます。
  7. プライベート キーを Pageant に追加するには、システム トレイ アイコンを右クリックし、[キーを追加] をクリックし、ファイル選択ウィンドウを使用して、保存されたプライベート キー (PPK) ファイルに移動して選択します。
    注： 以前にプライベート キー ファイルを保存したときにキーのパスフレーズを指定した場合は、そのパスフレーズを入力するためのボックスが表示されます。

結果

この時点では、プライベート キーは Pageant にロードされます。アクション メニューの [キーの表示] 項目を使用して、ロードされたキーのリストのキーを表示することができます。PuTTY を使用して SSH セッションを開始すると、PuTTY は Pageant からキーを自動的に取得し、そのキーを使用して認証するので、パスフレーズを入力する必要はありません。後で、SSH セッションの実行を終了して Pageant をシャットダウンするときには、Pageant システムのトレイ アイコンの右クリックメニューから [終了] を選択します。

次のタスク

Microsoft Azure サブスクリプションにテスト用仮想マシンを作成するの手順に従って、テスト用の仮想マシンを作成します。

Linux システム上で SSH キー ペアを作成する

Linux システムを使用して、Microsoft Azure サブスクリプションにデプロイするテスト用 Linux 仮想マシン に SSH 接続する場合は、以下の手順を使用します。

Microsoft Azure でテスト用仮想マシンを作成する手順では、生成されたパブリック キー ファイルの内容を使用します。テスト用仮想マシンに接続するために使用する Linux システム上に既存の SSH キー ペアがある場合は、この手順をスキップし、「Microsoft Azure サブスクリプションにテスト用仮想マシンを作成する」での説明に従ってテスト用仮想マシンの作成に進むことができます。

前提条件

これらの手順を実行する前に、別の目的で保持しておく既存の SSH キー ペアが上書きされないことを確認してください。Linux システムでは、SSH のパブリックおよびプライベート キー ファイルは、デフォルトで Linux の ~/.ssh/id_rsa ディレクトリに作成されます。このディレクトリに SSH キーペアが存在し、次のコマンドを実行するときに同じファイル名を使用する場合、またはコマンド内で別の場所を指定し、その場所に SSH キー ペアがすでに存在する場合は、既存の SSH キー ペアが上書きされます。

手順

  1. Linux システムで、Bash シェルを開きます。
  2. Bash シェルで、次のコマンドを入力します。 
    ssh-keygen -t rsa -b 2048
  3. 画面の指示に従い、キーを保存するファイルを入力し、パスフレーズを入力し、パスフレーズを確認します。
    ここに画面の指示のサンプルを示します。ここでは、キーを保存するファイルとして mykey が入力されました。 
    -bash-4.1$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/mts-cm/home/user1/.ssh/id_rsa): mykey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
    注： キー パスフレーズを使用することは、オプションのベスト プラクティスです。
    プライベート キーは指定したファイルに保存され、パブリック キーは同じ名前で拡張子が .pub のファイルに保存されます。ファイルとして mykey を入力する上記の例を使用した場合、出力サンプルは次のようになります。 
    Your identification has been saved in mykey.
Your public key has been saved in mykey.pub.

次のタスク

Microsoft Azure サブスクリプションにテスト用仮想マシンを作成するの手順に従って、テスト用の仮想マシンを作成します。

Microsoft Azure サブスクリプションにテスト用仮想マシンを作成する

Microsoft Azure 環境でテスト用 Linux 仮想マシン (VM) を使用して、Horizon Cloud ポッドが構成されているネットワーク接続を確認するテストを実行します。

前提条件

Horizon Cloud ポッドのデプロイのトラブルシューティング - SSH キー ペアを作成するでの説明に従って作成した SSH パブリック キーを持っていることを確認します。仮想マシンの作成ウィザードでこのパブリック キーを指定し、対応するプライベート キーを持つシステムからの SSH 接続を仮想マシンが信頼するようにします。

第 1 世代 Horizon Cloud - Microsoft Azure での必要な仮想ネットワークの構成での説明に従って、仮想ネットワーク (VNet) の名前が、ポッドのデプロイで使用しているものと同じであることを確認します。

[ポッドの追加] ウィザードのオプションを使用してポッドに独自の名前付きサブネットを使用せず、代わりにサブネットの CIDR を入力した場合、ポッド デプロイヤはポッドの管理サブネットを作成します。デプロイ プロセスが失敗した時点で、プロセスは VNet でポッドの管理サブネットをすでに作成している可能性があります。

  • デプロイヤがすでにその管理サブネットを作成している場合は、そのサブネットにテスト用仮想マシンをデプロイすることをお勧めします。VNet 上にポッドの管理サブネットが存在するかどうかを確認するには、Microsoft Azure ポータルにログインし、該当の VNet に移動してサブネットのリストを調べます。ポッド デプロイヤがポッドのサブネットを自動的に作成した場合（ポッドに独自の名前付きサブネットを使用するオプションを使用しなかった場合）、ポッドの管理サブネットの名前のパターンは vmw-hcs-podID-net-management になります。ここで podID はポッドの UUID です。それ以外の場合、ポッドの管理サブネットは、ポッドのデプロイ用に作成したサブネットになります。
  • 失敗したデプロイ プロセスで VNet 上にポッドの管理サブネットが作成されなかった場合は、VNet 上で使用可能なサブネットを選択するか、新しいサブネットを作成して、テスト用仮想マシンで使用することができます。

手順

  1. Microsoft Azure ポータルにログインします。
  2. ポータルで、Azure Martketplace からコンピューティング仮想マシンを作成し、その仮想マシンを Ubuntu Server LTS モデル タイプ ベースにします。
    本書の執筆時点では、 Ubuntu Server 20.04 LTS は Azure Marketplace から選択できました。
  3. このテスト用 Linux 仮想マシンを作成する場合は、ウィザードのユーザー インターフェイスに従って、必要なオプションを構成します。以下に示すように、次の項目を構成してください。
    オプション 説明
    [サブスクリプション] ポッドの [ポッドの追加] ウィザードで選択したサブスクリプションと一致します。
    [リソース グループ] テスト用仮想マシンに新しいリソース グループを作成することをお勧めします。画面上のプロンプトに従って、新しいリソース グループを作成します。

    このテスト用仮想マシンには既存のリソース グループを使用することができますが、テストの実行が終了したときにリソース グループ全体を削除した方が、より簡単に仮想マシンおよび関連するアーティファクトを削除できるので、テスト用仮想マシンに固有のリソース グループを使用することをお勧めします。

    [リージョン] ポッドの [ポッドの追加] ウィザードで選択したサブスクリプションと一致します。
    [サイズ] ここでは検証テストを完了するために使用される一時的な仮想マシンを想定しているため、任意のサイズを選択できます。ただし、通常はサイズが小さいほど Microsoft Azure の関連コストが低くなるため、テスト用仮想マシンには 2 vCPU モデルなど小さなサイズを選択するのが一般的です。
    [ユーザー名] この名前は、後で必要になるためメモしておきます。
    [認証タイプ] [SSH パブリック キー] を選択します。
    [SSH パブリック キー ソース] [既存のパブリック キーを使用する] を選択します。SSH パブリック キー フィールドがその選択とともに表示され、SSH パブリック キーを貼り付けることができます。
    [SSH パブリック キー] このフィールドには、SSH キー ペアを作成したときに作成した SSH パブリック キーを貼り付けます。貼り付けられた内容は、パブリック キーの ---- BEGIN SSH2 PUBLIC KEY ---- 行で始まり、---- END SSH2 PUBLIC KEY ---- 行で終わる必要があります。
    [パブリック受信ポート] 選択した SSH (22) ポートを許可して、このテスト用仮想マシンでテストを実行できるようにします。
    [仮想ネットワーク] 失敗したポッドのデプロイに使用されたのと同じ VNet を選択します。
    [サブネット] ポッドをデプロイしようとしてプロセスが失敗した場合は、ポッドの管理サブネットが仮想ネットワークで作成されている可能性があります。サブネットがある場合は、このテスト用仮想マシンにそのサブネットを選択することをお勧めします。選択された仮想ネットワークに存在するサブネットに移動するには、[サブネット] をクリックします。サブネット上にマウスを移動すると、ツールチップにサブネットの完全名が表示されます。

    ポッドのデプロイ プロセスで VNet 上にポッドの管理サブネットが作成されなかった場合は、テスト用仮想マシンに使用するように識別された VNet 上のサブネットを選択します（上記の前提条件を参照）。

    注： ポッドが正常に展開された後、ドメイン参加の問題のトラブルシューティングが発生した場合は、ドメイン参加の操作はそのデスクトップ サブネットに接続されたデスクトップ イメージで使用されるため、管理サブネットの代わりにポッドのデスクトップ サブネットをテスト用仮想マシンのために選択することができます。
    [パブリック IP アドレス] この項目を選択すると、作成されたテスト用仮想マシンにはパブリック IP アドレスが割り当てられます。パブリック IP アドレスが割り当てられたテスト用仮想マシンには Wide Area Network (WAN) 経由で接続できます。
    注： パブリック IP アドレスは、ネットワーク構成によっては使用できない場合があります。パブリック IP アドレスを持つテスト用仮想マシンを作成できない場合は、ローカル システムから、 [サブネット] フィールドで選択したサブネットにネットワーク接続する必要があります。あるいは、ネットワーク上の他のマシンに接続してから、テスト用仮想マシンにインバウンド接続する必要があります。
  4. ウィザードの最終手順では、重要な情報（サブスクリプション、リージョンの場所、仮想ネットワーク、サブネット）がポッドに使用しているものと一致することを確認し、仮想マシンの作成を送信します。

SSH を使用してテスト用仮想マシンに接続する

Microsoft Azure 環境でネットワーク接続テストを実行できるように、テスト用仮想マシンに対して SSH (Secure Shell) 接続を実行します。

Microsoft Windows システムからテスト用仮想マシンに SSH 接続する

この接続は、テスト用仮想マシンの作成時に指定したパブリック キーに対応するプライベート キーを持つ Microsoft Windows システムから行います。

前提条件

テスト用仮想マシンの IP アドレスと、仮想マシンの作成時に指定したユーザー名があることを確認します。

Microsoft Windows システムでは、通常 PuTTY が使用されます。SSH セッションを開始するときに PuTTY がプライベート キーを簡単に読み込むことができるように、PuTTY を起動する前に、Microsoft Windows システム上で SSH キー ペアを作成するでの説明に従って Pageant を起動し、SSH プライベート キーを Pageant キー リストに追加します。SSH プライベート キーは、テスト用仮想マシンの作成時に指定したパブリック キーと一致する必要があります。プライベート キーが Pageant に読み込まれると、PuTTY の SSH セッションはそのプライベート キーを自動的に使用します。

手順

  1. PuTTY を起動します（Microsoft Windows 10 の [スタート] メニューで [PuTTY] を選択）。
    [PuTTY 構成] ウィンドウが開きます。
  2. [PuTTY 構成] ウィンドウでホスト名を指定し、[SSH] を選択してから [開く] をクリックします。
    [PuTTY 構成] ウィンドウの [ホスト名] フィールドに、次のパターンで文字列を入力します。 
    testvm_username@testvmip
    テスト用仮想マシンのユーザー名と IP アドレスを、それぞれ文字列の testvm_username と testvmip に代入します。
    重要： [開く] をクリックした後、初めてテスト用仮想マシンに接続するときに、サーバのホスト キーがキャッシュされていないことを示す PuTTY セキュリティ メッセージが表示され、サーバの rsa2 キー フィンガープリントが表示されます。接続を続行する場合は、 [はい] をクリックしてサーバのホスト キーを PuTTY のキャッシュに追加するか、 [いいえ] をクリックしてキーを PuTTY のキャッシュに追加せずに接続することができます。テスト用仮想マシンへの接続がされていない可能性がある場合は、 [キャンセル] をクリックして接続を破棄し、[PuTTY 構成] ウィンドウに戻り、ホスト名の入力を確認します。
    次のスクリーンショットは、このサンプルを使用したウィンドウを示します。 
    [email protected]

    値が入力された、[PuTTY 構成] ウィンドウを示すスクリーンショット。緑色の矢印は、[ホスト名] フィールド、[SSH] ボタン、および [開く] ボタンを指しています。

結果

SSH 接続が確立されると、コマンドライン ウィンドウが表示されます。

次のタスク

テスト用仮想マシンに接続したら、テストを実行して Microsoft Azure 環境内のネットワーク接続をチェックできます。Microsoft Azure 環境でネットワークを確認するためのテストを実行するで説明する手順を実行します。

Linux システムからテスト用仮想マシンに SSH 接続する

この接続は、テスト用仮想マシンの作成時に指定したパブリック キーに対応するプライベート キーを持つ Linux システムから行います。

前提条件

テスト用仮想マシンの IP アドレスと、仮想マシンの作成時に指定したユーザー名があることを確認します。

手順

  1. Bash シェルを開きます。
  2. Bash シェルの $ プロンプトで、次のように ssh コマンドを入力し、テスト用仮想マシンの IP アドレスとユーザー名を、それぞれコマンドの testvmip と testvm_username に代入します。 
    ssh testvm_username@testvmip
    たとえば、 Microsoft Azure サブスクリプションにテスト用仮想マシンを作成するの例にあるテスト用仮想マシンの詳細を使用すると、サンプル コマンドは次のようになります。 
    ssh [email protected]

結果

SSH 接続が確立されると、次のスクリーンショットのようなコマンドライン ウィンドウが表示されます。
接続された SSH セッションのサンプル

次のタスク

テスト用仮想マシンに接続したら、テストを実行して Microsoft Azure 環境内のネットワーク接続を確認できます。Microsoft Azure 環境でネットワークを確認するためのテストを実行するで説明する手順を実行します。

Microsoft Azure 環境でネットワークを確認するためのテストを実行する

ここでのテストを実行することで、DNS が内部アドレスと外部アドレスの両方を解決できる、および必要な送信ポートが開いている、という 2 つのネットワーク関連の領域が適切に設定されていることを確認します。これらのテストは、テスト用仮想マシンを使用して実行します。

ポッドは DNS によって内部アドレスと外部アドレスの両方を解決します。ここでの最初の 2 つのテストでは、ネットワーク環境で設定された DNS が、内部アドレスと外部アドレスの既知の FQDN を解決できるかを確認します。

重要： これらの手動テストはすべて成功しても、オンプレミス ネットワークを介してすべてのトラフィックを送信し、認証されたトラフィックのみを通過させ、ポッド デプロイ ウィザードでプロキシを使用するための値を指定しなかった場合、ポッドのデプロイは保留状態のままになることがあります。この説明が状況に一致する場合は、[はじめに] ページからポッドを削除し、ポッド デプロイ ウィザードを再実行し、必要なプロキシ情報を指定する必要があります。

前提条件

これらのテストを実行する前に、Microsoft Azure サブスクリプションにテスト用仮想マシンを作成するおよびSSH を使用してテスト用仮想マシンに接続するでの説明に従って、Microsoft Azure サブスクリプションでテスト用仮想マシンを作成し、SSH 接続があることを確認します。

Active Directory ドメイン コントローラなど、VNet からアクセス可能であると考えられるネットワークの内部にあるサーバの IP アドレスと完全修飾ドメイン名 (FQDN) を取得します。この情報は、DNS 検証テストで使用します。

手順

  1. dlg コマンドを使用して Microsoft Azure の VNet の内部にある既知のドメイン名をクエリすることにより、DNS が環境内で動作し、内部 FQDN を解決できることを確認します。
    SSH 接続ウィンドウで、 dig コマンドを実行し、Active Directory ドメイン コントローラなどネットワークの内部にあることがわかっているサーバのドメイン名をクエリします。 
    dig internal-domain-name
    ここで、 internal-domain-name は、ネットワークの内部にあることがわかっているサーバの完全修飾ドメイン名です。

    dig (Domain Information Groper) は、ネットワーク トラブルシューティングのためのコマンドライン ツールです。内部ホスト名を使用してこのコマンドを実行した結果により、DNS 構成が内部アドレスを適切に解決できるかどうかが検証されます。DNS 構成がコマンドで使用される internal-domain-name を解決できる場合、コマンド出力はそのドメイン名に関連付けられた正しい IP アドレスを返します。

    たとえば VNet が、DNS エントリが skylo.local で IP アドレスが 192.168.0.15 の Active Directory ドメイン コントローラを持つ内部 Active Directory サーバで構成されているとします。 dig skylo.local を発行すると、VNet の DNS 構成がその内部の skylo.local サーバ名を解決できるかどうかがチェックされます： 
    testvmadmin@HCS-testingVM:~$ dig skylo.local

; <<>> DiG 9.10.3-P4-Ubuntu <<>> skylo.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64899
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;skylo.local.                   IN      A

;; ANSWER SECTION:
skylo.local.            600     IN      A       192.168.0.15

;; Query time: 1 msec
;; SERVER: 192.168.0.15#53(192.168.0.15)
;; WHEN: Mon Mar 26 20:58:01 UTC 2018
;; MSG SIZE  rcvd: 56

testvmadmin@HCS-testingVM:~$
    ANSWER SECTION が、指定したホスト名がそのホスト名に対して予測される IP アドレスに解決されたことを示している場合は、テストは成功です。
    注： 場合によっては DNS が完全に信頼できるものではなく、一部の要求は正常に解決され、他の要求は失敗することがあります。コマンドの最初の発行が失敗する場合は、コマンドを 10 ～ 20 回繰り返して実行し、信頼できる応答が毎回得られるかどうかを確認します。
  2. dlg コマンドを使用して既知の外部ドメイン名をクエリすることにより、DNS が環境内で動作し、外部 FQDN を解決できることを確認します。
    SSH 接続ウィンドウで、 dig コマンドを発行し、 vmware.com または microsoft.com などの外部の業界標準ドメイン名をクエリします。 
    dig external-domain-name
    ここで、 external-domain-name は、VNet の外部にある完全修飾ドメイン名です。たとえば、 dig vmware.com を発行すると VNet の DNS 構成がその外部名を解決できたかどうかチェックします。 
    testvmadmin@HCS-testingVM:~$ dig vmware.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> vmware.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38655
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;vmware.com.                    IN      A

;; ANSWER SECTION:
vmware.com.             150     IN      A       107.154.105.19
vmware.com.             150     IN      A       107.154.106.19

;; Query time: 28 msec
;; SERVER: 192.168.0.15#53(192.168.0.15)
;; WHEN: Mon Mar 26 21:14:29 UTC 2018
;; MSG SIZE  rcvd: 71

testvmadmin@HCS-testingVM:~
    上記の例では、ANSWER SECTION は外部ドメイン名 vmware.com が 2 つの IP アドレスに適切に解決されたことを示しています。
    注： このテストを azure.com や microsoft.com などのさまざまな外部ドメイン名を使用して繰り返し、DNS が異なる外部名を解決できることを確認できます。
    DNS テストが機能しない場合は、ネットワーク構成および DNS サーバを確認してください。DNS サーバを VNet に追加したことを確認します。
    重要： DNS サーバを VNet に追加する必要がある場合、または VNet の DNS サーバ構成を変更する必要がある場合は、VNet に接続されているすべての仮想マシンを再起動して変更を反映する必要があります。VNet の DNS サーバ設定を変更した後、その VNet に接続されたすべての仮想マシンを再起動しないと、変更は VNet 上で正しく伝達されません。
  3. netcat コマンドを使用して、必要な送信ポートが使用可能であることを確認します。
    Horizon Cloud ではいくつかの送信ポートを開く必要があります。それによって、ポッド ソフトウェアを Microsoft Azure 環境に安全にダウンロードすることができ、またポッドを Horizon Cloud 制御プレーンに戻すことができます。 第 1 世代テナント - Horizon Cloud on Microsoft Azure のデプロイ - ホスト名解決の要件、DNS 名で説明するように、以下の送信 TCP ポートをポッドの管理サブネットから開く必要があります：port 80、443、および 11371。以下に示すように netcat コマンドを実行すると、それらの送信ポートが要求されるとおりに開いていることを確認できます。
    SSH 接続ウィンドウで、次のコマンドを発行します（ポートごとに 1 つ）。
    注： ポート 11371 をテストする以下のコマンドは packages.microsoft.com を指定してその接続をテストし、他の 2 つの行は Horizon Cloud 制御プレーンへの送信接続をテストします。 
    testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 80
Connection to cloud.horizon.vmware.com 80 port [tcp/http] succeeded!
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 443
Connection to cloud.horizon.vmware.com 443 port [tcp/https] succeeded!
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 packages.microsoft.com 11371
Connection to packages.microsoft.com 11371 port [tcp/hkp] succeeded!
    ポートが正常に開くと、 netcat コマンドはそのテストに対して succeeded! 行を返します。
    netcat コマンドが失敗を返す場合は、Microsoft Azure のネットワーク接続、サブスクリプションのネットワーク セキュリティ グループ、および使用しているファイアウォールを確認します。 第 1 世代テナント - Horizon Cloud on Microsoft Azure のデプロイ - ホスト名解決の要件、DNS 名で説明されているように、ポッドがデプロイのために必要とする DNS、ポート、およびプロトコルの要件を、ネットワーク構成が確実に満たすようにします。

結果

上記のテストが成功した場合は、ポッドを正常にデプロイすることができます。

注： True SSO または認証サーバを使用する 2 要素認証など、ポッドで使用するオプションの機能を構成している場合は、それらの目的に応じて追加のポートが必要になることがあります。上記の送信ポートのテスト方法を使用して、それらのポートが適切に開いていることを確認することができます。

次のタスク

テストを完了したら、Microsoft Azure 環境からテスト用仮想マシンと、その仮想マシンのディスク、IP アドレス、NIC などの関連するアーティファクトのすべてを削除する必要があります。理想的には、テスト仮想マシンのリソース グループを作成してあり、単純にそのリソース グループを削除することで仮想マシンのすべてのアーティファクトを削除できることが望ましいです。テストの完了後にテスト用仮想マシンを削除する の手順に従います。

重要： Microsoft Azure 環境からすべてのテスト用仮想マシンのアーティファクトを削除しないで、仮想マシンをポッドのサブネットの 1 つに接続した場合、後でポッドの [削除] アクションを使用して Horizon Cloud 環境からポッドを削除しようとしても、システムはこれらの残りの接続されているアーティファクトのためにポッドを完全に削除できない可能性があります。デフォルトでは、 [削除] アクションを使用してポッドを削除する場合に、 Horizon Cloud はポッドのために作成したこれらのリソース グループおよびサブネットを削除します。Microsoft Azure は、継続して使用中であるサブネットの削除を防止します。テスト用仮想マシンのアーティファクトがポッドのサブネットに接続されている場合は、これらのサブネットは削除できず、ポッドの削除は完了しません。この状況を回避するには、ポッドを正常にデプロイした後に、テスト用仮想マシンのすべてのアーティファクトが確実に削除されるようにします。

テストの完了後にテスト用仮想マシンを削除する

Microsoft Azure のネットワーク構成を確認するためのテストを完了し、テスト用仮想マシンが不要になったら、Microsoft Azure 環境からその仮想マシンと関連するすべてのアーティファクトを削除する必要があります。

重要： Microsoft Azure 環境からすべてのテスト用仮想マシンのアーティファクトを削除しないで、仮想マシンをポッドのサブネットの 1 つに接続した場合、後でポッドの [削除] アクションを使用して Horizon Cloud 環境からポッドを削除しようとしても、システムはこれらの残りの接続されているアーティファクトのためにポッドを完全に削除できない可能性があります。デフォルトでは、 [削除] アクションを使用してポッドを削除する場合に、 Horizon Cloud はポッドのために作成したこれらのリソース グループおよびサブネットを削除します。Microsoft Azure は、継続して使用中であるサブネットの削除を防止します。テスト用仮想マシンのアーティファクトがポッドのサブネットに接続されている場合は、これらのサブネットは削除できず、ポッドの削除は完了しません。この状況を回避するには、ポッドを正常にデプロイした後に、テスト用仮想マシンのすべてのアーティファクトが確実に削除されるようにします。

手順

  1. Microsoft Azure ポータルにログインします。
  2. テスト用仮想マシンは、そのデプロイ方法に応じて次のいずれかの方法で削除します。
    • テスト用仮想マシンを独自のリソース グループにデプロイし、そのグループを他の目的で使用していない場合は、リソース グループ全体を削除できます。
      注意： 誤って他のアイテムを削除するのを回避するため、リソース グループを削除する前に、リソース グループにはテスト用仮想マシンと、ディスクやネットワーク アダプタなどの関連オブジェクトのみが含まれるようにします。
    • リソース グループ全体を削除せずにテスト用仮想マシンを削除する必要がある場合は、ポータルの検索ボックスを使用してテスト用の仮想マシンの名前を検索できます。検索結果には、仮想マシンとそのすべての関連オブジェクト（ディスク、ネットワーク インターフェイス、パブリック IP アドレスなど）が一覧表示されます。各オブジェクトを個別に削除します。