リモート拠点の Hyper‑V ホストを VPN 越しに管理していて、VM の電源操作はできるのにコンソールを開くと「リモート ビデオが中断されました」と言われてしまう――そんな現象に悩んでいませんか。本記事では、典型的な構成として Windows Server Core 2025＋Windows 10 を想定し、原因と具体的な対処手順を詳しく解説します。
Hyper‑V Manager で VM コンソールに接続できない症状の概要
Hyper‑V 環境のトラブルとしてよく見られるのが、次のような状況です。
- リモート拠点にある Windows Server Core 2025（Hyper‑V ホスト） を、社内から VPN 越しの Windows 10 クライアント で管理している
- Hyper‑V Manager からホストへの接続は問題なく行える
- 仮想マシン（VM）の作成・起動・停止もでき、状態も参照できる
- プレビュー画面のサムネイルは動いているように見える
- しかし、VM をダブルクリックしてコンソールを開こうとすると
「リモート ビデオが中断されました（Video remoting was disconnected）」 と表示され、画面が真っ黒のまま接続できない
ホストにはつながるのに VM コンソールだけが開けないため、「Hyper‑V の設定や権限は合っているはずなのになぜ？」と判断が難しくなりがちです。しかし、この症状はパターンが決まっており、原因を順序立てて潰していけば高い確率で解消できます。
なぜ「リモート ビデオが中断されました」になるのか ― 原因の全体像
このエラーは、Hyper‑V Manager 自体ではなく、VM コンソール用のビデオチャネルの確立に失敗した時に出るメッセージです。ホストの管理操作用チャネル（WMI や WinRM）と、VM 画面転送用チャネルは別物であり、後者が確立できないとこの現象が発生します。
典型的な原因を整理すると、次の 3 つに集約できます。
| 原因カテゴリ | 主な内容 | 典型的な兆候 |
|---|---|---|
| ポート遮断 | VM コンソール用チャネルの TCP 2179 がファイアウォールや VPN でブロックされている | ホスト操作はできるが、VM コンソールのみ黒画面や即切断になる |
| 認証委任（ダブルホップ） | クライアント → ホスト → VM 接続サービス の二段階認証で資格情報の委任に失敗 | ポートは空いているが、イベントログに認証失敗が記録される |
| 権限不足 | 操作ユーザーがホストの 「Hyper‑V Administrators」 グループに含まれていない | 特定ユーザーだけコンソールが開けない／ホストを変えると再現しない |
特に多いのは TCP 2179 がどこかでブロックされているケースです。実際、フォーラム等でも「最終的には 2179/TCP を VPN・FW 側で許可したら直った」という報告がよく見られます。
想定する環境と前提条件
この記事では、次のような構成を前提にしています。
- Hyper‑V ホスト：Windows Server Core 2025
- 管理クライアント：Windows 10（Hyper‑V Manager / RSAT インストール済み）
- 通信経路：インターネット VPN または拠点間 VPN 経由
- 管理アカウント：ドメインアカウント、もしくはホスト上のローカル管理者相当のアカウント
この構成以外でも、Windows Server 2019 / 2022 などの Hyper‑V ホストでほぼ同様に応用できます。オンプレ／クラウド上の VM（IaaS）のどちらでも基本は同じです。
原因別のアプローチと全体のすすめ方
効率良くトラブルシューティングするために、次の順番で確認していくことをおすすめします。
- TCP 2179 が通っているか（ネットワーク／FW）
- CredSSP など認証委任の設定
- ホスト側のローカル権限（Hyper‑V Administrators）
- イベントログで裏付けを取る
- VPN・EDR・セキュリティ製品の影響を疑う
それぞれ、具体的なコマンドと確認ポイントを詳しく見ていきます。
TCP 2179 を開放してビデオチャネルを確立する
Hyper‑V の VM コンソール（VMConnect.exe）は、RDP ライクな独自プロトコルで VM 画面を転送しており、そのためのポートとして TCP 2179 を利用します。このポートがどこかでブロックされていると、ホストに接続できても VM コンソールは開けません。
ホストの Windows ファイアウォール設定を確認・有効化
まずは Hyper‑V ホスト（Windows Server Core 2025）側で、該当するファイアウォールルールが有効かを確認します。Server Core なので GUI は使えません。PowerShell で作業します。
# ルールの状態確認
Get-NetFirewallRule -DisplayName "Hyper-V (VMMS-In)"
# ルール有効化 & 全プロファイル許可
Enable-NetFirewallRule -DisplayName "Hyper-V (VMMS-In)"
Set-NetFirewallRule -DisplayName "Hyper-V (VMMS-In)" -Profile Any
上記ルールは通常、TCP 2179 を含む Hyper‑V 関連通信を許可するためのものです。サードパーティ製のファイアウォールや管理ツールが導入されている場合は、Windows Defender Firewall 側の設定が上書きされていないかも合わせて確認してください。
VPN・境界ファイアウォールで TCP 2179 を許可する
社内からリモート拠点の Hyper‑V ホストにアクセスする場合、途中に複数のファイアウォールや VPN 装置、UTM、クラウド型セキュリティサービスなどが入っていることがほとんどです。これらの機器が、RDP（TCP 3389）は通すが TCP 2179 はデフォルト拒否というポリシーになっていると、まさに本記事のような症状が発生します。
ネットワーク担当者に依頼し、以下の条件で通信が許可されているかを確認・設定してください。
| 項目 | 値 |
|---|---|
| プロトコル | TCP |
| ポート番号 | 2179 |
| 方向 | クライアント → ホスト（必要に応じて双方向） |
| 宛先 | Hyper‑V ホストの IP アドレス（管理ネットワーク） |
製品によっては「RDP アプリケーション制御」などと紐付いている場合もあるため、RDP 以外のリモートコンソール系ポートがまとめてブロックされていないかも要チェックです。
クライアントから TCP 2179 の疎通をテストする
設定変更後は、クライアント（Windows 10）から Hyper‑V ホストに対して、TCP 2179 の疎通確認を行います。
Test-NetConnection <ホスト名またはIP> -Port 2179 -InformationLevel Detailed
結果の TcpTestSucceeded が True になっていれば、TCP 2179 の到達性は確保できています。False の場合は、どこかで依然としてブロックされている可能性が高いので、経路上の FW/VPN を再確認してください。
認証委任（ダブルホップ）問題を解消する ― CredSSP の最小構成
ネットワーク的には TCP 2179 が通っているのに、依然として「リモート ビデオが中断されました」となり、イベントログには認証エラーが記録されている場合、ダブルホップ問題（資格情報の委任）を疑います。
Hyper‑V Manager から VM コンソールを開く際、実際には次のような通信が行われます。
- クライアント（Windows 10） → Hyper‑V ホスト（Server Core 2025）
- Hyper‑V ホスト → VM 接続サービス（VM のコンソールセッション）
このとき、クライアントの資格情報をホスト経由で VM に委任する必要がありますが、既定の安全な設定のままだと、この「委任」が許可されていないことがあります。その結果、認証が途中で失敗し、ビデオチャネルが切断されてしまうのです。
クライアント側で CredSSP を有効化する
まず、管理クライアント（Windows 10）で管理者権限の PowerShell を開き、次のコマンドを実行します。
Enable-WSManCredSSP -Role Client -DelegateComputer "ホスト名またはFQDN"
"ホスト名またはFQDN" には、Hyper‑V ホストの実際のホスト名または FQDN を指定します。複数ホストをまとめて指定したい場合は、ワイルドカードやドメイン名を活用しますが、セキュリティ上は最小限の範囲に留めることを強くおすすめします。
ホスト側で CredSSP を受け入れる設定を行う
次に、Hyper‑V ホスト（Server Core 2025）側で CredSSP サーバーロールを有効化します。ホスト上の PowerShell で以下を実行します。
Enable-WSManCredSSP -Role Server
これにより、当該ホストが CredSSP による資格情報の委任を受け入れられるようになります。設定後、再度 Hyper‑V Manager から VM コンソールを開いてみて、症状が改善するか確認してください。
CredSSP を避けたい場合の代替案
組織ポリシー上、CredSSP の利用が制限されている場合は、次のような代替案も検討できます。
- クライアント・ホストを同一ドメインに参加させ、Kerberos 認証＋制約付き委任（Constrained Delegation）を構成する
- 一時的にホストへ RDP 接続し、ホスト側から
vmconnect.exeを実行してローカル接続する - 管理専用のジャンプサーバーを用意し、そこから Hyper‑V Manager を実行する
ただし、構成が複雑になるため、まずは CredSSP での動作確認を行い、その後ポリシーに応じて恒久対策を検討する流れが現実的です。
ホスト側の権限不足を確認する ― Hyper‑V Administrators グループ
特定のユーザーだけが VM コンソールを開けない場合や、同じホストでもアカウントを変えると症状が変わる場合は、ホスト側のローカル権限不足も疑う必要があります。
Hyper‑V ホストでは、VM の作成・削除・コンソール接続などを行うユーザーは、少なくとも以下のいずれかの権限を持っている必要があります。
- ローカル Administrators グループのメンバー
- Hyper‑V Administrators グループのメンバー
よりセキュアに運用する場合は、後者の Hyper‑V Administrators グループに必要なアカウントだけを追加する構成が推奨されます。
ユーザーを Hyper‑V Administrators に追加する
ホスト（Server Core 2025）で、次のコマンドを実行してユーザーをグループに追加します。
Add-LocalGroupMember -Group "Hyper-V Administrators" -Member "ドメイン\ユーザー"
ここでは、"ドメイン\ユーザー" を実際のドメイン名とユーザー名に置き換えてください。ローカルアカウントの場合は ".\ユーザー名" のように指定します。
グループに追加した後、一度 Hyper‑V Manager を終了し、再度起動してからコンソール接続を試してください。場合によっては、クライアント端末の再サインインが必要なこともあります。
イベントログで「どこで失敗しているか」を特定する
ここまでの設定を行っても解消しない場合、やみくもに設定を変える前に、イベントログから根拠を確認することが重要です。
確認すべき主なイベントログ
Hyper‑V ホスト側で、次のログを重点的に確認します。
- アプリケーションとサービス ログ > Microsoft > Windows > Hyper‑V‑VMMS
（仮想マシン管理サービス） - アプリケーションとサービス ログ > Microsoft > Windows > Hyper‑V‑Worker
（VM ワーカー プロセス）
これらのログに、以下のようなイベントが出ていないか確認します。
- 接続要求が拒否された旨の警告・エラー
- 認証に失敗したことを示すイベント
- VMID（仮想マシン ID）単位でのアクセス拒否
ログメッセージの中に「認証」「資格情報」「アクセスが拒否されました」といったキーワードが含まれている場合は、ポートではなく認証／権限まわりが原因である可能性が高まります。逆に、そうした記録がほとんどなく、クライアントからの接続要求自体が来ていないようであれば、ネットワーク／FW レベルで通信が届いていないと判断できます。
すぐにできる切り分けテスト
本格的な調査に入る前に、いくつかの「クイックテスト」を実施することで、原因の切り分けを大幅に効率化できます。
クライアントからの疎通確認 – Test‑NetConnection
先ほども触れましたが、クライアントから Hyper‑V ホストに対して TCP 2179 の疎通確認を行います。
Test-NetConnection <ホスト名> -Port 2179 -InformationLevel Detailed
ここで True になるかどうかで、ネットワーク／FW レベルの問題なのかを切り分けられます。
ホスト上で VM コンソールが開けるか ― vmconnect.exe のローカル実行
ホスト自身から VM コンソールを開いてみることで、問題が「ネットワーク」なのか「ホスト構成」なのかを明確にできます。ホスト（Server Core 2025）上で次のように実行します。
# ホスト上で実行（ローカル接続）
vmconnect.exe localhost "<VM名>"
これで正常にコンソールが表示される場合、少なくともホスト内部の Hyper‑V 構成は正常であり、問題は「クライアント～ホスト間のネットワーク」または「認証委任」に絞り込めます。逆に、ホストローカルでも開けない場合は、VM 自体の状態やホスト上の Hyper‑V サービスの問題も疑う必要があります。
Hyper‑V サービス（VMMS）が正常か確認する
VM コンソール接続には、Hyper‑V 仮想マシン管理サービス（VMMS）が関わっています。ホスト上でサービス状態を確認します。
Get-Service vmms
Status が Running になっているかを確認し、もし停止している場合はサービスの起動や、ホストの再起動を検討してください。頻繁に停止する場合は、システムログや Hyper‑V 関連ログを確認し、根本原因を調査します。
それでも解消しない場合に確認すべきポイント
ここまでの設定を行っても解消しない場合、次のような要因が隠れている可能性があります。
VPN・EDR・次世代 FW によるアプリケーション制御
最近のセキュリティ製品や次世代ファイアウォール（NGFW）は、単純なポート制御だけでなく、アプリケーション識別による制御を行う機能を持っています。その結果、ポート 2179 は開けたつもりでも、「不明なリモートコンソール」として検査・遮断されているケースがあります。
- VPN クライアントや SWG（Secure Web Gateway）のポリシーで、リモートアクセス系トラフィックが制限されていないか
- EDR/アンチウイルス製品の「ネットワーク保護」機能が、vmconnect.exe の通信をブロックしていないか
- UTM/NGFW でアプリケーション識別ルールにより RDP 以外のリモート画面転送が制限されていないか
一時的にポリシーを緩めるテスト環境を用意し、Hyper‑V コンソール接続だけを確認する、というアプローチも有効です。
名前解決（FQDN）と逆引きの整合性
Kerberos 認証を利用している場合、ホスト名・FQDN と SPN（Service Principal Name）・逆引き DNS の整合性が崩れていると認証に失敗し、結果としてコンソール接続もできなくなることがあります。
- クライアントからホスト名／FQDN で
pingを実行し、期待通りの IP に解決されているか - 逆引き DNS が正しく設定されているか
- 同一の IP アドレスに複数のホスト名が混在していないか
特に、クラウドや仮想化環境で頻繁に IP を付け替えている場合、DNS 設定や SRV レコードの整合性が崩れやすいため注意が必要です。
Hyper‑V 管理ツール（クライアント側）のバージョン
クライアントの Hyper‑V Manager が古いバージョンのままになっていると、サーバー側の新しいバージョンの Hyper‑V と微妙な非互換が生じることがあります。特に Windows 10 の古いビルドに RSAT を後付けしている環境では、アップデート状態を確認しておくと安心です。
- Windows 10 自体を最新ビルドまで更新する
- RSAT / 管理ツールを最新の状態にする
同じクライアント PC から別の Hyper‑V ホストに接続して問題なくコンソールが開ける場合は互換性の可能性は低めですが、「そのホストだけ常にダメ」という場合でも、一応確認しておく価値があります。
セキュリティ上の注意 ― CredSSP の扱い
CredSSP による資格情報の委任は、ダブルホップ問題を解消する強力な仕組みである一方、誤った設定を行うと資格情報が意図しないサーバーに渡ってしまうリスクがあります。そのため、以下の点に注意してください。
-DelegateComputerには、可能な限り 具体的なホスト名・FQDN を指定し、ワイルドカードや広範なドメイン指定は避ける- 検証が終わったら、不要な委任設定を解除する
不要になった CredSSP 設定の無効化
検証や一時対応で CredSSP を有効にした後、不要になった場合は次のコマンドで無効化できます。
Disable-WSManCredSSP -Role Server
Disable-WSManCredSSP -Role Client
運用環境では、「とりあえず全部に委任を許可する」のではなく、対象ホストを絞った上で、定期的に設定を棚卸しする仕組みを作っておくと安全です。
実際の解決例 ― TCP 2179 のブロック解除で復旧
実際のトラブルシューティング事例では、次のような流れで問題が解決することが多いです。
- Hyper‑V Manager からホストに接続できるが、VM コンソールを開くと「リモート ビデオが中断されました」と表示される
- ホスト上の Windows ファイアウォールは Hyper‑V 関連ルールが有効になっていることを確認
- クライアントから
Test-NetConnection <ホスト> -Port 2179を実行したところ、TcpTestSucceeded : Falseとなる - ネットワークチームに調査を依頼したところ、拠点間 VPN のフィルタで TCP 2179 が閉じていることが判明
- VPN 装置側で TCP 2179 を許可するポリシーを追加したところ、VM コンソールが問題なく開けるようになった
このように、ホスト側の設定をいくら変えても、途中の VPN や FW が閉じていたら VM コンソールは絶対に開かないという点が重要です。特に「RDP は通るから FW は関係ないはず」と思い込みがちですが、Hyper‑V コンソールは RDP（3389）とは別のポートを使うため、必ず TCP 2179 を個別に確認するようにしましょう。
まとめ ― 効率的なトラブルシューティングのポイント
Hyper‑V Manager の VM コンソールで「リモート ビデオが中断されました（Video remoting was disconnected）」と表示される問題は、原因さえ整理してしまえば、比較的パターン化されたトラブルです。本記事の内容を振り返ると、ポイントは次の通りです。
- ホストへの接続や VM の電源操作ができる場合でも、VM コンソール用のビデオチャネル（TCP 2179）が別に存在する
- 最も多い原因は TCP 2179 のブロックであり、Windows ファイアウォールだけでなく、VPN・境界 FW・EDR の影響も疑うべき
- ポートが通っているのにダメな場合は、CredSSP による資格情報委任や Hyper‑V Administrators グループの権限を確認する
- イベントログ（Hyper‑V‑VMMS / Hyper‑V‑Worker）を確認し、認証エラーか通信断かを切り分けると効率的
- クイックテスト（
Test-NetConnection、vmconnect.exe localhost）を活用することで、ネットワーク／ホスト／クライアントのどこに問題があるかを素早く絞り込める - CredSSP は便利だが、委任先の範囲を最小限にし、不要になったら無効化するなど、セキュリティ面にも配慮する
この流れに沿って確認していけば、ほとんどの「リモート ビデオが中断されました」問題は解決に導けます。特に、Hyper‑V をリモート拠点やクラウド上で運用している場合は、構築フェーズの段階であらかじめ TCP 2179 の開放と認証委任の方針を設計に組み込んでおくと、後々のトラブルを大きく減らすことができます。
今まさに同じ症状に悩まされている方は、本記事の手順に沿って、(1) 2179/TCP の開放 → (2) CredSSP による資格情報委任 → (3) 権限とログの確認の順で切り分けを進めてみてください。
コメント