Azure Local 環境で Azure Virtual Desktop に接続できない時の原因と対処法（ゲートウェイ／ドメイン不整合）

Azure Local 環境で Azure Virtual Desktop (AVD) を構築したのに、Web クライアントやデスクトップクライアントから接続できない――一方で RDP 3389 では普通につながる。このギャップに悩む管理者は少なくありません。本記事では、実際に遭遇したドメイン不整合が原因の事例を軸に、切り分けと解決のポイントを詳しく解説します。

シナリオ概要：Azure Local の AVD に接続できない

まずは、実際に発生した状況を整理します。すべての設定を終えたつもりなのに「AVD クライアントだけがつながらない」という、よくあるようで原因が掴みにくいパターンです。

構成の前提

Azure Local 環境で Azure Virtual Desktop を構成
以下は正常に作成済み
- ホストプール
- アプリグループ（Remote Desktop / RemoteApp）
- ワークスペース
アプリグループにはユーザー割り当ても実施済み
セッションホスト（AVD の VM）はオンプレミス Active Directory ドメインに参加
割り当てに使ったユーザーは Microsoft Entra ID（旧 Azure AD）のクラウド専用ユーザー

発生していた症状

RDP クライアントから VM へ 3389/TCP で直接接続するとログオン可能
AVD Web クライアント／デスクトップクライアントからの接続は失敗
Test-NetConnection でセッションホストやゲートウェイに対して以下の結果
- 3389/TCP：成功
- 443/TCP：失敗（到達不可）となるケースがある
セッションホスト側の AVD エージェント診断で https://<id>.rdbroker.microsoft.com などの Broker URL を確認
「AVD ゲートウェイの FQDN をどこで確認・変更すればいいのか」が不明

最終的に判明した根本原因

最終的に判明したのは、ネットワークやクライアントではなく、「ユーザーのドメイン」と「セッションホストが所属するドメイン」の不整合 でした。

セッションホスト：オンプレ AD ドメインに参加（例：corp.local）
割り当てユーザー：Entra ID 側にだけ存在するクラウド専用ユーザー（例：[email protected]）
オンプレ AD と Entra ID の同期（Azure AD Connect / Entra Connect）が未実施 or UPN サフィックス不一致

この状態では、AVD の制御プレーンではユーザーの認証が通るように見えても、バックエンドでセッションホストにログオンさせる段階でドメイン不整合が発生し、最終的な接続がうまくいきません。

解決策の概要

オンプレミス AD ユーザーを Azure AD Connect（Entra Connect）で Microsoft Entra ID に同期
同期されたユーザー（ハイブリッド ID ユーザー）を AVD のホストプール／アプリグループに割り当て直す
その結果、AVD クライアントからの接続が正常に成功

つまり、「ID 基盤の整合性を取った瞬間に、今までの接続エラーが解消した」 という非常に教訓的な事例です。

なぜ 3389 の RDP は通るのに AVD は失敗するのか

管理者の多くが最初に混乱するポイントはここです。「RDP が通るならネットワークは問題ないのでは？」と考えがちですが、AVD の接続パスは別物です。

接続経路の違い

項目	直接 RDP 接続	Azure Virtual Desktop（AVD）
クライアントからの宛先	セッションホスト VM の IP / FQDN	AVD ゲートウェイ／ブローカーの FQDN
主なポート	TCP 3389	TCP 443（任意で UDP 3390）
トランスポート	RDP プロトコルを直接使用	HTTPS（TLS）トンネル越しに RDP フロー
認証・権限	セッションホスト上のローカル/ドメイン認証	Entra ID 認証 + AVD ブローカーによるセッション割り当て
依存コンポーネント	DNS、ネットワーク、Windows 認証のみ	Entra ID、AVD ブローカー、ゲートウェイ、セッションホスト上の AVD エージェント

このように、AVD は「クライアント → AVD ゲートウェイ → セッションホスト」という間接ルート を辿ります。そのため、次のような状況が簡単に起きます。

3389/TCP は VM（セッションホスト）へ到達しているので、RDP は通る
しかし 443/TCP がゲートウェイ FQDN まで通っていない、または名前解決ができない
その結果、AVD の接続確立フェーズでエラーになる

3389 が開いていることは「セッションホストへ直通するための回線」が生きているだけであり、「AVD として正しく動作している」ことの保証にはなりません。

Azure Local 環境固有のポイント

クラウド版 AVD と比べて、Azure Local 環境には次のような特徴があります。

AVD のゲートウェイやブローカーが、Azure パブリッククラウドの共通エンドポイントではなく、Azure Local 環境用の必須エンドポイント に変わっている
ネットワーク的にはオンプレ／エッジロケーションに近いため、内部 DNS と境界ファイアウォールの設計ミスが即座に影響する
セッションホストはオンプレ AD に参加させるケースが多く、Entra ID 側の ID 設計との整合性がより重要になる

今回の事例では、ネットワークの 443 到達性や DNS も重要な論点でしたが、最終的には ID 側の設計ミス（ドメイン不整合） が主因でした。

今回の根本原因：ユーザーとセッションホストのドメイン不整合

もう一度、根本原因を整理します。

ドメイン不整合とは何か

ここでの「ドメイン不整合」は、次のような状態を指します。

セッションホストの参加ドメイン：オンプレ AD（例：corp.local）
AVD で割り当てたユーザー：Entra ID 内のみで完結するクラウド専用ユーザー（例：[email protected]）
オンプレ AD と Entra ID の間で、そのユーザーが同一人物として扱われる仕組み（AD 同期）がない

AVD 側では「Entra ID のユーザー」として認証は通りますが、最終的にはセッションホストに対して Windows ログオンを行う必要があります。このとき、オンプレ AD に該当ユーザーが存在しない、または UPN が一致しないと、セッションホスト側で「誰なのか分からない」状態になります。

結果として、

AVD クライアント視点：
「資格情報を入力したのに接続エラーになる／エラーコードが分かりにくい」
管理者視点：
「ゲートウェイやネットワークを疑って調査しても、決定的な原因が見つからない」

という、やや厄介な状況に陥ります。

典型的なアンチパターン

項目	誤った構成例	望ましい構成例
セッションホストのドメイン	オンプレ AD（`corp.local`）	オンプレ AD（`corp.local`）
AVD 割り当てユーザー	Entra ID のクラウド専用ユーザーのみ	オンプレ AD から同期されたハイブリッドユーザー
UPN サフィックス	オンプレ：`[email protected]` Entra：`[email protected]`（関連なし）	オンプレ：`[email protected]` Entra：`[email protected]`（一致）
AD 同期	未構成 or 一部のみ	Azure AD Connect / Entra Connect で組織的に運用

ポイントは、「AVD で使うユーザー = セッションホストにログオンできるユーザー」でなければならない、という非常にシンプルな原則です。

切り分けチェックリスト：再現時に見るべきポイント

同じようなトラブルに遭遇した場合、以下の順番で切り分けると効率的です。

ID／割り当ての確認

セッションホストの参加ドメインを確認（例：サーバーの システムのプロパティ からドメイン名を確認）
AVD のアプリグループ／ホストプールに割り当てたユーザーが、そのドメインに存在しているか
Entra ID で対象ユーザーの「同期の種類」が「同期済み（オンプレミスから）」になっているか
UPN サフィックス（例：@contoso.com）がオンプレ AD と Entra ID で一致しているか

PowerShell や GUI での確認例：

# セッションホスト上で現在のドメインを確認
whoami /upn

# ローカルのログオン先ドメインを確認
echo %USERDOMAIN%

可能なら、同期済みグループ（オンプレ AD グループを Entra に同期させたもの）を作成し、アプリグループにはそのグループごと割り当てると運用が楽になります。

ネットワーク／ファイアウォールの確認

次に、クライアントからゲートウェイ／ブローカーまでの 443/TCP が開いているかを確認します。

# クライアント端末から
Test-NetConnection &lt;ゲートウェイまたは Broker の FQDN&gt; -Port 443

# 参考：セッションホストに対する 3389 の確認（RDP 用）
Test-NetConnection &lt;セッションホスト FQDN or IP&gt; -Port 3389

あわせて、以下もチェックします。

Windows Defender ファイアウォール（セッションホスト側）で 443/TCP が許可されているか
NSG やオンプレの境界 FW で必須 FQDN 宛ての 443/TCP が遮断されていないか
AVD の快適さを優先する場合は UDP 3390 も開放できるか検討

DNS 解決の確認

FQDN が名前解決できなければ、いくらポートを開けても接続はできません。企業内 DNS に正しいレコードやフォワーダーが設定されているかを確認しましょう。

# クライアントから
nslookup &lt;ゲートウェイまたは Broker の FQDN&gt;
Resolve-DnsName &lt;ゲートウェイまたは Broker の FQDN&gt;

特に Azure Local 環境では、内部 DNS と外部 DNS のどちらで名前を解決させるのか を明確にしておくことが重要です。

ゲートウェイ／ブローカー情報の確認

「そもそもどの FQDN に向けて通信しているのか」が分からないと、ネットワークチームとも話が噛み合いません。以下のような場所から Broker／Gateway の FQDN を確認できます。

ホストプールのプロパティ（Azure ポータル / Azure Local の管理ポータル）
セッションホスト側のイベントログ
- Applications and Services Logs > Microsoft > Windows > RemoteDesktopServices-RDInfra-Agent > Operational
AVD エージェント付属の接続性チェックツール

ログには https://<id>.rdbroker.microsoft.com のような Broker URL が記録されていることがあり、その FQDN に対する 443/TCP と DNS 解決が重要な確認ポイントになります。

クライアント比較：Web / デスクトップ

Web クライアントとデスクトップクライアントでは、同じエラーでもメッセージ表現が異なることがあります。両方で試して、

どの段階で失敗しているか（署名、サインイン、リソースの取得、接続確立…）
表示されるエラーコード（例：0xXXXXXX）

を記録しておくと、マイクロソフトのサポートやネットワークチームとの連携がスムーズになります。

解決方法：オンプレ AD ユーザーを Entra ID に同期して割り当て直す

それでは、今回の事例で有効だった具体的な解決策を整理します。

解決の方向性

方針はシンプルです。

セッションホストにログオンできるオンプレ AD ユーザー を Entra ID に同期
AVD の割り当ては、その同期済みユーザー（ハイブリッド ID）に対して行う

このようにすることで、

Entra ID 上では AVD のアクセス制御や MFA を活用
セッションホスト側では、オンプレ AD アカウントとしてログオン

という一貫した ID フローが実現されます。

具体的な作業ステップ例

オンプレミス AD に対象ユーザーが存在することを確認
- 例：corp.local\user1 が実在し、RDP でセッションホストにログオンできることを確認
UPN サフィックスの整備
- オンプレ AD ユーザーの UPN を外部公開ドメイン（例：@contoso.com）に変更
- Entra ID 側でも同じドメインがカスタムドメインとして登録・確認済みであること
Azure AD Connect / Entra Connect の導入または設定見直し
- 対象 OU が同期対象に含まれているか
- フィルタリング設定でユーザーが除外されていないか
同期の実行と確認
- 同期後、Entra ID ポータルで対象ユーザーを検索
- 「オンプレミスから同期済み」であることを確認
AVD のホストプール／アプリグループの割り当てを見直し
- クラウド専用ユーザーではなく、同期済みユーザー（または同期済みグループ）を割り当て
クライアントから再接続テスト
- Web クライアントとデスクトップクライアントの両方で確認

このステップを踏むことで、今回の事例では接続エラーが解消し、AVD セッションが正常に確立できるようになりました。

ネットワーク／ポート設計のベースライン

ドメイン不整合が主因だったとはいえ、ネットワーク周りも重要です。AVD を安定運用するための最低限の「ネットワーク前提」を整理しておきます。

通信元	通信先	ポート	用途	備考
クライアント	AVD ゲートウェイ / ブローカー FQDN	TCP 443	AVD セッション確立・制御	必須。閉じていると AVD は利用不可
クライアント	AVD ゲートウェイ / ブローカー FQDN	UDP 3390	マルチメディア最適化等	任意だが開放推奨
セッションホスト	AVD サービスの必須 FQDN	TCP 443	エージェント通信	Azure Local 固有の FQDN 群を含む
管理用端末	セッションホスト VM	TCP 3389	管理者向けの直接 RDP	ユーザーからは不要な場合も

運用ドキュメントやネットワーク標準に、必須ポートと必須 FQDN の一覧 を明文化しておくと、将来のトラブルシューティングが格段に楽になります。

ログ・診断情報の活用

AVD のトラブルでは、セッションホスト側ログが非常に役立ちます。特に以下のログは習慣的に確認できるようにしておきましょう。

AVD エージェントログ

イベントビューアー
- Applications and Services Logs > Microsoft > Windows > RemoteDesktopServices-RDInfra-Agent > Operational
Broker への接続状況、エラーコード、FQDN 情報などが記録

ここから、

どの Broker / Gateway FQDN に接続しようとしているか
TLS ハンドシェイクや証明書関連で失敗していないか
ユーザー割り当てが正しく認識されているか

を読み取ることができます。

接続性チェックツール

AVD エージェントには、必須エンドポイントへの到達性をまとめてチェックするツールが付属している場合があります。これを定期的に、あるいは構成変更のたびに実行して、

どのエンドポイントへの接続が成功／失敗しているか
DNS 解決に問題はないか

を把握しておくと、問題の切り分けが格段にスムーズになります。

よくあるつまずきと注意点

今回の事例をふまえ、Azure Local 環境の AVD で特に注意したいポイントをまとめます。

「3389 が通る = AVD も通る」ではない
- AVD は 443/TLS 経由でゲートウェイ／ブローカーと通信するため、3389 のみ開いていても意味がない
クラウド専用ユーザーだけで構成しない
- オンプレ AD 参加のセッションホストに対しては、オンプレ AD から同期されたユーザーを使うのが原則
FQDN 未解決や証明書エラーは見え方が分かりにくい
- Web クライアントとデスクトップクライアントでエラー表示が異なるため、誤解しやすい
UPN サフィックスのバラバラ運用
- @corp.local と @contoso.com が混在していると、ユーザーも管理者も混乱する

再発防止のための運用ベストプラクティス

最後に、同じトラブルを繰り返さないための運用上の工夫を整理します。

ID 管理の統一

UPN サフィックスを外部公開ドメイン（例：@contoso.com）に統一
オンプレ AD と Entra ID の間で AD 同期を定常運用し、「クラウド専用ユーザー」と「オンプレ専用ユーザー」を極力減らす
AVD の割り当ては基本的に「同期済みグループ」を使い、人の追加・削除はオンプレ AD グループ操作に集約

ネットワーク基準の明文化

TCP 443（＋必要なら UDP 3390）を 「AVD 標準ポート」 としてネットワーク設計書に明記
AVD 用の必須 FQDN リストを社内 DNS／境界 FW 設定に恒久反映
構成変更や FW ポリシー変更時には、AVD 接続性チェックを回帰テストとして実施

監視と記録

セッションホストの AVD エージェントログを中央ログ基盤（例：Log Analytics、SIEM）に送信
接続失敗イベントが一定回数を超えたらアラートを上げる仕組みを検討
ユーザーからの「つながらない」問い合わせに備え、切り分けフロー（本記事のチェックリスト）をナレッジ化

まとめ：ひとことで言うとこういう問題

本記事で取り上げた事例をひとことでまとめると、次のようになります。

主因： ユーザーのドメインとセッションホストのドメインが一致していなかった（クラウド専用ユーザー vs オンプレ AD ドメイン）
効いた対策： オンプレ AD を Entra ID に同期し、同期済みユーザー（ハイブリッド ID ユーザー）を AVD に割り当て直した
あわせて確認すべきポイント：
- クライアントからゲートウェイ／ブローカー FQDN への 443/TCP 通信
- DNS で FQDN が正しく解決できるか
- AVD エージェントログに出力される Broker/Gateway URL とエラーコード

「RDP は通るのに AVD だけダメ」という状況に出会ったら、まずは本記事のチェックリストをなぞりつつ、ネットワークだけでなく ID（ドメイン整合性）にも目を向ける ようにしてみてください。それが、Azure Local 環境の AVD を安定運用する近道になります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Local 環境で Azure Virtual Desktop に接続できない時の原因と対処法（ゲートウェイ／ドメイン不整合）

シナリオ概要：Azure Local の AVD に接続できない

構成の前提

発生していた症状

最終的に判明した根本原因

解決策の概要

なぜ 3389 の RDP は通るのに AVD は失敗するのか

接続経路の違い

Azure Local 環境固有のポイント

今回の根本原因：ユーザーとセッションホストのドメイン不整合

ドメイン不整合とは何か

典型的なアンチパターン

切り分けチェックリスト：再現時に見るべきポイント

ID／割り当ての確認

ネットワーク／ファイアウォールの確認

DNS 解決の確認

ゲートウェイ／ブローカー情報の確認

クライアント比較：Web / デスクトップ

解決方法：オンプレ AD ユーザーを Entra ID に同期して割り当て直す

解決の方向性

具体的な作業ステップ例

ネットワーク／ポート設計のベースライン

ログ・診断情報の活用

AVD エージェントログ

接続性チェックツール

よくあるつまずきと注意点

再発防止のための運用ベストプラクティス

ID 管理の統一

ネットワーク基準の明文化

監視と記録

まとめ：ひとことで言うとこういう問題

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure Local 環境で Azure Virtual Desktop に接続できない時の原因と対処法（ゲートウェイ／ドメイン不整合）

シナリオ概要：Azure Local の AVD に接続できない

構成の前提

発生していた症状

最終的に判明した根本原因

解決策の概要

なぜ 3389 の RDP は通るのに AVD は失敗するのか

接続経路の違い

Azure Local 環境固有のポイント

今回の根本原因：ユーザーとセッションホストのドメイン不整合

ドメイン不整合とは何か

典型的なアンチパターン

切り分けチェックリスト：再現時に見るべきポイント

ID／割り当ての確認

ネットワーク／ファイアウォールの確認

DNS 解決の確認

ゲートウェイ／ブローカー情報の確認

クライアント比較：Web / デスクトップ

解決方法：オンプレ AD ユーザーを Entra ID に同期して割り当て直す

解決の方向性

具体的な作業ステップ例

ネットワーク／ポート設計のベースライン

ログ・診断情報の活用

AVD エージェント ログ

接続性チェック ツール

よくあるつまずきと注意点

再発防止のための運用ベストプラクティス

ID 管理の統一

ネットワーク基準の明文化

監視と記録

まとめ：ひとことで言うとこういう問題

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

AVD エージェントログ

接続性チェックツール

コメントするコメントをキャンセル