Azure Virtual Desktop エージェントに関する一般的な問題をトラブルシューティングする
Azure Virtual Desktop エージェントでは、次の複数の要因のために接続に関する問題が発生することがあります。
- エージェントのサービスを停止させるブローカーでのエラー。
- 更新に関する問題。
- セッション ホストへの接続を中断させる、エージェントのインストール中のインストールに関する問題。
この記事では、これらの一般的なシナリオの解決策と、接続に関する問題に対処する方法について説明します。
注意
セッションの接続性と Azure Virtual Desktop エージェントに関連する問題のトラブルシューティングについては、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動して、セッション ホスト仮想マシン (VM) のイベント ログを確認することをお勧めします。 問題を特定するために、次のいずれかのソースがあるイベントを探してください。
- WVD-Agent
- WVD-Agent-Updater
- RDAgentBootLoader
- MsiInstaller
エラー:RDAgentBootLoader またはリモート デスクトップ エージェント ローダー、あるいはその両方が動作を停止した
次のいずれかの問題が発生している場合は、エージェントを読み込むブート ローダーでエージェントを正しくインストールできなかったため、エージェント サービスがセッション ホスト VM 上で動作していないことを示します。
- RDAgentBootLoader が停止したか、または動作していない。
- リモート デスクトップ エージェント ローダーの状態がない。
この問題を解決するには、RDAgent ブート ローダーを起動します。
[サービス] ウィンドウで、 [リモート デスクトップ エージェント ローダー] を右クリックします。
[スタート] を選択します。 このオプションが灰色表示されている場合は、管理者のアクセス許可がありません。 サービスを開始するために、これらのアクセス許可を取得する必要があります。
10 秒待ってから、 [リモート デスクトップ エージェント ローダー] を右クリックします。
[最新の情報に更新] を選択します。
開始して更新した後にサービスが停止する場合は、登録エラーが発生している可能性があります。 詳細については、INVALID_REGISTRATION_TOKEN またはEXPIRED_MACHINE_TOKEN に関する記述を参照してください。
エラー: INVALID_REGISTRATION_TOKEN または EXPIRED_MACHINE_TOKEN
セッション ホスト VM で、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動します。 ID 3277 のイベント (記述 INVALID_REGISTRATION_TOKEN または EXPIRED_MACHINE_TOKEN を伴って) が表示されている場合は、使用されている登録キーが有効として認識されていません。
この問題を解決するには、次の手順を実行します。
「登録キーの生成」の手順に従って、新しい登録キーを作成します。
管理者として PowerShell プロンプトを開き、次のコマンドを実行して新しい登録キーをレジストリに追加します。
<RegistrationToken>を、生成した新しい登録トークンに置き換えます。$newKey = '<RegistrationToken>' Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name "IsRegistered" -Value 0 -Force Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name "RegistrationToken" -Value $newKey -Force次に、以下のコマンドを実行して、
RDAgentBootLoaderサービスを再起動します。Restart-Service RDAgentBootLoader次のコマンドを実行して、IsRegistered が 1 に設定されていること、RegistrationToken が空白であることを確認します。
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name IsRegistered | FL IsRegistered Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name RegistrationToken | FL RegistrationToken次の出力のような出力になる必要があります。
IsRegistered : 1 RegistrationToken :ご利用のセッション ホストがホスト プール内で無効になっていないか確認します。 そうでない場合は、イベント ビューアーのエントリを表示して、エージェントの起動を妨げるエラーがないか確認します。
エラー: エージェントを INVALID_FORM ブローカーに接続できない
セッション ホスト VM で、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動します。 ID 3277 のイベント (説明に INVALID_FORM と示される) が表示されている場合は、エージェントが特定のブローカーに接続したり、特定のエンドポイントに到達したりすることはできません。 この問題は、特定のファイアウォールまたは DNS の設定が原因である可能性があります。
この問題を解決するには、BrokerResourceIdURI と BrokerResourceIdURIGlobal と呼ばれる 2 つのエンドポイントに到達できることを確認します。
レジストリ エディターを開きます。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RDInfraAgent に移動します。
BrokerResourceIdURI と BrokerResourceIdURIGlobal の値をメモしておきます。
Web ブラウザーを開き、アドレス バーに BrokerResourceIdURI の値を入力し、末尾に /api/health を追加します (例:
https://rdbroker-g-us-r0.wvd.microsoft.com/api/health)。ブラウザーで別のタブを開き、アドレス バーに BrokerResourceIdURIGlobal の値を入力し、末尾に /api/health を追加します (例:
https://rdbroker.wvd.microsoft.com/api/health)。ネットワークによってブローカーへの接続がブロックされていない場合は、両方のページが正常に読み込まれ、次のスクリーンショットに示すように "RD Broker is Healthy" というメッセージが表示されます。
ネットワークによってブローカー接続がブロックされている場合は、次のスクリーンショットに示すように、ページは読み込まれません。
必要なエンドポイントのブロックを解除してから、手順 4 から 7 を繰り返す必要があります。 詳細については、「必要な URL リスト」を参照してください。
これまでの手順を実行しても問題が解決されない場合は、エージェントからブローカーへの接続をブロックする暗号を含むグループ ポリシーが存在しないことを確認します。 Azure Virtual Desktop では、Azure Front Door と同じ TLS 1.2 暗号化を使用します。 詳細については、「接続のセキュリティ」を参照してください。
エラー: 3703
セッション ホスト VM で、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動します。 ID 3703 のイベント (説明に RD Gateway Url: is not accessible (RD ゲートウェイ URL にアクセスできません) と示される) が表示されている場合は、エージェントのゲートウェイ URL へのアクセスを有効にできません。 セッション ホストに正常に接続するには、「必要な URL リスト」にある URL へのネットワーク トラフィックを許可する必要があります。 また、ファイアウォールまたはプロキシの設定によってこれらの URL がブロックされていないことも確認してください。 これらの URL のブロックの解除は、Azure Virtual Desktop を使用するために必要です。
この問題を解決するには、必要な URL チェック ツールを実行して、必要な URL へアクセスできるかどうかを確認します。 Azure Firewall を使用している場合、Azure Virtual Desktop 用に構成する方法について詳しくは、「Azure Firewall を使用して Azure Virtual Desktop のデプロイを保護する」および「Azure Firewall の DNS 設定」を参照してください。
エラー: 3019
セッション ホスト VM で、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動します。 ID 3019 のイベントが表示されている場合、エージェントは Web ソケット トランスポートの URL へアクセスできません。 セッション ホストに正常に接続し、ネットワーク トラフィックを許可してこれらの制限をバイパスするには、「必要な URL リスト」にリストされている URL のブロックを解除する必要があります。 ご担当のネットワーク チームと協力して、ファイアウォール、プロキシ、DNS 設定でそれらの URL がブロックされていないことを確認してください。 また、ネットワーク トレース ログを確認して、Azure Virtual Desktop サービスがブロックされている場所を特定することもできます。 この特定の問題に対する Microsoft サポート ケースを開く場合は、必ずネットワーク トレース ログをリクエストに添付してください。
エラー: InstallationHealthCheckFailedException
セッション ホスト VM で、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動します。 ID 3277 のイベント (説明に InstallationHealthCheckFailedException と示される) が表示されている場合は、ターミナル サーバーによってスタック リスナーのレジストリ キーが切り替えられたため、そのスタック リスナーが動作していません。
この問題を解決するには、次の手順を実行します。
スタック リスナーが動作していることを確認します
スタック リスナーが動作していない場合は、手動でスタック コンポーネントをアンインストールして再インストールしてください。
エラー: ENDPOINT_NOT_FOUND
セッション ホスト VM で、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動します。 ID 3277 のイベント (説明に ENDPOINT_NOT_FOUND と示される) が表示されている場合は、接続を確立するエンドポイントをブローカーによって見つけることができませんでした。 この接続の問題は、次のいずれか 1 つが原因で発生することがあります。
- ホスト プールにセッション ホスト VM が 1 つもない。
- ホスト プール内のセッション ホスト VM がアクティブでない。
- ホスト プール内のすべてのセッション ホスト VM がセッションの上限を超えている。
- ホスト プール内のどの VM でも、エージェント サービスが実行されていない。
この問題を解決するには、次の手順を実行します。
VM の電源が入っており、かつホスト プールから削除されていないことを確認します。
VM がセッションの上限を超えていないことを確認します。
エージェント サービスが実行されていて、かつスタック リスナーが動作していることを確認します。
エージェントをブローカーに接続できることを確認します。
VM に有効な登録トークンがあることを確認します。
VM 登録トークンの有効期限が切れていないことを確認します。
エラー:InstallMsiException
セッション ホスト VM で、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動します。 ID 3277 のイベント (説明に InstallMsiException と示される) が表示されている場合は、エージェントをインストールしようとするときにインストーラーが既に別のアプリケーションのために動作しているか、グループ ポリシーによって msiexec.exe の実行がブロックされています。
グループ ポリシーによって msiexec.exe の実行がブロックされているかどうかを確認するには、次の手順を実行します。
管理者特権のコマンド プロンプトから rsop.msc を実行して、[ポリシーの結果セット] を開きます。
ポップアップ表示される [ポリシーの結果セット] ウィンドウで、[コンピューターの構成] > [管理用テンプレート]>[Windows コンポーネント]>[Windows インストーラー]>[Windows インストーラーをオフにする] に移動します。 状態が [有効] になっている場合は、Active Directory チームと協力して
msiexec.exeの実行を許可します。![[ポリシーの結果セット] での Windows インストーラー ポリシーのスクリーンショット](media/gpo-policy.png)
注意
この一覧はポリシーの包括的な一覧ではなく、現在認識されているものだけです。
エラー:Win32Exception
セッション ホスト VM で、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動します。 ID 3277 のイベント (説明に InstallMsiException と示される) が表示されている場合は、ポリシーによって cmd.exe の起動がブロックされています。 このプログラムをブロックすると、エージェントが更新されるたびにサービスを再開するために使用する必要のあるコンソール ウィンドウが実行されなくなります。
管理者特権のコマンド プロンプトから rsop.msc を実行して、[ポリシーの結果セット] を開きます。
ポップアップ表示される [ポリシーの結果セット] ウィンドウで、[ユーザーの構成] > [管理用テンプレート] > [システム] > [コマンド プロンプトにアクセスできないようにする] に移動します。 状態が [有効] になっている場合は、Active Directory チームと協力して
cmd.exeの実行を許可します。
エラー:スタック リスナーが Windows 10 2004 セッション ホスト VM で動作していない
セッション ホスト VM で、コマンド プロンプトから qwinsta.exe を実行し、[セッション名] 列の rdp-sxs の横に表示されるバージョン番号をメモします。 rdp-tcp エントリと rdp-sxs エントリの [状態] 列が [Listen] でない場合、または rdp-tcp エントリと rdp-sxs エントリが一覧にない場合は、スタックに問題があることを意味します。 スタックの更新プログラムはエージェントの更新プログラムと共にインストールされますが、更新が正常に行われなかった場合、Azure Virtual Desktop リスナーは動作しません。
この問題を解決するには、次の手順を実行します。
レジストリ エディターを開きます。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations に移動します。
[WinStations] には、さまざまなスタック バージョン用のいくつかのフォルダーが表示されることがあります。コマンド プロンプトで
qwinsta.exeを実行したときに表示されたバージョン情報に一致するフォルダーを選択します。fReverseConnectMode を見つけ、そのデータ値が 1 であることを確認します。 また、fEnableWinStation が 1 に設定されていることも確認してください。
fReverseConnectMode が 1 に設定されていない場合は、 [fReverseConnectMode] を選択し、その値フィールドに「1」と入力します。
fEnableWinStation が 1 に設定されていない場合は、 [fEnableWinStation] を選択し、その値フィールドに「1」と入力します。
コマンド プロンプトで
qwinsta.exeを実行すると表示されるバージョン情報と一致するフォルダーごとに、前の手順を繰り返します。ヒント
複数の VM の fReverseConnectMode または fEnableWinStation モードを一度に変更するには、次の 2 つの操作のいずれかを実行できます。
- 既に動作しているコンピューターからレジストリ キーをエクスポートし、この変更を必要とするその他のすべてのコンピューターにインポートします。
- この変更を必要とするマシンのレジストリ キー値を設定するグループ ポリシー オブジェクト (GPO) を作成します。
セッション ホスト VM を再起動します。
レジストリ エディターを開きます。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings に移動します。
ClusterSettings で SessionDirectoryListener を探し、そのデータ値が
rdp-sxs<version number(<version numberはコマンド プロンプトでqwinsta.exeを実行すると表示されるバージョン情報) であることを確認します。SessionDirectoryListener が
rdp-sxs<version numberに設定されていない場合は、「問題がここに示されていないか、または解決されなかった」セクションの手順に従う必要があります。
エラー:DownloadMsiException
セッション ホスト VM で、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動します。 ID 3277 のイベント (説明に DownloadMsiException と示される) が表示されている場合は、ディスク上に RDAgent 用の十分な領域がありません。
この問題を解決するには、次を実行してディスク上の領域を確保します。
- 使用しなくなったファイルを削除する。
- セッション ホスト VM のストレージ容量を増やす。
エラー: MissingMethodException によりエージェントを更新できない
セッション ホスト VM で、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動します。 ID 3389 のイベント (説明に MissingMethodException: Method not found と示される) が表示されている場合は、Azure Virtual Desktop エージェントが正常に更新されず、以前のバージョンに戻されています。 この問題は、VM に現在インストールされている .NET Framework のバージョン番号が 4.7.2 よりも低いことが原因である発生する可能性があります。 この問題を解決するには、.NET Framework のドキュメントに記載されているインストール手順に従って、.NET をバージョン 4.7.2 以降にアップグレードする必要があります。
エラー: セッション ホスト VM が [アップグレード中] 状態でスタックしている
ホスト プール内のセッション ホストに対して表示されている状態が常に [使用不可] または [アップグレード中] である場合は、エージェントやスタックが正しくインストールされていません。
この問題を解決するには、まずは次のようにサイドバイサイド スタックを再インストールします。
管理者としてセッション ホスト VM にサインインします。
管理者特権の PowerShell プロンプトから
qwinsta.exeを実行し、[セッション名] 列の rdp-sxs の横に表示されるバージョン番号をメモします。 rdp-tcp エントリと rdp-sxs エントリの [状態] 列が [Listen] でない場合、または rdp-tcp エントリと rdp-sxs エントリが一覧にない場合は、スタックに問題があることを意味します。次のコマンドを実行して、RDAgentBootLoader サービスを停止します。
Stop-Service RDAgentBootLoader[コントロール パネル]>[プログラム]>[プログラムと機能] に移動するか、Windows 11 で [設定] アプリ > [アプリ] に移動します。
リモート デスクトップ サービス SxS ネットワーク スタックの最新バージョン、または ReverseConnectionListener の値の下にある HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations のレジストリ エディターに表示されているバージョンをアンインストールします。
PowerShell プロンプトに戻り、次のコマンドを実行して、セッション ホスト VM にあるサイドバイサイド スタックの最新のインストーラーのファイル パスを変数に追加し、その名前を一覧に表示します。
$sxsMsi = (Get-ChildItem "$env:SystemDrive\Program Files\Microsoft RDInfra\" | ? Name -like SxSStack*.msi | Sort-Object CreationTime -Descending | Select-Object -First 1).FullName $sxsMsi次のコマンドを実行して、セッション ホスト VM にあるサイドバイサイド スタックの最新のインストーラーをインストールします。
msiexec /i $sxsMsiセッション ホスト VM を再起動します。
コマンド プロンプトから
qwinsta.exeをもう一度実行し、rdp-tcp エントリと rdp-sxs エントリの [状態] 列が [Listen] であることを確認します。 そうでない場合は、VM を再登録し、エージェント コンポーネントを再インストールする必要があります。
エラー: セッション ホストが [使用不可] 状態でスタックする
セッション ホスト VM が [使用不可] 状態でスタックしている場合、VM が「正常性チェック」に記載されている正常性チェックのいずれかに合格していません。 VM が正常性チェックに合格しなかった原因となっている問題を解決する必要があります。
エラー: セッション ホストが [サポートが必要] 状態でスタックする
セッション ホスト VM が [サポートが必要] 状態でスタックする現象の原因としては、正常性チェック UrlsAccessibleCheck、 MetaDataServiceCheck、MonitoringAgentCheck が考えられます。
UrlsAccessibleCheck
セッション ホストが UrlsAccessibleCheck 正常性チェックに合格しない場合は、デプロイで現在ブロックしている必要な URL を特定する必要があります。 ブロックされている URL がわかったら、その URL をブロックしている設定を特定して削除します。
サービスが必要な URL をブロックしている理由には次の 2 つがあります。
- アクティブなファイアウォールがほとんどの送信トラフィックと必要な URL へのアクセスをブロックしている。
- ローカル ホスト ファイルが、必要な Web サイトをブロックしている。
ファイアウォール関連のイシューを解決するには、ブロックされた URL に関連付けられている TCP ポート 80/443 への送信接続を許可する規則を追加します。
ローカル ホスト ファイルが必要な URL をブロックしている場合は、デバイスの Hosts ファイルに必要な URL が含まれていないことを確認します。 Hosts ファイルの場所は、次のレジストリ キーと値にあります。
キー: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
タイプ: REG_EXPAND_SZ
名前: DataBasePath
MetaDataServiceCheck
セッション ホストが MetaDataServiceCheck 正常性チェックに合格しない場合、サービスは IMDS エンドポイントにアクセスできません。 このイシューを解決するには、次のいずれかのことを行ってください。
- ネットワーク、ファイアウォール、またはプロキシ設定を再構成して、IP アドレス 169.254.169.254 のブロックを解除します。
- IMDS に対してクエリを実行する場合は、HTTP クライアントが VM 内の Web プロキシをバイパスするようにします。 送信ネットワーク トラフィックの方向を処理する VM 内のすべてのファイアウォール ポリシーで、必要な IP アドレスを許可することをお勧めします。
イシューの原因が Web プロキシである場合は、Web プロキシの構成に 169.254.169.254 の例外を追加します。 この例外を追加するには、管理者特権でコマンド プロンプトまたは PowerShell セッションを開き、次のコマンドを実行します。
netsh winhttp set proxy proxy-server="http=<customerwebproxyhere>" bypass-list="169.254.169.254"
MonitoringAgentCheck
セッション ホストが正常性チェック MonitoringAgentCheck に合格しない場合は、以下のようにしてリモート デスクトップ サービス インフラストラクチャ Geneva エージェントをチェックし、セッション ホスト上で正しく機能しているかどうかを検証する必要があります。
リモート デスクトップ サービス インフラストラクチャ Geneva エージェントがセッション ホストにインストールされていることを確認します。 これは、セッション ホストにインストールされているプログラムの一覧で確認できます。 このエージェントの複数のバージョンがインストールされている場合は、古いバージョンをアンインストールし、最新バージョンのみをインストールしたままにしてください。
リモート デスクトップ サービス インフラストラクチャ Geneva エージェントがセッション ホストにインストールされていない場合は、C:\Program Files\Microsoft RDInfra\GenevaInstall.txt にあるログを確認し、インストール失敗の原因が何らかのエラーであるかどうかを確認してください。
スケジュールされたタスク GenevaTask_<version> が作成されているかどうかを確認します。 このスケジュールされたタスクは、有効になっており実行されている必要があります。 この状態になっていない場合は、Microsoft.RDInfra.Geneva.Installer-x64-<version>.msi という名前の
.msiファイル (C:\Program Files\Microsoft RDInfra に格納されています) を使用してエージェントを再インストールしてください。
エラー:接続が見つからない: RDAgent にはブローカーへのアクティブな接続がない
セッション ホスト VM が接続の制限に達している可能性があり、新しい接続を受け入れることができません。
この問題を解決するには、次のいずれかを実行します。
- 最大セッション数を減らします。 この変更により、リソースがセッション ホストにまたがってより均等に分散されるようになるため、リソースの枯渇が防止されます。
- セッション ホスト VM のリソース容量を増やします。
エラー:Pro VM またはその他のサポートされていない OS を操作している
サイドバイサイド スタックは、Windows Enterprise または Windows Server SKU でのみサポートされています。つまり、Pro VM などのオペレーティング システムはサポートされません。 Enterprise や Server SKU がない場合、スタックは VM にインストールされますが、アクティブ化されないため、コマンド ラインで qwinsta を実行したときに表示されません。
この問題を解決するには、サポートされているオペレーティング システムを使用してセッション ホスト VM を作成します。
エラー:NAME_ALREADY_REGISTERED
セッション ホスト VM の名前が既に登録されており、重複している可能性があります。
この問題を解決するには、次の手順を実行します。
「ホスト プールからセッション ホストを削除する」セクションの手順に従います。
別の VM を作成します。 この VM には一意の名前を選択するようにしてください。
Azure portal に移動し、VM が存在していたホスト プールの [概要] ページを開きます。
[セッション ホスト] タブを開き、すべてのセッション ホストがそのホスト プール内にあることを確認します。
セッション ホストの状態が [使用可能] と表示されるまで 5 ～ 10 分待ちます。
問題がここに示されていないか、または解決されなかった
問題がこの記事に見つからないか、またはその手順が役に立たなかった場合は、Azure Virtual Desktop エージェントをアンインストールし、再インストールして、再登録することをお勧めします。 このセクションの手順では、次の方法でセッション ホスト VM を Azure Virtual Desktop サービスに再登録する方法について説明します。
すべてのエージェント、ブート ローダー、スタック コンポーネントをアンインストールする
ホスト プールからセッション ホストを削除する。
VM の新しい登録キーを生成する。
Azure Virtual Desktop エージェントとブート ローダーを再インストールする。
次のシナリオが 1 つ以上当てはまる場合は、このセクションの手順に従ってください。
- セッション ホスト VM の状態が [アップグレード中] または [使用不可] でスタックしている。
- スタック リスナーが動作しておらず、Windows 10 バージョン 1809、1903、または 1909 上で実行している。
- EXPIRED_REGISTRATION_TOKEN エラーが表示されている。
- セッション ホスト VM がセッション ホストの一覧に表示されていない。
- [サービス] コンソールにリモート デスクトップ エージェント ローダー サービスが表示されていない。
- タスク マネージャーで実行中のプロセスとして RdAgentBootLoader コンポーネントが表示されていない。
- カスタム イメージ VM で設定を接続ブローカーで検証できませんでしたというエラーを受け取っている。
- この記事の前のセクションで問題が解決されなかった。
手順 1:すべてのエージェント、ブート ローダー、スタック コンポーネント プログラムをアンインストールする
エージェント、ブート ローダー、スタックを再インストールする前に、VM から既存のコンポーネントをすべてアンインストールする必要があります。 すべてのエージェント、ブート ローダー、スタック コンポーネント プログラムをアンインストールするには、次の手順を実行します。
管理者としてセッション ホスト VM にサインインします。
[コントロール パネル]>[プログラム]>[プログラムと機能] に移動するか、Windows 11 で [設定] アプリ > [アプリ] に移動します。
次のプログラムをアンインストールしてから、セッション ホスト VM を再起動します。
注意事項
リモート デスクトップ サービス SxS ネットワーク スタックをアンインストールするときに、"リモート デスクトップ サービス" と Remote Desktop Services UserMode Port Redirector を閉じるよう求められます。 RDP を使用してセッション ホスト VM に接続している場合は、[アプリケーションを閉じない] を選択してから、[OK] を選択します。そうしないと、RDP 接続が動作しなくなります。
- リモート デスクトップ エージェント ブート ローダー
- リモート デスクトップ サービス インフラストラクチャ エージェント
- リモート デスクトップ サービス インフラストラクチャ Geneva エージェント
- リモート デスクトップ サービス SxS ネットワーク スタック
注意
これらのプログラムの複数のインスタンスが表示されることがあります。 それらをすべて削除するようにしてください。
手順 2:ホスト プールからセッション ホストを削除する
ホスト プールからセッション ホストを削除すると、このセッション ホストはそのホスト プールに登録されていない状態になります。 この変更は、セッション ホストの登録のリセットとして機能します。 ホスト プールからセッション ホストを削除するには、次の手順を実行します。
Azure portal にサインインします。
検索バーに「Azure Virtual Desktop」と入力し、一致するサービス エントリを選択します。
[ホスト プール] を選択し、セッション ホスト VM が存在するホスト プールの名前を選択します。
[セッション ホスト] を選択し、そのホスト プール内のすべてのセッション ホストの一覧を表示します。
セッション ホストの一覧を確認し、削除するセッション ホストの横にあるチェック ボックスをオンにします。
[削除] を選択します。
手順 3: VM の新しい登録キーを生成する
セッション VM をホスト プールとサービスに再登録するために使用される新しい登録キーを生成する必要があります。 VM の新しい登録キーを生成するには、次の手順を実行します。
Azure portal にサインインします。
検索バーに「Azure Virtual Desktop」と入力し、一致するサービス エントリを選択します。
[ホスト プール] を選択し、セッション ホスト VM が存在するホスト プールの名前を選択します。
[概要] ブレードで、[登録キー] を選択します。
[登録キー] タブを開き、 [新しいキーの生成] を選択します。
有効期限を入力し、 [OK] を選択します。
注意
有効期限は、その生成日時から 1 時間以上で、かつ 27 日以内にする必要があります。 必要な期間分の登録キーを生成します。
- 新しく生成されたキーをクリップボードにコピーするか、ファイルをダウンロードします。 このキーは、後で必要になります。
手順 4:エージェントとブート ローダーを再インストールする
エージェントとブート ローダーの最新バージョンを再インストールすると、サイドバイサイド スタックと Geneva 監視エージェントも自動的にインストールされます。 エージェントとブート ローダーを再インストールするには、次の手順に従います。 これは、 非検証環境での Azure Virtual Desktop エージェントのダウンロード可能な最新バージョンです。 エージェントの新しいバージョンのロールアウトの詳細については、「Azure Virtual Desktop エージェントの新機能」を参照してください。
セッション ホスト VM に管理者としてサインインし、セッション ホスト VM のエージェント インストーラーとブートローダーを実行します。
ヒント
ダウンロードしたエージェントとブート ローダーのインストーラーごとに、ブロックの解除が必要になる場合があります。 各ファイルを右クリックし、[プロパティ] を選択してから [ブロックの解除] を選択し、最後に [OK] を選択します。
インストーラーから登録トークンの入力を求められたら、クリップボードから登録キーを貼り付けます。
ブート ローダー インストーラーを実行します。
セッション VM を再起動します。
Azure portal にサインインします。
検索バーに「Azure Virtual Desktop」と入力し、一致するサービス エントリを選択します。
[ホスト プール] を選択し、セッション ホスト VM が存在するホスト プールの名前を選択します。
[セッション ホスト] を選択し、そのホスト プール内のすべてのセッション ホストの一覧を表示します。
これで、ホスト プールに登録されているセッション ホストが [使用可能] の状態で表示されます。
DisableRegistryTools レジストリ キーを削除する
4 つすべての手順を実行してもエージェントが機能しない場合、DisableRegistryTools レジストリ キーが次のいずれかの場所で有効になっていることが原因と考えられます。
- HKU:\DEFAULT\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools = 1
- HKU:\S-1-5-18\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools = 1
- HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools = 1
このレジストリ キーがあることでエージェントがサイドバイサイド スタックをインストールできないため、installMSIException エラーが発生します。 このエラーにより、セッション ホストが使用できない状態でスタックします。
この問題を解決するには、このキーを削除する必要があります。
前述の 3 つの場所から DisableRegistryTools キーを削除します。
[アプリと機能] フォルダーから、影響を受けている、サイドバイサイド スタックのインストールをアンインストールし、削除します。
影響を受けているサイドバイサイド スタックのレジストリ キーを削除します。
VM を再起動する。
エージェントを起動し、それによってサイドバイサイド スタックが自動インストールされるようにします。
次の手順
引き続き問題が発生する場合は、サポート ケースを作成し、発生している問題とそれを解決しようとして実行したすべてのアクションに関する詳細情報を含めます。 次の一覧には、Azure Virtual Desktop のデプロイでの問題をトラブルシューティングするために使用できるその他のリソースが含まれています。
- Azure Virtual Desktop トラブルシューティングの概要とエスカレーション トラックについては、「トラブルシューティングの概要、フィードバック、サポート」を参照してください。
- Azure Virtual Desktop 環境でホスト プールを作成しているときに発生した問題のトラブルシューティングを行うには、環境とホスト プールの作成に関するページを参照してください。
- Azure Virtual Desktop で仮想マシン (VM) の構成中に発生した問題を解決するには、セッション ホスト仮想マシンの構成 に関する記事を参照してください。
- Azure Virtual Desktop クライアント接続の問題をトラブルシューティングするには、Azure Virtual Desktop サービスの接続に関するページを参照してください。
- Azure Virtual Desktop で PowerShell を使用しているときに発生した問題を解決するには、「Azure Virtual Desktop PowerShell」を参照してください。
- サービスの詳細については、Azure Virtual Desktop 環境に関するページを参照してください。
- トラブルシューティング チュートリアルについては、「Tutorial:Resource Manager テンプレート デプロイのトラブルシューティング」を参照してください。
- 監査アクションについては、「 リソース マネージャーの監査操作」をご覧ください。
- デプロイ時にエラーが発生した場合の対応については、 デプロイ操作の確認に関するページを参照してください。