Windows Server 2016 Standard評価版（Server Core）でHyper-Vホストを作ってしまい、評価期限切れでホストが自動シャットダウンする…。再インストールせずにHyper-V Server 2016へ“変換”できるのか、結論と、現実的に安全な移行手順・落とし穴をまとめます。
起きている問題：評価期限切れでホストが落ちると、VM全体が巻き込まれる
Windows Serverの評価版は期限が切れると、警告が出るだけでなく、一定間隔で強制シャットダウンが発生しやすくなります。VMホストでこれが起きると、ゲストOSが何台あってもまとめて停止し、業務影響が大きくなりがちです。
再アーム（rearm）で延命できても、それは「一時しのぎ」です。延命回数や状態は環境で差が出るため、恒久対策（ライセンスで正す／ホストを作り直す）を前提に動くのが安全です。
まず押さえる前提：Server Coreの話と、Hyper-V Serverの話は別物
混同されやすいポイントですが、次の2つはまったく別の概念です。
- Server Core / Desktop Experience：Windows Serverの「インストールオプション（UIの有無）」
- Windows Server / Hyper-V Server：そもそも「製品（SKU）」が違う
「GUIなし（Server Core）で作った＝Hyper-V Serverっぽいから、同じように切り替えできそう」と見えますが、実際は別製品です。Windows Server内の機能追加・削除で切り替える話ではありません。
結論：Windows Server 2016（Core含む）からHyper-V Server 2016へ“変換”する正式手段はない
Windows Server 2016 Standard（評価版/製品版、Server Core含む）を、インプレースでHyper-V Server 2016へ切り替える（ライセンス/エディション変更のように変換する）ことはできません。
理由はシンプルで、Hyper-V ServerはWindows Serverの「エディション違い」ではなく、別SKUとして提供される独立製品だからです。インプレース移行経路が用意されていないものは、基本的に“変換”ではなく「入れ替え（再インストール）」になります。
現実的な恒久対策は2つ：どちらが得かは“目的”で決まる
やるべきことは大きく2択です。どちらを選ぶべきかは、コストだけでなく、運用・ライセンス・将来計画まで含めて決めると失敗しにくいです。
| 選択肢 | やること | 向いているケース | 注意点 |
|---|---|---|---|
| Windows Serverのまま正す | 評価版をやめ、正規キーでStandardとしてライセンス認証（必要なら評価版→製品版へ切替） | ホスト再構築の手間を最小化したい／Windows Serverの仮想化権利も含めて考えたい | キーやライセンス体系（コア数・ゲスト権利）を正しく満たす必要がある |
| Hyper-V Serverへ入れ替える | VMをExportして退避 → Hyper-V Server 2016をクリーンインストール → VMをImport | ホストを軽量にしたい／Hyper-V専用ホストに割り切りたい | 再インストール前提。ゲストOSのライセンスは別途必要（無料＝何でも無料ではない） |
質問の主旨が「Hyper-V Serverに切り替えたい」なので、この記事の中心は入れ替え（Export/Import）ですが、最短で止血したいなら“Windows Serverのまま正しくライセンス認証して使い続ける”選択肢も現実解です。環境によっては、こちらのほうがダウンタイムもリスクも小さくなります。
選択肢A：Windows Server 2016 Standardとして継続（評価版問題だけ解消する）
「Hyper-V Serverに切り替える」ことが目的ではなく、「評価期限切れのシャットダウンを止めたい」が目的なら、まずはこの選択肢を検討する価値があります。
ポイント：評価版の状態と、切り替え可能なエディションを確認する
環境によっては、評価版（ServerStandardEvalなど）から製品版（ServerStandard）へ切り替え可能です。まずは現状を確認します。
コマンド例（PowerShell）
DISM /Online /Get-CurrentEdition
DISM /Online /Get-TargetEditionsコマンド例（GUIなしでも実行できる確認）
systeminfo切り替えが可能なら、正規のプロダクトキーを使ってエディション変更＋認証を行います（環境要件により手順が異なるため、社内のライセンス管理・ボリュームライセンス運用の方針に従ってください）。
一般的なイメージ（例）
DISM /Online /Set-Edition:ServerStandard /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEulaこの方法が成立するなら、ホスト再インストールが不要になり、仮想スイッチやNIC設定、ストレージ構成など「ホスト依存の復旧作業」が大幅に減ります。
注意：評価版→製品版の切り替え可否や、切り替え先のエディションは、現在の状態やメディア、適用済み更新、役割・機能の状況で変わることがあります。実施前に必ずバックアップを取り、検証環境で試せるなら先に試すのが安全です。
選択肢B：Hyper-V Server 2016へ入れ替え（Export → 再インストール → Import）
ここからが本題です。“変換”はできないが、VM移行は十分現実的です。Hyper-VのExport/Importは業務でよく使われる標準機能で、ポイントを押さえれば移行成功率は高いです。
最初に整理：Export/Importで「何が移る」のか
| 項目 | Export/Importで引き継がれやすい | 引き継がれない／作り直しが必要になりやすい |
|---|---|---|
| VM本体（構成） | CPU/メモリ設定、仮想ディスク、チェックポイント（含める設定次第） | ホスト固有のパス依存設定がある場合は調整が必要 |
| ネットワーク | VMのNIC設定自体は移る | 接続先vSwitchはホスト側に存在しないと切断状態になりやすい |
| ホスト設定 | 基本的に移らない | vSwitch、NIC Teaming、VLAN、IP、ドライバ、更新、監視、バックアップ連携 |
つまり、移行をスムーズにするコツは「VMを動かすために必要なホスト側の前提条件（特にネットワーク）を、先に再現する」ことです。
移行前にやること：失敗を減らす“控えるべき情報”チェックリスト
移行作業そのものよりも、事前のメモが勝負です。特にネットワークで詰まるケースが多いので、以下を控えておきます。
| 控えるもの | 具体例 | 控える理由 |
|---|---|---|
| vSwitch名と種類 | External / Internal / Private、どのNICに紐づくか | Import後にVM NICが正しく接続されない原因になりやすい |
| VLAN設定 | アクセスVLAN、トランク、許可VLAN一覧 | 疎通しない原因が“設定忘れ”になりがち |
| NIC Teaming | チーム名、メンバーNIC、LACP/静的、負荷分散方式 | ホスト再構築時に同じ構成を再現するため |
| VMの配置先 | VHDXの保存先、VM構成ファイルの保存先 | Import時のパス不一致や容量不足を防ぐ |
| 固定MAC/予約 | VM側で固定MAC、DHCP予約、FWホワイトリスト | MACが変わると通信や認証が崩れることがある |
| 仮想化機能の特殊設定 | Nested Virtualization、SR-IOV、GPU割り当て等 | ホスト側要件が変わると動作しない場合がある |
可能なら、現行ホストで以下のような“棚卸しコマンド”を実行して、出力をファイル保存しておくと復旧が速くなります。
# vSwitch一覧
Get-VMSwitch
# VMとNIC接続先（SwitchName確認）
Get-VMNetworkAdapter -VMName * | Select VMName, Name, SwitchName, MacAddress, DynamicMacAddress
# VLAN設定（VMごと）
Get-VMNetworkAdapterVlan -VMName *
# Hyper-Vホストの一般情報
Get-VMHostVMのExport：まずは“退避が本当に取れたか”まで確認する
ExportはGUIでもPowerShellでもできます。複数VMがある場合、PowerShellで一括退避すると漏れが減ります。
推奨方針：基本は停止（シャットダウン）してからExport
Hyper-Vには稼働中のエクスポートもありますが、評価期限が絡んでホストが落ちる状況では、メンテナンス時間を確保してVMを計画停止→Exportのほうがトラブルが少ないです。特にDBやトランザクションが絡むVMがあるなら、停止Exportが安心です。
PowerShellで一括Exportする例
退避先は、別ディスク（外付け・別LUN・NASなど）を推奨します。同一ディスクに置くと、再インストールやディスク障害時に共倒れします。
# 退避先フォルダ（例）
$exportRoot = "D:\HV_Export"
# 念のため作成
New-Item -ItemType Directory -Path $exportRoot -Force | Out-Null
# すべてのVMをエクスポート
Get-VM | Export-VM -Path $exportRootエクスポート後は「フォルダサイズが想定通りか」「VMごとのエクスポートが揃っているか」を確認してください。容量不足やアクセス権で一部VMだけ失敗しているケースは意外とあります。
チェックポイント（スナップショット）が多い場合の注意
チェックポイントが大量に残っていると、エクスポートが肥大化し、復元時間も伸びます。運用上不要なチェックポイントは整理した上でExportするのが無難です（ただし、安易に削除せず、影響を理解した上で実施してください）。
Hyper-V Server 2016の再インストール：入れ替え作業で詰まりやすいポイント
Hyper-V Serverは軽量で良い反面、導入直後は「最低限の設定」しか入っていません。再インストール後に慌てないよう、やることを先に並べておきます。
セットアップ直後に行う代表的な設定
- IPアドレス、DNS、デフォルトゲートウェイ（固定IP運用なら必須）
- ホスト名の変更（管理や監視があるなら重要）
- ドメイン参加（必要な運用の場合）
- リモート管理の有効化（別PCからHyper-V ManagerやPowerShellで管理する前提）
- Windows Update方針、時刻同期、ドライバ適用
Hyper-V Serverは、初期設定ツール（sconfig）でまとめて設定できるため、まずはsconfigでネットワークとリモート管理を整えるのが定石です。
ネットワーク再現が最重要：vSwitch名を合わせると移行がラクになる
Import後のVMは、以前接続していたvSwitch名を覚えています。新ホストに同名のvSwitchが存在しないと、VMのNICが「未接続」になり、ゲストがネットワーク不通になります。
そのため、可能なら旧ホストと同じvSwitch名で作っておくと、Import直後から疎通しやすくなります。
# vSwitch作成例（外部スイッチ）
New-VMSwitch -Name "vSwitch-External" -NetAdapterName "Ethernet0" -AllowManagementOS $trueVLAN運用の場合は、ホスト側（物理スイッチ）とHyper-V側（vSwitch/VM NIC）の両方の整合が必要です。設定忘れの検知が遅れると「VMは起動するのに通信だけできない」状態になり、切り分けに時間を取られます。
VMのImport：3つの取り込み方式を理解すると事故が減る
Hyper-VのImportは、同じ“インポート”でも選択肢が複数あります。特にVM IDの扱いが変わるため、目的に合わせて選びます。
| 方式（呼び方） | イメージ | 向いているケース | 注意点 |
|---|---|---|---|
| そのまま登録 | Exportした場所のファイルを参照して登録 | ストレージ配置を変えない／検証用途 | Exportフォルダを移動すると壊れやすい |
| 復元 | 指定した場所へ展開して登録 | 本番移行で一般的 | 展開先の容量・パス設計が重要 |
| コピー（新しいIDを生成） | クローンとして取り込む | 旧ホストを残したまま並行稼働したい | VM IDやMACが変わる前提で、DHCP予約やFWを調整 |
今回のように「旧ホストを置き換える」なら、まずは復元（Restore）が無難です。旧ホストを残して並行運用する期間があるなら、ID重複を避けるために“コピー（新しいID）”が安全です。
PowerShellでImportする例（代表例）
実際のパスはエクスポート先に合わせて置き換えてください。
# 例：復元として取り込み（ファイルを指定フォルダへ配置）
Import-VM -Path "D:\HV_Export\VM01\Virtual Machines\xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.vmcx" -Copy -GenerateNewId上の例は「Copy + GenerateNewId」なのでクローン作成向けです。旧ホストを完全に廃止してIDを維持したい場合は、GUIのImportウィザードで“新しい一意のIDを生成しない”選択をする運用もあります（ただし、並行稼働すると衝突し得るため、切替計画に合わせて選びます）。
Import後に必ずやる：NICの接続先（vSwitch）を確認する
Importが成功しても、NICが未接続なら通信はできません。以下を確認します。
- VMのNICが正しいvSwitchに接続されているか
- VLANが必要なVMはVLAN設定が入っているか
- 固定MACを前提にしている場合、MACが変わっていないか
# VMのNIC接続先を一覧で確認
Get-VMNetworkAdapter -VMName * | Select VMName, SwitchName, MacAddress, DynamicMacAddress移行後の動作確認：起動した“だけ”で終わらせない
VMが起動してログインできても、運用上はまだ不十分なことがあります。最低限、次の観点で確認しておくと安心です。
| 確認項目 | 見るべきポイント | 見落としがちな原因 |
|---|---|---|
| ネットワーク疎通 | 同一セグメント内、ルーティング越し、名前解決（DNS） | VLAN未設定、vSwitch未接続、物理側ポート設定違い |
| ディスクI/O | アプリの反応、ログの遅延、イベントログ | ストレージパス違い、アンチウイルス/監視の影響 |
| 時刻 | NTP同期、ドメイン環境での時刻ずれ | ホストの時刻設定、ゲスト側同期設定の不整合 |
| バックアップ | バックアップソフトがホスト変更を検知しているか | ホスト名変更、証明書/認証、エージェント設定 |
| 自動起動/停止 | ホスト起動時に必要VMが上がるか | 自動開始設定が初期化、依存VMの順序 |
よくあるトラブル集：詰まりどころは“ネットワーク”と“パス”
Hyper-Vの移行で発生しやすいトラブルと、現場での対処方針をまとめます。
| 症状 | 原因の候補 | 対処の方向性 |
|---|---|---|
| VMは起動するがネットが一切つながらない | vSwitch未接続、vSwitch名不一致、VLAN設定漏れ | VM NICのSwitchNameを確認し、同名vSwitch作成か接続先変更。VLANも再設定 |
| Import時に仮想ディスクが見つからないと言われる | VHD/VHDXの配置が変わった、パスがずれた | Importウィザードでパスを再指定、または構成ファイルの参照先を修正 |
| DHCP予約やFWルールが効かなくなった | MACアドレスが変わった（コピー/新ID生成時など） | MACを固定に戻す、または予約・ルール側を更新 |
| リモート管理できない | WinRM/ファイアウォール、名前解決、ドメイン参加未完 | sconfigでリモート管理有効化、FW確認、DNS/ドメイン状態の確認 |
| パフォーマンスが落ちた | ドライバ、NIC設定、ストレージ設定、電源プラン | メーカー推奨ドライバ適用、NICオフロード、ストレージ最適化、ログで原因追跡 |
移行を成功させるための現場のコツ
最後に、手順書には書きづらい“事故を減らすコツ”をまとめます。小規模でも効果が大きいポイントです。
- 退避先は別媒体にする（同一ディスクにExportして再インストールで消す事故が本当に多い）
- vSwitch名を旧ホストに寄せる（Import後のネットワーク復旧が一気に楽になる）
- 並行稼働があり得るなら新ID生成を選ぶ（VM ID衝突の地雷を踏まない）
- 移行当日に慌てないために、棚卸し結果をテキストで保存（スイッチ、VLAN、MAC、パス）
- 重要VMは最初に1台だけImportして疎通確認し、型が固まってから一括移行する
まとめ：変換にこだわるより「止血」と「安全移行」を最優先にする
Windows Server 2016（Server Core含む）からHyper-V Server 2016へ、OSのエディション変更のように“変換”する手段はありません。ここを探し続けるより、現実的には次のどちらかで早めに決着を付けるのが安全です。
- ホストをWindows Server 2016 Standardとして正規に認証して継続（再構築を避けたい・最短で止血したい場合）
- VMをExport → ホストをHyper-V Server 2016で再インストール → VMをImport（専用ホストに割り切りたい場合）
特に後者は「再インストールが必須」というだけで、VM移行自体は標準機能で十分成立します。ネットワーク（vSwitch名/VLAN/チーミング）と、ストレージパスを事前に押さえれば、移行の不安はかなり減らせます。
コメント