セッション ホスト仮想マシンの構成

  • [アーティクル]

重要

この内容は、Azure Resource Manager Azure Virtual Desktop オブジェクトを含む Azure Virtual Desktop に適用されます。 Azure Resource Manager オブジェクトを含まない Azure Virtual Desktop (クラシック) を使用している場合は、こちらの記事を参照してください。

この記事は、Azure Virtual Desktop セッション ホスト仮想マシン (VM) の構成時に発生する問題のトラブルシューティングを行うときに使用してください。

フィードバックの提供

Azure Virtual Desktop Tech Community にアクセスし、Azure Virtual Desktop サービスに関して製品チームや活発なコミュニティのメンバーと意見を交わしてください。

VM がドメインに参加していません

仮想マシン (VM) をドメインに参加させることができない場合は、次の手順に従ってください。

エラー:資格情報が間違っています

原因: Azure Resource Manager テンプレート インターフェイスの修正で資格情報が入力されたとき、入力ミスがありました。

解決策: 解決するには、次のいずれかの操作を行ってください。

エラー:ユーザー入力の待機中にタイムアウトになりました

原因: ドメイン参加の完了に使用するアカウントに多要素認証 (MFA) が設定されている可能性があります。

解決策: 解決するには、次のいずれかの操作を行ってください。

  • アカウントの MFA を一時的に削除します。
  • サービス アカウントを使用します。

エラー:プロビジョニング中に使用されたアカウントに、操作を完了するためのアクセス許可が与えられていません。

原因: 使用中のアカウントには、コンプライアンスと規則により、ドメインに VM を参加させるためのアクセス許可が与えられていません。

解決策: 解決するには、次のいずれかの操作を行ってください。

  • 管理者グループに属するアカウントを使用します。
  • 必要なアクセス許可を使用中のアカウントに与えます。

エラー:ドメイン名が解決されません。

原因 1: ドメインが置かれている仮想ネットワーク (VNET) に関連しない仮想ネットワークに VM が入っています。

解決策 1: VM がプロビジョニングされた VNET と、ドメイン コントローラー (DC) が実行されている VNET の間に VNET ピアリングを作成します。 「仮想ネットワーク ピアリングを作成する - Resource Manager、異なるサブスクリプション」を参照してください。

原因 2: Microsoft Entra Domain Services を使用する場合、仮想ネットワークの DNS サーバーの設定が、管理対象のドメイン コントローラーを指すように更新されません。

修正 2: Microsoft Entra Domain Services を含む仮想ネットワークの DNS 設定を更新するには、「Azure 仮想ネットワークの DNS 設定を更新する」を参照してください。

原因 3: ネットワーク インターフェイスの DNS サーバー設定が、仮想ネットワーク上の適切な DNS サーバーを指していません。

解決策 3: 次のいずれかの操作を実行して、[DNS サーバーの変更] の手順に従って解決します。

  • [DNS サーバーの変更] の手順に従って、ネットワーク インターフェイスの DNS サーバー設定を [カスタム] に変更し、仮想ネットワーク上の DNS サーバーのプライベート IP アドレスを指定します。
  • [DNS サーバーの変更] の手順に従って、ネットワーク インターフェイスの DNS サーバー設定を [仮想ネットワークから継承する] に変更し、その後、[DNS サーバーの変更] の手順に従って、仮想ネットワークの DNS サーバーの設定を変更します。

Azure Virtual Desktop エージェントと Azure Virtual Desktop ブート ローダーがインストールされていません

推奨される VM のプロビジョニング方法は、Azure portal 作成テンプレートを使用することです。 このテンプレートにより、Azure Virtual Desktop エージェントと Azure Virtual Desktop ブート ローダーが自動的にインストールされます。

次の手順でコンポーネントがインストールされていることを確認し、エラー メッセージがないか確認します。

  1. [コントロール パネル]>、 [プログラム]>、 [プログラムと機能] の順に選択し、2 つのコンポーネントがインストールされていることを確認します。 Azure Virtual Desktop エージェントと Azure Virtual Desktop ブート ローダーが表示されない場合は、VM にインストールされていません。
  2. エクスプローラーを開き、C:\Windows\Temp\ScriptLog.log に移動します。 ファイルがない場合、2 つのコンポーネントをインストールした PowerShell DSC が、指定されたセキュリティ コンテキストで実行できなかったことを示しています。
  3. ファイル C:\Windows\Temp\ScriptLog.log がある場合、それを開き、エラー メッセージがないか確認します。

エラー: Azure Virtual Desktop エージェントと Azure Virtual Desktop ブート ローダーがありません C:\Windows\Temp\ScriptLog.log もありません

原因 1: Azure Resource Manager テンプレートに入力中に指定された資格情報が間違っているか、アクセス許可が足りません。

解決策 1: 「PowerShell を使用してホスト プールを作成する」の手順で VM に足りないコンポーネントを手動追加します。

原因 2: PowerShell DSC は起動し、実行できましたが、Azure Virtual Desktop にサインインして必要な情報を得ることができないため、実行を完了できませんでした。

解決策 2: 次のリストにある項目を確認します。

  • アカウントに MFA が指定されていないことを確認します。
  • ホスト プールの名前が正しく、ホスト プールが Azure Virtual Desktop に存在することを確認します。
  • 少なくとも Azure サブスクリプションまたはリソース グループに対する共同作成者アクセス許可がアカウントに与えられていることを確認します。

エラー:認証失敗、C:\Windows\Temp\ScriptLog.log にエラー

原因: PowerShell DSC は実行できましたが、Azure Virtual Desktop に接続できませんでした。

解決策: 次のリストにある項目を確認します。

  • VM を Azure Virtual Desktop サービスに手動で登録します。
  • Azure サブスクリプションまたはリソース グループでホスト プールを作成するためのアクセス許可が、Azure Virtual Desktop への接続に使用されるアカウントに与えられていることを確認します。
  • アカウントに MFA が指定されていないことを確認します。

Azure Virtual Desktop エージェントが Azure Virtual Desktop サービスに登録されません

(手動か、Azure Resource Manager テンプレートと PowerShell DSC によって) Azure Virtual Desktop エージェントが最初にセッション ホスト VM にインストールされたとき、登録トークンが与えられます。 次のセクションでは、Azure Virtual Desktop エージェントとトークンに適用される問題のトラブルシューティングについて説明します。

エラー:AzWvdSessionHost コマンドレットの状態フィールドに、状態が Unavailable (利用不可) と示されています

Get-AzWvdSessionHost cmdlet shows status as Unavailable.

原因: エージェントを新しいバージョンに更新できません。

解決策: 次の手順でエージェントを手動更新します。

  1. セッション ホスト VM に新しいバージョンのエージェントをダウンロードします。
  2. タスク マネージャーを起動し、[サービス] タブで RDAgentBootLoader サービスを停止します。
  3. 新しいバージョンの Azure Virtual Desktop エージェントのインストーラーを実行します。
  4. 登録トークンを求められたら、エントリ INVALID_TOKEN を削除し、[次へ] を押します (新しいトークンは要求されません)。
  5. インストール ウィザードを完了します。
  6. タスク マネージャーを開き、RDAgentBootLoader サービスを開始します。

エラー: Azure Virtual Desktop エージェントのレジストリ エントリ IsRegistered に値 0 が表示されます

原因: 登録トークンの有効期限が切れています。

解決策: 次の手順でエージェント レジストリ エラーを修正します。

  1. 登録トークンが既に存在する場合は、Remove-AzWvdRegistrationInfo を使用してそれを削除します。
  2. New-AzWvdRegistrationInfo コマンドレットを実行して、新しいトークンを生成します。
  3. -ExpriationTime パラメーターが 3 日に設定されていることを確認します。

エラー: Get-AzWvdSessionHost を実行したとき、Azure Virtual Desktop エージェントからハートビートが報告されません

原因 1: RDAgentBootLoader サービスが停止しました。

解決策 1: タスク マネージャーを起動し、[サービス] タブで RDAgentBootLoader サービスの状態が停止になっている場合、サービスを起動します。

原因 2: ポート 443 が閉じられている可能性があります。

解決策 2: 次の手順でポート 443 を開きます。

  1. Sysinternal ツールから PSPing ツールをダウンロードし、ポート 443 が開いていることを確認します。

  2. エージェントが実行されているセッション ホスト VM に PSPing をインストールします。

  3. 管理者としてコマンド プロンプトを開き、下のコマンドを実行します。

    psping rdbroker.wvdselfhost.microsoft.com:443

  4. PSPing で RDBroker から返された情報が受け取られることを確認します。

    PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2016 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP connect to 13.77.160.237:443:
5 iterations (warmup 1) ping test:
Connecting to 13.77.160.237:443 (warmup): from 172.20.17.140:60649: 2.00ms
Connecting to 13.77.160.237:443: from 172.20.17.140:60650: 3.83ms
Connecting to 13.77.160.237:443: from 172.20.17.140:60652: 2.21ms
Connecting to 13.77.160.237:443: from 172.20.17.140:60653: 2.14ms
Connecting to 13.77.160.237:443: from 172.20.17.140:60654: 2.12ms
TCP connect statistics for 13.77.160.237:443:
Sent = 4, Received = 4, Lost = 0 (0% loss),
Minimum = 2.12ms, Maximum = 3.83ms, Average = 2.58ms

Azure Virtual Desktop サイドバイサイド スタックで問題を解決する

サイドバイサイド スタックは主に 3 とおりの方法でセッション ホスト プール VM にインストールされるか、有効化されます。

  • Azure portal 作成テンプレートを使用する
  • マスター イメージに含まれ、有効になっている
  • 各 VM に手動でインストールし、有効にする (あるいは、extensions/PowerShell を使用する)

Azure Virtual Desktop サイドバイサイド スタックに問題がある場合、コマンド プロンプトから qwinsta コマンドを入力し、サイドバイサイド スタックがインストールされ、有効になっていることを確認します。

サイドバイサイド スタックがインストールされ、有効になっている場合、qwinsta の出力には、rdp-sxs が一覧表示されます。

Side-by-side stack installed or enabled with qwinsta listed as rdp-sxs in the output.

下に記載されているレジストリ エントリを調べ、その値が一致することを確認します。 レジストリ キーがないか、値が一致しない場合は、サポートされているオペレーティング システムを実行していることを確認してください。 これに該当する場合は、「ホスト プールにセッション ホストを登録する」にあるサイドバイサイド スタックの再インストール方法を実行してください。

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
    Server\WinStations\rds-sxs\"fEnableWinstation":DWORD=1

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
    Server\ClusterSettings\"SessionDirectoryListener":rdp-sxs

エラー:O_REVERSE_CONNECT_STACK_FAILURE

O_REVERSE_CONNECT_STACK_FAILURE error code.

原因: サイドバイサイド スタックがセッション ホスト VM にインストールされていません。

解決策: 次の手順で、セッション ホスト VM にサイドバイサイド スタックをインストールします。

  1. リモート デスクトップ プロトコル (RDP) を使用し、ローカル管理者としてセッション ホスト VM に直接入ります。
  2. 「ホスト プールにセッション ホストを登録する」の手順に従って、サイドバイサイド スタックをインストールします。

正しく動作していない Azure Virtual Desktop サイドバイサイド スタックを修正する方法

サイドバイサイド スタックに誤作動を引き起こす状況が確認されています。

  • 正しい手順でサイドバイサイド スタックを有効にしていない
  • Windows 10 Enhanced Versatile Disc (EVD) の自動更新
  • リモート デスクトップ セッション ホスト (RDSH) ロールがない

このセクションの手順は、Azure Virtual Desktop サイドバイサイド スタックをアンインストールする際に参考になります。 サイドバイサイド スタックをアンインストールしたら、「ホスト プールにセッション ホストを登録する」の手順に従ってサイドバイサイド スタックを再インストールします。

修復に使用される VM は、誤作動するサイドバイサイド スタックがある VM と同じサブネットならびにドメインに置かれている必要があります。

同じサブセットならびにドメインから次の手順で修復します。

  1. 標準のリモート デスクトップ プロトコル (RDP) で、修正プログラムを適用する VM に接続します。

  2. PsExec をダウンロードしてインストールします。

  3. コマンド プロンプトをローカル管理者として起動し、PsExec が解凍されたフォルダーに移動します。

  4. コマンド プロンプトから、次のコマンドを使用します。ここで、<VMname> は、サイドバイサイド スタックが誤作動する VM のホスト名です。 初めて PsExec を実行する場合は、[同意する] をクリックして続行するには、PsExec 使用許諾契約書に同意する必要もあります。

    psexec.exe \\<VMname> cmd

  5. サイドバイサイド スタックが誤作動する VM でコマンド プロンプト セッションが開いたら、以下のコマンドを実行し、rdp-sxs という名前のエントリがあることを確認します。 エントリがない場合、サイドバイサイド スタックは VM 上にありません。そのため、問題はサイドバイサイド スタックに関連したものではありません。

    qwinsta

    Administrator command prompt

  6. 次のコマンドを実行します。このコマンドによって、サイドバイサイドが誤作動する VM にインストールされている Microsoft コンポーネントが一覧表示されます。

    wmic product get name

  7. 上記の手順から得られた製品名を指定し、下のコマンドを実行します。例:

    wmic product where name="<Remote Desktop Services Infrastructure Agent>" call uninstall

  8. リモート デスクトップで始まるすべての製品をアンインストールします。

  9. すべての Azure Virtual Desktop コンポーネントがアンインストールされたら、(Azure portal または PsExec ツールを使用して) サイドバイサイド スタックが誤作動している VM を再起動します。 次に、「ホスト プールにセッション ホストを登録する」の手順に従って、サイドバイサイド スタックを再インストールできます。

リモート デスクトップ ライセンス モードが構成されていない

管理者アカウントを使用して Windows 10 Enterprise マルチセッションにサインインしている場合、「Remote Desktop licensing mode isn't configured, Remote Desktop Services will stop working in X days. On the Connection Broker server, use Server Manager to specify the Remote Desktop licensing mode. （リモート デスクトップ ライセンス モードが構成されていません。リモート デスクトップ サービスはあと X 日で動作を停止します。Connection Broker サーバーで、サーバー マネージャーを使用してリモート デスクトップ ライセンス モードを指定してください。）」と書かれた通知を受信する可能性があります。

制限時間が経過すると、「このコンピューターで利用できるリモート デスクトップ クライアント アクセス ライセンスがないため、リモート セッションは切断されました」というエラー メッセージが表示されます。

これらのメッセージのいずれかが表示された場合は、イメージに最新の Windows 更新プログラムがインストールされていないか、グループ ポリシーでリモート デスクトップ ライセンス モードを設定していることを意味します。 次のセクションの手順に従って、グループ ポリシーの設定を確認し、Windows 10 Enterprise マルチセッションのバージョンを特定して、対応する更新プログラムをインストールしてください。

注意

Azure Virtual Desktop では、ホスト プールに Windows Server セッション ホストが含まれている場合は、RDS クライアント アクセス ライセンス (CAL) のみが必要です。 RDS CAL を構成する方法については、「クライアント アクセス ライセンス (CAL) を使用して RDS 展開をライセンスする」を参照してください。

リモート デスクトップ ライセンス モードのグループ ポリシーの設定を無効にする

グループ ポリシーの設定を確認するには、VM でグループ ポリシーエディターを開いて、 [管理用テンプレート]>[Windows コンポーネント]>[リモート デスクトップ サービス]>[リモート デスクトップ セッション ホスト]>[ライセンス]>[リモート デスクトップ ライセンス モードの設定] の順に移動します。 グループポリシーの設定が [有効] の場合は、 [無効] に変更します。 既に無効の場合は、そのままにしておきます。

注意

ご自身のドメインを使用してグループ ポリシーを設定する場合は、これらの Windows 10 Enterprise マルチセッション VM を対象としたポリシーでこの設定を無効にします。

使用している Windows 10 Enterprise マルチセッションのバージョンを特定する

使用している Windows 10 Enterprise マルチセッションのバージョンを特定するには、次のようにします。

  1. 管理者アカウントを使用してサインインします。

  2. [スタート] メニューの横にある検索バーに「About」と入力します。

  3. [PC 情報] を選択します。

  4. [バージョン] の横の数字を確認します。次の図に示すように、数値は "1809" または "1903" のいずれかである必要があります。

    A screenshot of the Windows specifications window. The version number is highlighted in blue.

バージョン番号がわかったら、該当するセクションに進んでください。

バージョン 1809

バージョン番号が "1809" の場合は、KB4516077 更新プログラムをインストールします。

バージョン 1903

Azure ギャラリーから、最新バージョンの Windows 10 バージョン 1903 イメージを使用して、ホスト オペレーティング システムを再デプロイします。

We couldn't connect to the remote PC because of a security error (セキュリティ エラーのため、リモート PC に接続できませんでした)

"セキュリティ エラーのため、リモート PC に接続できませんでした。 この問題が引き続き発生する場合は、管理者または技術サポートにお問い合わせください" というエラーがユーザーに表示された場合は、既定の RDP アクセス許可を変更する既存のポリシーを確認してください。 このエラーを発生させる可能性があるポリシーの 1 つは、"リモート デスクトップ サービスを使ったログオンを許可" セキュリティ ポリシーです。

このポリシーの詳細については、「リモート デスクトップ サービスを使ったログオンを許可」を参照してください。

ゴールデン イメージをデプロイできない

ゴールデン イメージには、Azure Virtual Desktop エージェントを含めることはできません。 エージェントは、ゴールデン イメージをデプロイした後にのみインストールできます。

次のステップ