Hyper-V Server 2016（Core）をWindows 10のHyper-V マネージャーからリモート管理していると、［仮想マシンのインポート］でローカルPCのフォルダーを選べず「リモート コンピューターに接続している場合、このユーザー インターフェイスからローカル ファイル システムを参照できません」と表示されることがあります。原因は設定ではなく“仕様”で、解決の近道はホストが読める場所（ローカル or UNC共有）にVMファイルを置くことです。
症状：リモート接続時にローカルPCのパスが選べない
この問題は、次のような構成でよく発生します。
- Hyper-V Server 2016（GUIなし／Server Core相当）を複数台運用している
- 管理端末はWindows 10で、Hyper-V マネージャー（virtmgmt.msc）から各ホストへリモート接続している
- 管理端末のローカルにある.vhdx、またはエクスポート済みVMフォルダー一式を使い、リモートホスト上で［仮想マシンのインポート］を実行したい
ところがインポートウィザードの参照画面でローカルPCを見ようとすると、次のメッセージが出て先へ進めません。
リモート コンピューターに接続している場合、このユーザー インターフェイスからローカル ファイル システムを参照できません
ドメイン管理者権限で実行しても改善しないため、GPOや権限設定を疑いがちですが、まず押さえるべきポイントは「インポート処理はどこで実行されているか」です。
結論：これは仕様（制限）で、GPOのせいではない
Hyper-V マネージャーでリモートのHyper-Vホストに接続している場合、［仮想マシンのインポート］の実体は接続先ホスト側で実行されます。つまり、ウィザード画面は手元のPCで表示されていても、ファイル参照の“基準”はリモートホストです。
そのため、インポート元として選べるのはホストから到達できる場所に限られます。管理端末のローカルディスク（C:やD:など）は、ホストから見れば別PCのローカルであり、ウィザードの設計上、そのまま参照する機能がありません。
| インポート元として指定できる場所 | 指定可否 | 理由／補足 |
|---|---|---|
| Hyper-Vホストのローカルパス（例：D:\VMs\Import\VM1） | 〇 | ホスト自身が直接アクセスできる |
| UNC共有（例：\\fileserver\HyperV\Import\VM1） | 〇 | ホストからネットワーク経由で到達できる（権限設計が重要） |
| 管理端末のローカルパス（例：C:\Users\me\Desktop\VM1） | × | ホスト側UIでは“ローカル”ではないため参照不可（今回の制限） |
| 管理端末で割り当てたドライブレター（例：Z:） | ×（ほぼ） | ドライブマッピングは基本的に“その端末のユーザーセッション”依存で、ホストのサービスからは見えない |
要するに、このエラー自体は「乗っ取り」「ポリシーでブロック」よりも、リモート管理の設計上の制約として理解するのが正解です。
解決の基本方針：VMファイルを“ホストが読める場所”へ置く
対処はシンプルで、以下のどれかに寄せれば確実に解決します。
- （推奨）ファイルサーバー等の共有（UNC）にエクスポート済みVMを置く
- （手堅い）いったんホストのローカルディスクにコピーしてからインポートする
- （運用向け）PowerShell Remotingでコピーとインポートを完結させる
以下では、それぞれのやり方と「つまずきポイント」を具体的に解説します。
方法1：UNC共有に置いてインポートする（推奨）
複数ホストを運用しているなら、最も運用が安定するのはファイルサーバーの共有フォルダーに“インポート用置き場”を用意する方法です。管理端末→共有に配置→各ホストから参照、という流れに揃うため、作業手順がブレにくく、監査や権限管理も行いやすくなります。
手順（Hyper-V マネージャーでのインポート）
- ファイルサーバーにインポート用フォルダーを作成（例：\\fileserver\HyperV\Import）
- エクスポート済みVMフォルダー（またはVHDX）をその配下へコピー
- 管理端末のHyper-V マネージャーで対象ホストに接続
- ［操作］→［仮想マシンのインポート］→ 参照でUNCパスを指定
- インポートの種類（登録／復元／コピー）を選択し、完了
重要：共有とNTFS権限は「ユーザー」ではなく「ホスト（コンピューターアカウント）」も考慮する
ここが最もハマりやすいポイントです。Hyper-Vのインポートは、内部的にはHyper-Vの管理サービス（vmms）が処理します。vmmsは一般にLocalSystem権限で動作するため、ネットワーク共有へアクセスする際は、ユーザーの権限ではなくホストのコンピューターアカウント（例：DOMAIN\HYPERV01$）としてアクセスする場面が出てきます。
その結果、あなたがドメイン管理者であっても、共有側にホスト（またはホスト用のADグループ）が許可されていないと、インポート元の読み取りで失敗します。
| 場所 | 設定対象 | 推奨する権限の考え方 |
|---|---|---|
| インポート元（共有） | 共有権限／NTFS権限 | 少なくともホストのコンピューターアカウント（またはホスト群のグループ）に読み取り権限。エラーが出る場合は一時的に変更（運用で最小化） |
| インポート先（ホストのローカル） | NTFS権限 | 基本はデフォルトの保存先を使うか、Administrators / SYSTEMを含む通常のVM格納権限にする（過度に締めすぎない） |
管理端末のローカルを“共有”として見せるのも有効（小規模・一時対応）
専用のファイルサーバーがない場合でも、インポート対象のVMフォルダーを管理端末側で一時的に共有し、ホストから\\管理端末名\共有名として参照させれば、同じ発想で進められます。
- 例：管理端末に「VMImport$」を作り共有 → \\ADMINPC\VMImport$\VM1 を指定
- 共有の許可は、必要最小限（作業が終わったら共有を削除）
- 管理端末がスリープ／VPN切断すると作業が止まるため、恒久運用より“移行作業の一時対応”向き
方法2：いったんホストのローカルへコピーしてからインポートする（最も確実）
「共有に置いたのにアクセスできない」「ダブルホップで詰まる」「権限設計に時間をかけたくない」場合、最も確実なのはホストのローカルディスクへ先にコピーしてからインポートする方法です。インポート元がローカルになれば、ネットワーク認証要因が消え、成功率が一気に上がります。
コピーの代表例（SMBでホストへ直接コピー）
管理端末からホストの管理共有（D$など）へコピーできるなら、操作は単純です。
例：管理端末 → ホスト(HYPERV01)のDドライブへコピー
\\HYPERV01\D$\VMs\Import\VM1\ （ここへエクスポート一式を配置）大量のファイルや差分同期をしたい場合は、robocopyが安定します。
robocopy "C:\Export\VM1" "\\HYPERV01\D$\VMs\Import\VM1" /E /Z /R:1 /W:1 /COPY:DAT /DCOPY:DATコピー後のインポート手順
- Hyper-V マネージャーでホストに接続
- ［仮想マシンのインポート］で D:\VMs\Import\VM1 を指定
- インポートの種類を選び、必要に応じて保存先をホスト側で指定
ネットワーク越しに読み取りが発生しないため、“とにかく通したい”ときの最短ルートです。
方法3：PowerShellでコピー→インポートまで完結させる（自動化・再現性重視）
複数台への移行や夜間バッチなど、手作業を減らしたい場合はPowerShellが便利です。特にCopy-Item -ToSessionを使うと、ファイル共有の公開を最小限にしつつ、管理端末からホストへ安全にファイルを転送できます。
例：管理端末からリモートセッション経由でコピーし、Import-VMを実行
$session = New-PSSession -ComputerName "HYPERV01"
# エクスポートフォルダー一式をホストのローカルへ転送
Copy-Item -Path "C:\Export\VM1" -Destination "D:\VMs\Import\VM1" -ToSession $session -Recurse
# ホスト側でインポート（例：コピー＆新しいID）
Invoke-Command -Session $session -ScriptBlock {
Import-VM -Path "D:\VMs\Import\VM1" -Copy -GenerateNewId
}
Remove-PSSession $sessionポイントは、「コピー（ファイル転送）」と「インポート（実行主体）」をどちらもホスト側で完結させることです。Hyper-V マネージャーのウィザードと同じ制限（ローカル参照不可）を回避しつつ、作業手順をスクリプトとして残せます。
「共有に置いたのにアクセスできない」典型原因：ダブルホップ問題
UNC共有を指定したはずなのに、インポートが失敗したり、参照はできても途中で権限エラーになる場合、原因として最も多いのがダブルホップ問題です。
簡単に言うと、次のような“二段階の認証”が発生する構図です。
- 第1ホップ：管理端末 → Hyper-Vホスト（リモート管理の接続）
- 第2ホップ：Hyper-Vホスト → ファイルサーバー（UNC共有へのアクセス）
このとき、ホストがファイルサーバーへアクセスするための資格情報がうまく引き継げないと、アクセスが匿名になったり、意図しないアカウント（コンピューターアカウント）になって失敗します。
| 状況 | 起きやすい症状 | 現実的な回避策 |
|---|---|---|
| ウィザードでUNCを指定したら「アクセス拒否」「パスが見つからない」 | 共有が開けない／途中で失敗 | ホストのコンピューターアカウントに共有の権限を付与、または方法2でホストへコピー |
| 管理端末の共有（\\ADMINPC\Share）を使った | PCのスリープやFWで失敗 | 一時対応に留める。安定運用はファイルサーバー共有へ |
| PowerShellでホストへ接続し、さらに別サーバーへアクセス | 共有に触れた瞬間にエラー | Copy-Item -ToSessionでホストへ転送してから処理、もしくは（ポリシーに従って）CredSSP／制約付き委任 |
認証方式（Kerberos/NTLM）も地味に重要
ドメイン環境でも、接続の仕方によってはKerberosではなくNTLMになり、委任が効かずに詰まることがあります。特に次のようなケースは要注意です。
- ホスト名をIPアドレスで指定している（例：192.168.x.x）
- DNSの名前解決が不安定で、SPNが合わない
- サーバーとクライアントの時刻ズレが大きい（Kerberosは時刻差に敏感）
「共有に置いたのにダメ」な場合は、権限だけでなく接続名（FQDN）や時刻同期も合わせて見直すと、切り分けが早くなります。
どうしても「ホスト→共有」を成立させたい場合：制約付き委任とCredSSP
基本方針は「ホストが読める場所に置く（コピー／UNC）」ですが、環境によっては「管理端末からホストへ接続したまま、ホストが別サーバーの共有へ確実にアクセスできるようにしたい」という要件もあります。その場合に検討されるのがKerberosの制約付き委任やCredSSPです。
制約付き委任（Kerberos Constrained Delegation）の考え方
制約付き委任は、Active Directory上で「このホスト（HYPERV01）は、特定のサービス（例：fileserverのCIFS）に対してのみ、ユーザーの資格情報を委任してよい」という形で委任先を限定する仕組みです。無制限の委任（Unconstrained Delegation）より安全に設計できます。
- よく委任対象にするサービス：CIFS（ファイル共有）、必要に応じてHTTP/WSMANなど
- 委任が効く前提：ドメイン環境でKerberos認証になっている（IP指定やDNS不整合だと失敗しがち）
ただし、委任設定は環境全体のセキュリティ設計に関わるため、手順の丸写しよりも「要件が本当にあるか」「コピー運用で代替できないか」を先に検討するのが現実的です。
CredSSPの使いどころと注意点
CredSSPは、PowerShell Remotingなどで資格情報をリモート先へ委任できる方式です。検証や一時対応では強力ですが、資格情報の委任を許す以上、運用では取り扱いに注意が必要です（利用範囲・期間を最小化し、終わったら無効化するのが基本です）。
例として、管理端末側とホスト側でCredSSPを有効化し、CredSSPで接続してからUNCへアクセスする、という流れになります。
# 管理端末（クライアント）側：委任先ホストを許可
Enable-WSManCredSSP -Role Client -DelegateComputer "HYPERV01"
# Hyper-Vホスト側：サーバーとしてCredSSPを許可
Enable-WSManCredSSP -Role Server
# CredSSPで接続（ここから先の共有アクセスが通りやすくなる）
Enter-PSSession -ComputerName "HYPERV01" -Authentication CredSSP -Credential "DOMAIN\user"作業後は、忘れずに無効化しておくと安心です。
Disable-WSManCredSSP -Role Client
Disable-WSManCredSSP -Role Server権限で詰まりやすいポイントをもう少し具体的に
「自分がドメイン管理者」でも通らない理由
リモートのHyper-Vホストで実際に動くのは、あなたのExplorerではなくホストのサービスです。共有にアクセスする主体があなたのユーザーではないなら、どれだけ強いユーザー権限でも効果がありません。
運用でよくある落とし穴は次のとおりです。
- 共有権限は「Domain Admins」にフル、でもホスト（HYPERV01$）が無い
- NTFS権限は厳密に絞ってあり、SYSTEMやAdministratorsの継承が切れている
- インポート先フォルダーに事前に独自ACLを付け、Hyper-Vが必要なACLを設定できない
最初の移行や検証では、まずデフォルトに近いACLで成功させ、動作確認後に最小権限へ詰めていく方が安全です。
ドライブレター（Z:）が使えないのは“あるある”
「共有をZ:に割り当てているのに、インポートでは見えない」という相談も多いです。理由は単純で、ドライブレターはユーザーセッション単位の設定であり、Hyper-Vのインポートを実行するサービス（LocalSystem）からは見えません。インポート元は必ずUNC（\\server\share）で指定するのが基本です。
インポート方式（登録／復元／コピー）の選び方
Hyper-Vのインポートでは、同じファイルを取り込む場合でも“取り込み方”を選びます。ここを誤ると、重複IDや保存先の衝突で後から面倒になるため、意味を整理しておきましょう。
| 方式 | 概要 | 向いているケース | 注意点 |
|---|---|---|---|
| 登録（Register） | ファイルをその場所のまま登録し、既存IDで管理下に入れる | 同一ホストに“置き場所だけ”を戻す／一時的に登録し直す | 保存先が共有だと権限やロックで詰まりやすい。移行用途では選びにくい |
| 復元（Restore） | 元の構成に近い形で復元し、既存IDを維持する | 同一VMを同じIDで戻したい（障害復旧など） | 別ホストへ複製して同時稼働させる用途には不向き |
| コピー（Copy） | 新しい場所へコピーし、新しいIDを生成して取り込む | 別ホストへ移行／複製したい | 重複IDを避けやすく、移行作業では最も無難 |
迷ったら、移行・複製の場面では「コピー（新しいID）」が安全です。特に、元ホストに同名VMが残る可能性がある運用では、ID重複による混乱を避けられます。
VHDXしかない場合：インポートより「新規VM＋既存ディスク接続」が速いことも
エクスポート済みVM一式ではなく、ディスクファイル（.vhdx）だけを持っているケースもあります。その場合、［仮想マシンのインポート］にこだわらず、次の手順の方が早いことがあります。
- VHDXをホストが読める場所（ホストローカル or UNC）に置く
- Hyper-V マネージャーで新規仮想マシンを作成
- 「既存の仮想ハードディスクを使用する」でVHDXを指定
VMの世代（第1世代／第2世代）やSecure Boot設定、仮想スイッチ接続などは再設定が必要ですが、構成がシンプルなVMならこの方が移行がスムーズな場合もあります。
切り分けに役立つ：インポート失敗時に確認したいログ（VMMS）
インポートが途中で失敗する場合、画面上のメッセージだけでは原因が分かりにくいことがあります。そんなときは、Hyper-Vホスト側のイベントログ（VMMS）を見ると「どのパスで」「どんな権限で」失敗したかが追いやすくなります。
- イベント ビューアー：アプリケーションとサービス ログ → Microsoft → Windows → Hyper-V-VMMS → Admin
GUIが使いづらい環境では、PowerShellで直近のログを拾うのも有効です。
Get-WinEvent -LogName "Microsoft-Windows-Hyper-V-VMMS/Admin" -MaxEvents 30 |
Select-Object TimeCreated, Id, LevelDisplayName, Message| よく見る失敗の傾向 | 例 | まず疑うポイント |
|---|---|---|
| アクセス拒否 | 0x80070005 など | 共有／NTFS権限にホスト（HYPERV01$）が無い、または委任が効いていない |
| パス不正・到達不可 | 0x80070003 など | UNCのタイプミス、DNS解決、ファイアウォール、SMB（445）遮断 |
| 設定ファイルが見つからない | 構成ファイルを検出できない | 「VHDXだけ」なのにインポートしようとしている、またはエクスポート一式が欠けている |
補足：Hyper-V関連サービスが停止して見えるのは異常？
「Hyper-Vのサービスが止まっているように見える」と不安になることがありますが、サービスの中には必要時に起動（トリガー起動）するものもあり、停止＝異常とは限りません。
ただし、次のように管理経路そのものが不安定な場合は、インポート以前の設定を点検した方が早いです。
- Hyper-V マネージャーで接続が頻繁に切れる
- PowerShell Remoting（WinRM）が通らない
- SMBコピー（\\HYPERV01\D$ など）ができない
トラブル時の確認チェックリスト（最短で切り分ける）
「何を直せばいいか分からない」ときは、次の順に確認すると迷いにくくなります。
リモート管理（Hyper-V マネージャー／WinRM）
- 管理端末のユーザーがホスト側のHyper-V Administrators（またはAdministrators）に入っている
- ホストのリモート管理が有効（sconfigでRemote Managementを有効化している）
- ファイアウォールでHyper-V管理・WMI/WinRMが許可されている
ファイル配置（SMB/共有）
- インポート元はホストが到達できるUNCまたはホストローカル
- UNC共有の権限に、ユーザーだけでなくホスト（DOMAIN\HYPERV01$）またはホスト群グループが含まれている
- 共有の指定はドライブレターではなくUNCで統一している
認証（ダブルホップ回避）
- 可能なら「方法2：ホストへコピー」で切り分ける（共有由来の失敗を消す）
- ホスト名はIPではなくFQDNで接続する（Kerberosになりやすい）
- ドメイン時刻同期が崩れていない（特に仮想環境での時刻ズレ）
まとめ：このエラーは仕様。解決は「配置」と「権限」をホスト目線で整える
Hyper-V Server 2016をリモート管理しているときに「ローカル ファイル システムを参照できません」と出るのは、設定ミスではなくリモート管理時の仕様（制限）です。対処は、インポート元をホストが読める場所（ホストローカル or UNC共有）に置くこと。さらに、共有を使うならホストのコンピューターアカウントやダブルホップを意識して権限設計を行うと、移行作業が安定します。
最短で成功させるなら「ホストへコピーしてからインポート」。運用を整えるなら「ファイルサーバー共有＋ホスト権限」。この二本柱で考えると、同じトラブルに何度も悩まされずに済みます。
コメント