新規にホスト プールを作ったのに、セッションホストが「Unavailable」のままでユーザーが入れない――Azure Virtual Desktop（AVD）で最も多い初期トラブルのひとつです。本記事は、再現性の高い原因から優先順に切り分ける実務手順を、ログの見方・コマンド例・運用ノウハウとともに体系化しました。読み進めながら上から順に確認すれば、その場で復旧までたどり着けます。
結論（まずはここから）：最短で直すための手順
「Unavailable」の大半は エージェント登録・ネットワーク疎通・ドメイン参加 のどれかで詰まっています。迷ったら、以下の順で実行してください。
- セッションホストの OS にログオン（Azure Bastion／一時的な 3389 開放／コンソール等）
- イベント ビューアーで WVD‑Agent / RDAgentBootLoader / MsiInstaller を確認し、
INVALID_REGISTRATION_TOKEN・サービス起動失敗・インストール失敗を探す - エージェント／ブートローダーを最新版へ入れ直し（登録トークンはホスト プールの Registration Key を使用）
- アウトバウンド疎通（TCP 443 と UDP 3391）が NSG／ファイアウォール／プロキシで許可されているか検証（TLS インスペクションは回避）
- ドメイン参加状態を修復（Azure AD Join または AD DS へ手動参加 → 再起動）
- AVD Insights を有効化し、接続／認証／セッション管理の失敗イベントを時系列で可視化
この順路で多くの環境が復旧します。以下で詳細を解説します。
症状の定義と背景
AVD のセッションホスト状態は Broker 側が受け取る エージェントのハートビート といくつかのヘルス シグナルから決まります。VM 自体が稼働中でも、エージェント未登録・ネットワーク遮断・ドメイン不整合などで Broker に到達できない場合、ポータルや API では 「Unavailable」 と表示され、ユーザーは接続不可になります。
- Available：ハートビート良好。接続受付可
- Unavailable：Broker から到達不能／エージェント異常／前提条件未満
- Needs assistance：更新や構成の手当が必要（エージェント更新・再起動など）
- Shutdown：VM 停止中／割り当て解除
原因と解決策（一覧）
| 主なチェック項目 | 内容・対処 |
|---|---|
| ① AVD エージェントの登録失敗 | セッションホストの イベント ビューアー → WVD‑Agent / RDAgentBootLoader / MsiInstaller を確認し、INVALID_REGISTRATION_TOKEN やサービス起動失敗を調査。エージェントやブートローダーが入っていない／停止している場合は最新版を再インストールし、サービスを再起動。 |
| ② ネットワーク／ポート疎通 | セッションホストから TCP 443（必須）と UDP 3391（推奨）がインターネットおよび AVD サービスへ到達できるか、NSG／ファイアウォール／プロキシで確認・許可。TLS インスペクション（SSL 復号）がある場合は AVD 向け通信をバイパス。 |
| ③ ドメイン参加状態 | VM が Azure AD またはオンプレ AD に参加できていないケースあり。手動でドメイン参加 → 再起動 により「Unavailable」が解消された実例多数（本件もこれで解決）。 |
| ④ サブスクリプション／クォータ | Azure Service Health でリージョン障害を確認。合わせて CPU・NIC などのクォータ不足がないか点検。 |
| ⑤ Insights で追加診断 | ポータルの Azure Virtual Desktop Insights を有効化し、接続／認証／セッション管理の失敗イベントを可視化して原因を絞り込み。 |
上表を順に確認すれば、ほとんどの「Session host is unavailable」問題は解消できます。
現場で使えるチェックリスト（詳細版）
| カテゴリ | 主なサイン | 確認コマンド／ログ | 対処 |
|---|---|---|---|
| エージェント登録 | Broker に登録されない／状態が Unavailable のまま | イベント ビューアー：WVD‑Agent / RDAgentBootLoader / MsiInstaller サービス状態確認：Get-Service *RDAgent* | 登録トークンの有効期限を再発行 ブートローダー → エージェントの順で再インストール 再起動後に状態更新を待機 |
| ネットワーク | TLS ハンドシェイク失敗／タイムアウト／UDP 不可 | Test-NetConnection -ComputerName <AVD ゲートウェイ FQDN> -Port 443 Test-NetConnection -ComputerName <AVD ゲートウェイ FQDN> -Port 3391 NSG：Service Tag AzureVirtualDesktop を許可 | アウトバウンド 443／UDP 3391 を開放 SSL/TLS インスペクションをバイパス プロキシ設定の例外に AVD ドメインを追加 |
| ドメイン参加 | Azure AD Join / Hybrid Join / AD DS 参加が未完了 | dsregcmd /status（Azure AD 加入） システムのプロパティ → ドメイン参加 | 手動で参加 → 再起動 Azure AD Join では RBAC「Virtual Machine Administrator/User Login」を VM に割り当て |
| 時間・証明書 | 時刻ずれ／TLS 1.2 無効で失敗 | w32tm /query /status レジストリで TLS 1.2 有効化を確認 | NTP 同期の正常化（Azure ホスト時刻と整合） TLS 1.2 を有効化 |
| 拡張機能 | VM 拡張のデプロイが失敗／保留 | ポータルの「拡張機能」で状態を確認 | 失敗している拡張を削除→再デプロイ |
実例：ドメイン未参加が原因で「Unavailable」になったケース
新規ホスト プールを作成後、セッションホストがずっと「Unavailable」。エージェントのインストールログは正常、ネットワークの 443/3391 も疎通。dsregcmd /status を確認すると「AzureADJoined : NO」。管理者が RDP で VM に入り、Azure AD へ参加 → 再起動 を実施したところ、数分後に「Available」へ遷移。以後はユーザー接続が安定しました。
- 学び：Join の未完了はログの表現が散漫で見落としやすい。まず
dsregcmd /statusを見る。 - 再発防止：イメージ作成手順書に「Join 確認」「VM への RBAC 付与」を追加。
ディープダイブ：原因別の直し方
AVD エージェント／ブートローダーの入れ直し
登録トークンの期限切れや、イメージ化時点の古い版が原因で起動直後に失敗することがあります。以下の順での再インストールが安定します。
- ホスト プールの Registration Key を新規発行（有効期限に注意）
- セッションホストで旧版をアンインストール（必要に応じて）
- BootLoader → Agent の順にインストール（BootLoader に Registration Key を指定）
- サービスを再起動し、イベント ビューアーで登録完了を確認
静的インストール例（ログ採取付き）：
rem 管理者 PowerShell / CMD
msiexec /i "Microsoft.RDInfra.RDAgentBootLoader.msi" REGISTRATIONTOKEN=<発行したキー> /quiet /norestart /l*v C:\Windows\Temp\AVD_BootLoader.log
msiexec /i "Microsoft.RDInfra.RDAgent.msi" /quiet /norestart /l*v C:\Windows\Temp\AVD_Agent.log
sc query type= service state= all | findstr /i "rdinfra rdagent"
Get-Service *RDAgent* | Select-Object Name,Status | Format-Table よくある誤り：
- 期限切れトークンでイメージ化→展開直後に
INVALID_REGISTRATION_TOKEN - BootLoader 未設定で Agent のみ導入→登録処理が走らない
ネットワーク疎通（NSG／FW／プロキシ）
AVD はセッションホストから Broker／Gateway へ アウトバウンド 443 を必須とし、UDP 3391 を利用すると体感が大幅に向上します（利用不可でも「Unavailable」自体は直る場合あり）。企業プロキシや次世代ファイアウォールの TLS インスペクションが、Agent の認証を壊している例も多発します。
- NSG は Service Tag AzureVirtualDesktop を許可すると運用が楽
- プロキシ配下では バイパス の検討（PAC／静的例外）
- SSL インスペクションは AVD ドメインを除外
検証コマンド：
# TCP 443
Test-NetConnection -ComputerName <ゲートウェイの FQDN> -Port 443 -InformationLevel Detailed
# UDP 3391（到達性の有無をまず確認）
Test-NetConnection -ComputerName <ゲートウェイの FQDN> -Port 3391 ドメイン参加と VM ログオン権限
Azure AD Join／Hybrid Join／AD DS いずれでも、Join が完了し適切なログオン権限が付いていないと、Broker 側の接続準備が崩れます。
- Azure AD Join：VM に Virtual Machine Administrator Login / Virtual Machine User Login を割り当て
- Hybrid Join：ラインオブサイト（DNS／DC／時間同期）
- AD DS：ドメイン参加 → 再起動 → 再試行
状態確認：
dsregcmd /status
whoami /groups
nltest /dsgetdc:<ドメイン名>
w32tm /query /status
時間同期・TLS
5 分以上の時刻ずれはトークン検証・TLS ハンドシェイクを落とします。ホストのタイムゾーン設定と NTP を標準化しましょう。TLS 1.2 を無効化している古いポリシーも要注意です。
Azure Monitor（AVD Insights）での可視化
ホスト プール単位で AVD Insights を有効にし、Log Analytics ワークスペースへデータ送信することで、障害の全体像が掴めます。特に「接続」「認証」「セッション管理」の 3 系列の失敗イベントを並べると、どの層で止まっているか が一目瞭然です。
KQL の例：
// セッションホストのヘルス
WVDCheckpoints
| where TimeGenerated > ago(24h)
| summarize arg_max(TimeGenerated, *) by SessionHostName
| project TimeGenerated, SessionHostName, State, Message
// 直近の接続失敗
WVDConnections
| where TimeGenerated > ago(24h)
| where Result != "Succeeded"
| project TimeGenerated, UserName, SessionHostName, Result, FailureReason サブスクリプションのクォータとリージョン障害
「利用者は少ないのに VM を増やすと一部だけ Unavailable」— こうした時は、裏でクォータ不足や基盤側のアラートが潜んでいます。コンピュート／NIC／パブリック IP のクォータを確認し、足りない場合は増枠申請を。並行してサービスヘルスをチェックし、リージョン側のイベントが無いか把握しておきましょう。
イメージ運用と「Unavailable」を生まない作り方
カスタム イメージを使う場合の注意
- Sysprep の前提：最新の AVD エージェント／ブートローダーを含めつつ、登録トークンはイメージに埋め込まない 運用が安全です。展開時に新しい Registration Key を用いて登録を実施。
- 更新自動化：Azure Image Builder／Azure Compute Gallery を活用し、パッチ適用とエージェント更新をパイプライン化。
- 初回ブート時のレースコンディション対策：ブートローダーの登録前にプロキシ／証明書／時刻同期の GPO を適用できるよう、起動順を整備。
ゴールデン イメージの健全性チェック
# 主要サービスの存在と自動起動を確認
Get-Service | Where-Object {$_.DisplayName -like "*Remote Desktop*"} | Select-Object DisplayName, Status, StartType
# イメージ内のプロキシ設定確認（WinHTTP）
netsh winhttp show proxy 運用者向け：PowerShell で一気に可視化・復旧
管理面からも状況を掴みます。以下は Az.DesktopVirtualization を用いた例です。
# モジュール導入（管理端末）
Install-Module Az.DesktopVirtualization -Scope CurrentUser -Force
Connect-AzAccount
# セッションホストの一覧と状態
Get-AzWvdSessionHost -ResourceGroupName -HostPoolName |
Select-Object Name, Status, AllowNewSession, SxSStackVersion | Format-Table
# 必要ならユーザー視点接続の簡易テスト
Test-AzWvdUserConnection -ResourceGroupName -HostPoolName -UserPrincipalName
# メンテ時に新規セッション拒否（Drain）
Update-AzWvdSessionHost -ResourceGroupName -HostPoolName -Name -AllowNewSession:$false PowerShell で状態を横断的に眺めると、1 台だけ「Unavailable」な異常個体や、特定バージョンのエージェントで不具合が出ている傾向を素早く拾えます。
プロキシ・セキュリティ製品の落とし穴
- TLS インスペクション：AVD の制御通信は証明書ピン留め等の検証が厳格。復号・再暗号化により失敗することがあるため、AVD 向けはバイパス。
- プロキシ認証：サービス起動直後のシステムアカウントでの通信は、認証プロキシを通過できない場合あり。機械アカウントのバイパス または 静的例外 を設ける。
- SSL/TLS バージョン固定：古いポリシーで TLS 1.2 を落としていると、初回登録が失敗。
トラブル再発防止の運用設計
監視の最小構成
- AVD Insights を有効化（ワークスペースは業務基盤のものへ集約）
- SessionHost の Status が Unavailable に変化したら通知（アラート ルール）
- Agent/BootLoader のイベント ID で重大度エラーをサブスクライブ
変更管理
- ネットワーク系変更（プロキシ／FW／NSG）には AVD 回帰テスト を必ず紐付ける
- イメージ更新時は「登録トークンが埋め込まれていないか」を CI で検査
ランブック（現場用）
- ポータルで「Unavailable」台数と共通点を把握（OS／ゾーン／スケールセット）
- 1 台に管理ログオン → イベント／サービス／疎通を 10 分で確認
- エージェント再インストール → 再起動
- Join 修復（必要なら）→ 再起動
- 復旧後に AVD Insights で前後の失敗率を確認し、原因を事後記録
よくある質問（FAQ）
Q. UDP 3391 が閉じていても「Unavailable」になりますか？
A. 多くの環境では 443 が生きていれば 状態自体 は Available に上がります。ただし体感品質（ラグ・音声・画面応答）は悪化するため、原則として 3391 も開けておくのが運用のベストプラクティスです。
Q. エージェントはどの順番で入れますか？
A. 一般に BootLoader → Agent の順が推奨です。BootLoader に Registration Key を与えて登録し、その後 Agent が制御を担います。
Q. カスタム イメージで毎回 Unavailable になります。
A. トークンの埋め込みや古いエージェントが原因のことが多いです。イメージには最新のコンポーネントを保持しつつ、登録は展開時 に行う設計へ改めましょう。
Q. Azure AD Join なのに、管理者がログオンできません。
A. VM に対する RBAC「Virtual Machine Administrator Login / User Login」が不足している可能性があります。割り当て後に反映まで数分かかる点にも留意してください。
切り分けを加速するスニペット集
イベント ログの一括収集
# 管理者 PowerShell
$logs = @(
"Application",
"System"
)
$channels = @(
"Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational",
"Microsoft-Windows-TerminalServices-LocalSessionManager/Operational"
)
$dest = "C:\Windows\Temp\AVD_Logs_$(Get-Date -Format yyyyMMddHHmm).evtx"
wevtutil epl Application $dest
wevtutil epl System $dest
foreach ($c in $channels) { wevtutil epl $c ($dest + ".$((($c -replace '[\/]', '_'))).evtx") }
Get-Service *RDAgent* | Format-Table -Auto ネットワーク健全性の即席チェック
# 代表 FQDN への 443/3391 疎通確認（名称は自環境に合わせて）
$targets = @("rdweb.wvd.microsoft.com","rdbroker.wvd.microsoft.com")
$ports = @(443,3391)
foreach ($t in $targets) {
foreach ($p in $ports) {
$r = Test-NetConnection -ComputerName $t -Port $p
"{0}:{1} - {2}" -f $t,$p, ($r.TcpTestSucceeded ? "OK" : "NG") | Write-Host
}
}
セッションホストの一斉 Drain/解除
# メンテナンス開始前に新規セッションを止める
Get-AzWvdSessionHost -ResourceGroupName <RG> -HostPoolName <Pool> |
% { Update-AzWvdSessionHost -ResourceGroupName <RG> -HostPoolName <Pool> -Name $_.Name -AllowNewSession:$false }
追加のヒント・注意点（要点まとめ）
- カスタム イメージ利用時：Sysprep 前に AVD エージェントと BootLoader を最新化。登録トークンは展開時に付与する。
- Azure AD Join 構成：VM に「Virtual Machine Administrator Login」「Virtual Machine User Login」ロールを割り当て。
- 接続テスト：
Test-AzWvdUserConnectionでユーザー視点の接続可否を素早く検証。 - SSL インスペクション回避：制御プレーン通信の復号は失敗要因。除外ルールを作成。
- 時間同期：5 分以上のずれは TLS／トークン検証を壊す。NTP を整える。
まとめ：上から順に潰せば必ず直る
「Unavailable」は、エージェント登録・ネットワーク疎通・ドメイン参加の 3 点に絞って潰すのが最短です。まずログで登録の成否を確かめ、443/3391 のアウトバウンドを検証し、Join を是正。必要に応じて AVD Insights で失敗の位置を可視化しましょう。この記事のチェックリストとコマンドを手元に、現場の初動スピードを一段引き上げてください。
付録：コピーして使える実務テンプレート
現場チェックシート（印刷用）
| 項目 | Yes/No | メモ |
|---|---|---|
| Registration Key は有効期限内か | □ / □ | |
| BootLoader → Agent の順でインストール済みか | □ / □ | |
| TCP 443 のアウトバウンドは通るか | □ / □ | |
| UDP 3391 のアウトバウンドは通るか | □ / □ | |
| Azure AD / AD DS への参加は完了しているか | □ / □ | |
| VM への RBAC（VM Admin/User Login）は付与済みか | □ / □ | |
| 時間同期／TLS 1.2 は有効か | □ / □ | |
| AVD Insights は有効化されているか | □ / □ |
現場エスカレーションの書式
[現象]
新規ホスト プール作成後、セッションホストが Unavailable
[試行済み]
* イベント ログ確認（WVD‑Agent / RDAgentBootLoader）
* Registration Key 再発行 → 再登録
* TCP 443 / UDP 3391 の疎通確認
* dsregcmd /status で Join 確認
* 再起動（症状変わらず）
[補足]
* プロキシ／FW の変更はなし
* AVD Insights の失敗イベント時刻は 2025-xx-xx xx:xx 最後に：この記事の使い方
新人のオンボーディング資料、夜間当番のランブック、変更作業のチェックリストとして、そのまま運用現場に配布して使えます。迷ったら「エージェント → ネットワーク → ドメイン」の順でトラブルを狭める。これが AVD 運用の鉄則です。
コメント