Azure Virtual Desktop エージェントに関する一般的な問題をトラブルシューティングする
Azure Virtual Desktop エージェントでは、次の複数の要因のために接続に関する問題が発生することがあります。
- エージェントのサービスを停止させるブローカーでのエラー。
- 更新に関する問題。
- エージェントのインストール中のインストールに関する問題。セッション ホストへの接続が中断されます。
この記事では、これらの一般的なシナリオの解決策と、接続に関する問題に対処する方法について説明します。
注意
セッションの接続性と Azure Virtual Desktop エージェントに関連する問題のトラブルシューティングについては、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動して、セッション ホスト仮想マシン (VM) のイベント ログを確認することをお勧めします。 問題を特定するために、次のいずれかのソースがあるイベントを探してください。
- WVD-Agent
- WVD-Agent-Updater
- RDAgentBootLoader
- MsiInstaller
エラー:RDAgentBootLoader またはリモート デスクトップ エージェント ローダー、あるいはその両方が動作を停止した
次のいずれかの問題が発生した場合は、エージェントを読み込むブート ローダーがエージェントを正しくインストールできず、エージェント サービスがセッション ホスト VM で実行されていないことを意味します。
- RDAgentBootLoader が停止したか、または動作していない。
- リモート デスクトップ エージェント ローダーの状態がない。
この問題を解決するには、RDAgent ブート ローダーを起動します。
- Services ウィンドウで、[デスクトップ エージェント ローダーのを右クリック。
- [スタート] を選択します。 このオプションが淡色表示の場合、管理者権限はありません。 サービスを開始するには、これらのアクセス許可を取得する必要があります。
- 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 が説明に表示された場合、エージェントはゲートウェイ URL に到達できません。 セッション ホストに正常に接続するには、「必要な URL リスト」にある URL へのネットワーク トラフィックを許可する必要があります。 また、ファイアウォールまたはプロキシの設定によってこれらの URL がブロックされていないことも確認してください。 これらの URL のブロックの解除は、Azure Virtual Desktop を使用するために必要です。
この問題を解決するには、必要な URL チェック ツールを実行して、必要な URL へアクセスできるかどうかを確認します。 Azure Firewall を使用している場合は、「Azure Firewall を使用して Azure Virtual Desktop のデプロイを保護する使用するAzure Firewall の DNS 設定 Azure Virtual Desktop 用に構成する方法の詳細を参照してください。
エラー: 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 を実行してポリシーのセットを開きます。
ポップアップ表示される ポリシーのセット ウィンドウで、 Computer Configuration>Administrative Templates>Windows Components>Windows Installer>Turn off Windows Installer に移動します。 状態が Enabled の場合は、Active Directory チームと協力して、 msiexec.exe の実行を許可します。
Note
この一覧はポリシーの包括的な一覧ではなく、現在認識されているものだけです。
エラー:Win32Exception
セッション ホスト VM で、[イベント ビューアー]>[Windows ログ]>[アプリケーション] に移動します。 ID 3277 のイベントと InstallMsiException が説明に表示された場合、ポリシーによって cmd.exe の起動がブロックされます。 このプログラムをブロックすると、エージェントが更新されるたびにサービスを再開するために使用する必要のあるコンソール ウィンドウが実行されなくなります。
- 管理者特権のコマンド プロンプトから rsop.msc を実行してポリシーのセットを開きます。
- ポップアップ表示される Resultant ポリシー セット ウィンドウで、コマンド プロンプトへの User Configuration>Administrative Templates>System>Prevent アクセスに移動。 状態が Enabled の場合は、Active Directory チームと協力して、 cmd.exe の実行を許可します。
エラー:スタック リスナーが Windows 10 2004 セッション ホスト VM で動作していない
セッション ホスト VM で、コマンド プロンプトからqwinsta.exe実行し、SESSIONNAME列のrdp-sxsの横に表示されるバージョン番号をメモします。 rdp-tcpエントリとrdp-sxs エントリのSTATE列が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 フレームワークのバージョン番号が 4.7.2 より小さいために発生する可能性があります。 この問題を解決するには、.NET Framework のドキュメントに記載されているインストール手順に従って、.NET をバージョン 4.7.2 以降にアップグレードする必要があります。
エラー: セッション ホスト VM がアップグレード中の状態でスタックしている
ホスト プール内のセッション ホストに対して表示されている状態が常に [使用不可] または [アップグレード中] である場合は、エージェントやスタックが正しくインストールされていません。
この問題を解決するには、まずは次のようにサイドバイサイド スタックを再インストールします。
管理者としてセッション ホスト VM にサインインします。
管理者特権の PowerShell プロンプトから、
qwinsta.exeを実行し、SESSIONNAME列のrdp-sxsの横に表示されるバージョン番号をメモします。rdp-tcpエントリとrdp-sxsエントリのSTATE列がListenされていない場合、またはrdp-tcpエントリとrdp-sxsエントリが一覧にない場合は、スタックの問題があることを意味します。次のコマンドを実行して、 RDAgentBootLoader サービスを停止します。
Stop-Service RDAgentBootLoaderコントロール パネル>プログラム>プログラムと機能に移動するか、Windows 11 で Settings App>Apps に移動します。
Remote Desktop Services SxS ネットワーク スタックの最新バージョンまたは
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStationsのレジストリ エディターのReverseConnectionListenerの値に記載されているバージョンをアンインストールします。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エントリのSTATE列がListenされていることを確認します。 そうでない場合は、VM を再登録し、エージェント コンポーネントを再インストールする必要があります。
エラー: セッション ホストが使用不可状態でスタックしている
セッション ホスト VM が [使用不可] 状態でスタックしている場合、VM が「正常性チェック」に記載されている正常性チェックのいずれかに合格していません。 VM が正常性チェックに失敗する原因となっている問題を解決する必要があります。
エラー: セッション ホストが [サポートが必要] 状態でスタックする
いくつかの正常性チェックにより、セッション ホスト VM が Needs Assistance 状態でスタックする可能性があります: 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 エージェントがセッション ホストにインストールされていることを確認します。 これは、セッション ホストにインストールされているプログラムの一覧で確認できます。 このエージェントの複数のバージョンがインストールされている場合は、古いバージョンをアンインストールし、最新バージョンのみをインストールしたままにします。
- セッション ホストにインストールされているリモート デスクトップ サービス インフラストラクチャ ジュネーブ エージェントが見つからない場合は、 C:\Program Files\Microsoft RDInfra\GenevaInstall.txt にあるログを確認し、エラーが原因でインストールが失敗しているかどうかを確認します。
- スケジュールされたタスク GenevaTask_<バージョン> が作成されているかどうかを確認します。 このスケジュールされたタスクは、有効になっており実行されている必要があります。 インストールされていない場合は、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 SKU または Server SKU がない場合、スタックは VM にインストールされますがアクティブ化されないため、コマンド ラインで qwinsta.exe を実行しても表示されません。
この問題を解決するには、サポートされているオペレーティング システムを使用してセッション ホスト VM を作成します。
エラー:NAME_ALREADY_REGISTERED
セッション ホスト VM の名前が既に登録されており、重複している可能性があります。
この問題を解決するには、次の手順を実行します。
次の手順に従って ホスト プールからセッション ホストを削除します。
別の VM を作成します。 この VM には一意の名前を選択するようにしてください。
Azure portal に移動し、VM が存在していたホスト プールの [概要] ページを開きます。
[セッション ホスト] タブを開き、すべてのセッション ホストがそのホスト プール内にあることを確認します。
セッション ホストの状態が Available になるまで 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 で Settings App>Apps に移動します。
次のプログラムをアンインストールし、セッション ホスト VM を再起動します。
注意事項
Remote Desktop Services SxS ネットワーク スタックをアンインストールする場合は、リモート デスクトップ サービスと Remote Desktop Services UserMode ポート リダイレクターを閉じる必要があることを確認するメッセージが表示されます。 RDP を使用してセッション ホスト VM に接続している場合は、[ アプリケーションを閉じません] を選択し、[ OKを選択します。 そうしないと、RDP 接続は機能しません。
- リモート デスクトップ エージェント ブート ローダー
- リモート デスクトップ サービス インフラストラクチャ エージェント
- リモート デスクトップ サービス インフラストラクチャ Geneva エージェント
- リモート デスクトップ サービス SxS ネットワーク スタック
Note
これらのプログラムの複数のインスタンスが表示される場合があります。 それらをすべて削除するようにしてください。
手順 2:ホスト プールからセッション ホストを削除する
ホスト プールからセッション ホストを削除すると、このセッション ホストはそのホスト プールに登録されていない状態になります。 この変更は、セッション ホストの登録のリセットとして機能します。 ホスト プールからセッション ホストを削除するには、次の手順を実行します。
Azure portal にサインインします。
検索バーに「Azure Virtual Desktop」と入力し、一致するサービス エントリを選択します。
[ホスト プール] を選択し、セッション ホスト VM が存在するホスト プールの名前を選択します。
[セッション ホスト] を選択し、そのホスト プール内のすべてのセッション ホストの一覧を表示します。
セッション ホストの一覧を確認し、削除するセッション ホストの横にあるチェック ボックスをオンにします。
[削除] を選択します。
手順 3: VM の新しい登録キーを生成する
セッション VM をホスト プールとサービスに再登録するために使用する新しい登録キーを生成する必要があります。 VM の新しい登録キーを生成するには、次の手順を実行します。
Azure portal にサインインします。
検索バーに「Azure Virtual Desktop」と入力し、一致するサービス エントリを選択します。
[ホスト プール] を選択し、セッション ホスト VM が存在するホスト プールの名前を選択します。
[概要] ブレードで、[登録キー] を選択します。
[登録キー] タブを開き、 [新しいキーの生成] を選択します。
有効期限を入力し、 Ok を選択します。
Note
有効期限は、その生成日時から 1 時間以上で、かつ 27 日以内にする必要があります。 必要な期間分の登録キーを生成します。
新しく生成されたキーをクリップボードにコピーするか、ファイルをダウンロードします。 このキーは後で必要になります。
手順 4:エージェントとブート ローダーを再インストールする
エージェントとブート ローダーの最新バージョンを再インストールすると、サイドバイサイド スタックと Geneva 監視エージェントも自動的にインストールされます。 エージェントとブート ローダーを再インストールするには、次の手順に従います。 これは、 非検証環境での Azure Virtual Desktop エージェントのダウンロード可能な最新バージョンです。 エージェントの新しいバージョンのロールアウトの詳細については、「Azure Virtual Desktop エージェントの新機能」を参照してください。
セッション ホスト VM に管理者としてサインインし、セッション ホスト VM のエージェント インストーラーとブートローダーを実行します。
ヒント
ダウンロードしたエージェントとブート ローダーのインストーラーごとに、ブロックの解除が必要になる場合があります。 各ファイルを右クリックし、 Properties>Unblock>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 を構成する際の問題のトラブルシューティングについては、「 Session ホスト仮想マシンの構成を参照してください。
- Azure Virtual Desktop クライアント接続の問題をトラブルシューティングするには、Azure Virtual Desktop サービスの接続に関するページを参照してください。
- Azure Virtual Desktop で PowerShell を使用しているときに発生した問題を解決するには、「Azure Virtual Desktop PowerShell」を参照してください。
- サービスの詳細については、Azure Virtual Desktop 環境に関するページを参照してください。
- トラブルシューティング チュートリアルについては、「Tutorial:Resource Manager テンプレート デプロイのトラブルシューティング」を参照してください。
- 監査アクションについては、「 リソース マネージャーの監査操作」をご覧ください。
- デプロイ時にエラーが発生した場合の対応については、 デプロイ操作の確認に関するページを参照してください。