Azure 上で Windows 11 ARM の仮想マシンを Azure Virtual Desktop（AVD）のセッション ホストとして登録しようとしても、エージェント導入済み・登録トークンも正しいのに、ホスト プールに一切表示されないことがあります。こうしたケースは設定ミスよりも「アーキテクチャが非サポート」という根本原因で発生しやすく、最短で切り分けて確実に解消する手順を整理します。
現象：Windows 11 ARM VM が AVD のセッション ホストとして登録されない
今回の状況を整理すると、次のような“いかにも登録できそうなのにできない”状態です。
- Azure 上に Windows 11 ARM（Arm64） の VM を作成
- ホスト プールに追加するために AVD エージェント／AVD ブートローダー をインストール済み
- 登録トークン（REGISTRATIONTOKEN）も正しいことを確認
- しかし、ホスト プール側の「セッション ホスト」一覧に VM が一切出てこない
“インストールは通るのに登録されない”ため、ネットワークやトークン、ドメイン参加を疑って延々と沼に入りやすいのがこのパターンです。
結論：AVD は Arm64 ベースの Azure VM をセッション ホストとしてサポートしていない
この現象の主因は「AVD のセッション ホストは Arm64 ベースの Azure VM を非サポート」であることです。
Microsoft Learn の前提条件（Prerequisites）では、セッション ホストとしてサポートされる OS は 64-bit（x64） のみであり、さらに「セッション ホストとしてサポートされない項目」の中に Arm64-based Azure VMs が明記されています。
また、まさに同じ状況（Windows 11 ARM の VM がホスト プールに登録されない）について、Microsoft Q&A でも「AVD は現在 ARM ベースの Windows 11 セッション ホストをサポートしていないため、エージェントは入ってもホスト プールに出てこない」という回答が受理され、x64 イメージに変えたら動いた旨の追記も確認できます。
「インストール成功＝登録成功」ではない理由
AVD のセッション ホスト登録は、単に MSI を入れれば終わりではなく、エージェントが Azure Virtual Desktop のサービス（管理面）と通信し、ホスト プールへの参加処理を完了して初めて登録になります。
Windows 11 ARM は x64 アプリのエミュレーション等で “インストーラー自体” が動いてしまうことがあります。しかし AVD 側は、前提条件に合致しないアーキテクチャを 有効なセッション ホストとして受け付けないため、結果として「入ったのに出てこない」状態になります。
先に押さえる：AVD セッション ホストでサポートされる OS / サポート外の条件
まずは「OS 名」だけで判断せず、“AVD セッション ホストとしてのサポート条件”を基準に選定するのが重要です。
| 区分 | サポートされる例 | 前提 | よくある落とし穴 |
|---|---|---|---|
| Windows クライアント | Windows 11 Enterprise / Windows 11 Enterprise multi-session Windows 10 Enterprise / Windows 10 Enterprise multi-session | 64-bit（x64）のみ | Windows 11 “ARM” は別枠（Arm64 VM はセッション ホスト非対応） |
| Windows Server | Windows Server 2025 / 2022 / 2019 / 2016 | 64-bit（x64）のみ | 用途が「RDS」寄りになるため、マルチセッション要件と混同しやすい |
| サポート外（代表例） | 32-bit OS、N/KN/LTSC、Arm64-based Azure VMs など | 前提条件に明記 | Azure ポータルで選べても “AVD で使える” とは限らない |
補足として、Windows 11 自体は Azure VM 上でのサポート要件（世代、Trusted Launch、CPU 世代など）があり、さらに Windows 11 on Arm は Previewであること、そして Azure ポータルはサポート対象外の VM 構成を選べてしまう場合があることも示されています。つまり「Windows 11 ARM が作れた＝AVD セッション ホストとしてもいけるはず」という推測が外れやすい状況です。
最短で原因を確定するチェック（ARM 非対応を見抜く）
“ARM が原因” であることを早期に確定させるために、以下だけは最初に確認します。
| 確認項目 | 見る場所 / コマンド例 | 判断基準 |
|---|---|---|
| OS アーキテクチャ | systeminfo | findstr /i "System Type" または 設定 > システム > バージョン情報 | ARM64 と出るなら、AVD セッション ホストとしては非対応 |
| 前提条件の“非サポート項目” | Microsoft Learn の前提条件（Prerequisites） | Arm64-based Azure VMs は非サポートと明記 |
| 同様事例の再現性 | Microsoft Q&A 事例 | ARM では登録されず、x64 では登録できた報告がある |
ここで ARM64 と確定した場合、ネットワークやトークンを深掘りするより、x64 のサポート OS に切り替えるのが最短ルートです。
解決策：x64 のサポート OS イメージで作り直して登録する
結論はシンプルで、Windows 11 ARM VM を “そのまま” AVD セッション ホストとして成立させる方法はありません（少なくとも現行の前提条件上は不可）。VM の CPU アーキテクチャを後から変更することもできないため、基本は再デプロイになります。
おすすめの進め方（失敗しにくい順）
- AVD 対応の x64 OS イメージで VM を作り直す（Windows 11 Enterprise multi-session など）
- VM を Microsoft Entra ID または Active Directory（AD DS / Entra Domain Services） に正しく参加させる
- AVD エージェント／ブートローダーをインストールし、登録トークンを渡して登録する
- ホスト プールの「セッション ホスト」に表示されることを確認し、状態が Available になったら再起動して安定化する
具体手順：x64 VM をホスト プールへ登録する（手動インストール例）
Azure ポータルの「セッション ホスト追加」ウィザードで作るのが最も簡単ですが、既存 VM を登録する／自動化したい場合は MSI の手動インストールもよく使われます。
インストール前チェック
- VM が x64 OS（サポート対象 SKU）であること
- VM が Entra ID もしくは AD DS / Entra DS に参加済みであること
- ホスト プールの登録キー（Registration key / token）が有効期限内であること
- アウトバウンド通信（特に TCP 443）が許可されていること（詳細は後述）
msiexec での登録（公式手順の形に合わせた例）
AVD エージェント（RDAgent）とブートローダーを順に入れます。エージェント側に REGISTRATIONTOKEN を渡すのがポイントです。
msiexec /i <path>\Microsoft.RDInfra.RDAgent.Installer-x64.msi /qn /norestart /l*vx <path>\RDAgentInstall.txt REGISTRATIONTOKEN=<token>
msiexec /i <path>\Microsoft.RDInfra.RDAgentBootLoader.Installer-x64.msi /qn /norestart /l*vx <path>\RDBootLoaderInstall.txtポイントは次のとおりです。
- REGISTRATIONTOKEN は MSI のプロパティ名（インストール時に渡す）であり、レジストリ上の名前（RegistrationToken）とは別物として扱うと混乱しにくい
- サイレントインストール（/qn）にする場合、ログ（/l*vx）を必ず残すと後で原因追跡が楽
- ブートローダーはエージェントの起動・更新にも関与するため、両方入って初めて安定する
「登録できたか」を VM 側で確認する（IsRegistered / RegistrationToken）
x64 に切り替えても登録できない場合は、まず VM 側のレジストリ状態とサービス状態を見ます。Microsoft Learn のトラブルシュートでは、登録キーの不正・期限切れ（INVALID_REGISTRATION_TOKEN / EXPIRED_MACHINE_TOKEN）をイベント ID 3277 で確認し、IsRegistered と 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
Restart-Service RDAgentBootLoader
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 は空になる（トークンが消費される）挙動が案内されています。ここが揃わない場合は、トークンの期限切れ・ネットワーク遮断・サービス停止などが疑わしいです。
ホスト プール側の見え方：最初は Unavailable でも慌てない
登録直後は、ホスト プールの「セッション ホスト」一覧に VM が出てきても、ステータスがすぐに Available にならないことがあります。追加手順のドキュメントでは、最初は Unavailable に見える場合があること、また利用可能な新しいエージェントがあれば自動更新が走ること、その後 Available になったタイミングで VM を再起動する流れが示されています。
さらに、ステータス（Available / Needs Assistance / Unavailable 等）はエージェントのヘルスチェック結果で変わります。特に Needs Assistance は “致命的ではないが品質が落ちる可能性” を示す状態で、URL 到達性・IMDS・監視エージェントなどのチェック不合格が原因になり得ます。
x64 でも登録されない場合のチェックリスト（ここからが本当のトラブルシュート）
ARM 非対応が原因だったケースは、x64 に切り替えるとあっさり直ることが多い一方で、環境によっては別要因で登録に失敗します。以下は“別要因”の定番です。
| 分類 | よくある原因 | 確認方法 | 対処の方向性 |
|---|---|---|---|
| トークン | 期限切れ / 間違い | イベント ID 3277（INVALID_REGISTRATION_TOKEN / EXPIRED_MACHINE_TOKEN） | 新しい登録キーを生成し、RegistrationToken を入れ直して RDAgentBootLoader 再起動 |
| サービス | RDAgentBootLoader が停止 | サービス一覧 / イベントログ（WVD-Agent, RDAgentBootLoader 等） | サービス起動、またはエージェント再インストール |
| ネットワーク | 必須 URL / FQDN への 443 が遮断 | Required FQDN を許可、URL チェックツールで検証 | FW/NSG/プロキシ例外の見直し（特に 443） |
| ドメイン/ID | Entra / AD 参加が不完全 | ドメイン参加状態、Domain joined チェック | 正しい参加方式に統一、参加権限や同期状態を見直す |
ネットワーク要件：AVD は「アウトバウンド 443」が生命線
AVD の接続は “逆方向（reverse connection）” が基本で、原則として受信ポートを開ける必要はありません。その代わり、セッション ホストと利用者が TCP 443 で AVD サービスに到達できることが必須です。URL がフィルタリングや FW でブロックされていると、登録はもちろん運用も成り立ちません。
最低限押さえたい「必要 FQDN / エンドポイント」の考え方
厳密な一覧は Microsoft Learn の Required FQDN にまとまっています。ここでは “遮断すると詰む” 典型を、意味とセットでまとめます（環境やクラウド種別で追加が必要になるため、最終的には公式一覧を基準にしてください）。
| 用途 | 例（代表） | 主なポート | 一言 |
|---|---|---|---|
| 認証 | login.microsoftonline.com | TCP 443 | ここが塞がるとトークン周りも含めて破綻 |
| AVD コントロールプレーン | *.wvd.microsoft.com | TCP 443 | 登録・ブローカー関連の中核 |
| 監視 / テレメトリ（例） | gcs.prod.monitoring.core.windows.net 等 | TCP 443 | ヘルスチェックや監視で影響 |
| Azure メタデータ / 基盤 | 169.254.169.254（IMDS）、168.63.129.16 | TCP 80 | URL 到達性チェック・基盤連携で重要 |
| ライセンス/アクティベーション | azkms.core.windows.net | TCP 1688 | KMS 系。塞ぐと OS のアクティベーションに影響 |
| （該当時）RDP Shortpath / WebRTC | 環境により UDP 3478 など | UDP | 最適化機能。要件は構成で変わる |
URL 到達性を一括検証する（Azure Virtual Desktop Agent URL tool）
「許可したはずなのに登録されない」「プロキシ配下で怪しい」というときは、公式のチェック手段を使うのが近道です。URL ツール（WVDAgentUrlTool.exe）をダウンロードし、必要な URL へ到達できるかをまとめて検証できます。
# （例）ツール実行の流れイメージ
# 1) WVDAgentUrlTool.exe を取得して展開
# 2) 管理者として実行し、結果を確認（失敗した URL をネットワーク側で許可）また、プロキシ運用は構成によっては回避・例外設定が必要です。公式のガイドラインでも、必要な URL への到達性を確保し、不要な経路強制（例えば RDP を TCP に固定する等）を行うと品質低下につながる点が触れられています。
イベントログで確証を取る：登録されない時に見るべきソースと ID
「結局どこで詰まっているのか」を最短で確定するには、イベントログが一番強いです。Microsoft Learn のトラブルシュートでは、アプリケーションログで以下のソースを確認することが推奨されています。
- WVD-Agent
- WVD-Agent-Updater
- RDAgentBootLoader
- MsiInstaller
特に遭遇しやすいイベントを、意味と次アクションでまとめます。
| イベント ID（例） | 典型メッセージ | 意味 | まずやること |
|---|---|---|---|
| 3277 | INVALID_REGISTRATION_TOKEN / EXPIRED_MACHINE_TOKEN | 登録キーが無効（間違い/期限切れ） | 新しい登録キーを生成→RegistrationToken を入れ直し→BootLoader 再起動 |
| 3277 | INVALID_FORM | ブローカー/エンドポイントに到達できない可能性 | Required FQDN 許可、/api/health 到達確認、TLS/プロキシ方針見直し |
| 3703 | RD Gateway Url: is not accessible | ゲートウェイ URL に到達できない | URL チェックツールで失敗 URL を特定し許可 |
| 3019 | web socket transport に到達できない | WebSocket 系の URL ブロック疑い | FW/プロキシのフィルタを点検 |
ネットワーク疎通の追加確認として、セッション ホスト構成のトラブルシュートでは rdbroker.wvdselfhost.microsoft.com の 443 を疎通確認する例（psping）が紹介されています。環境によって名前が変わるため、実際には Required FQDN と自環境の BrokerResourceIdURI を基準に確認するのが安全です。
再発防止：イメージ選定時に「AVD の前提条件」を最初に見る
今回のように Azure 上で Windows 11 ARM VM が作成できると、「それなら AVD にも使えるはず」と考えがちです。しかし、Windows 11 が Azure VM として動く条件と、AVD のセッション ホストとして動く条件は一致しません。
- AVD のセッション ホストは、前提条件の“サポートされる OS と非サポート項目”が基準（Arm64 VM は非サポート）
- Windows 11 on Arm 自体は Preview であり、Azure ポータルはサポート外構成を選べてしまう場合がある
この2点を最初に押さえておくと、「エージェント入れたのに登録されない」という時間のかかる調査を避けやすくなります。
まとめ：原因は “ARM 非対応”、解決は “x64 で再デプロイ” が最短
Windows 11 ARM VM に AVD エージェント／ブートローダーを入れてもホスト プールに出てこない場合、もっとも可能性が高いのは Arm64 ベース VM が AVD セッション ホスト非サポートであることです。
解決策は、サポート対象の x64 OS イメージで VM を作り直し、同じ手順で登録すること。これで同様の事例では正常登録が確認されています。
それでも登録できない場合は、トークン（期限切れ）、ネットワーク（Required FQDN への 443）、サービス（BootLoader 停止）をイベントログ中心に潰していくと、最短で原因に到達できます。
コメント