Windows Server 2016から2019へインプレースアップグレードできない原因と対策｜「個人用ファイルとアプリを引き継ぐ」がグレーアウトする

Windows Server 2016からWindows Server 2019へインプレースアップグレードしようとすると、「個人用ファイルとアプリを引き継ぐ」がグレーアウトして「何もしない」しか選べないことがあります。本記事ではこの現象が起きる典型原因と、失敗しにくい移行・アップグレード手順を具体的に整理します。

症状：Windows Server 2016→2019のアップグレードで「引き継ぐ」が選べない

Windows Server 2019のセットアップを起動し、「引き継ぐものを選ぶ」画面まで進むと、本来であれば次のような選択肢が表示されます。

• 個人用ファイルとアプリを引き継ぐ（アプリ・設定・データを保持）
• 個人用ファイルのみを引き継ぐ（データのみ保持）
• 何もしない（Nothing）（クリーンインストール相当）

ところが環境によっては、「個人用ファイルとアプリを引き継ぐ」や「個人用ファイルのみを引き継ぐ」がグレーアウトし、「何もしない」しか選べない状態になります。この状態のまま進めると、アプリや設定を維持した移行はできません。

まず押さえる前提：ブート起動でのアップグレードは基本「引き継ぎ不可」

ISOから起動してインストールを開始した場合、セットアップは「新規インストール（クリーン）」の流れになりやすく、引き継ぎ項目が出ない／制限されることがあります。アプリや設定を保持したいインプレースアップグレードは、原則としてWindows Server 2016を起動した状態で、ISOのルートにあるsetup.exeを実行して開始します。

ただし「OS上からsetup.exeを実行してもグレーアウトする」場合は、次の章で解説する“現在のOSとインストールメディアの不一致”が原因になっていることが多いです。

なぜ「個人用ファイルとアプリを引き継ぐ」がグレーアウトするのか

セットアップが引き継ぎを許可するかどうかは、互換性チェックで決まります。ポイントはシンプルで、インストールしようとしているWindows Server 2019の内容が、現在稼働しているWindows Server 2016と“同系統”であることです。条件が合わないと、引き継ぎを行う前提が崩れるため「Nothing」固定になります。

よくある不一致	典型的な状況	結果	現実的な対処
エディション不一致	2016 Standardに2019 Datacenter媒体／その逆など	引き継ぎ不可になりやすい	同一エディションの媒体を用意（必要なら事前にエディション変更を検討）
インストールオプション不一致	2016がServer Coreなのに2019 Desktop Experienceで入れようとする（または逆）	引き継ぎ不可	Core→Core、GUI→GUIで揃える（後から相互変換はできない）
言語不一致	2016が日本語、2019が英語（または多言語ISOの選択ミス）	引き継ぎ不可	同一言語のISOを使う
ライセンスチャネル／評価版の影響	Evaluation版メディア／Evaluation版OSの組み合わせ	引き継ぎが制限される例がある	正規メディアを用意、または評価版を変換してから実施
製品種別の取り違え	Hyper-V Server（無償版）をWindows Serverと同じ感覚でアップグレードしようとする	期待通りに進まない	製品種別を確認し、原則は新規構築＋移行

つまり、グレーアウトは「壊れている」というより“条件が合っていないので保持を許可できない”というサインです。原因を特定せずに繰り返し実行しても改善しづらいため、次章のチェックリストで一気に潰していくのが近道です。

推奨：新規インストール＋移行が安全な理由

サーバー用途では、結論としてWindows Server 2019をクリーンインストールして役割（Roles）とアプリケーションを移行するのが最も安全で確実です。インプレースアップグレードは成功すれば速い一方、失敗した時の影響が大きく、復旧が難航しがちです。

• ロールバックしやすい：新サーバーを作って並走できるため、問題が出たら切り戻しが容易。
• 障害ドメインを分離できる：OS、ドライバ、ミドルウェア、設定の“積み重なり”をリセットできる。
• 移行計画が立てやすい：停止時間（ダウンタイム）を短く設計しやすい。
• セキュリティ上も有利：不要なサービスや古いコンポーネントを抱えにくい。

特に次のようなサーバーは、インプレースよりも新規構築＋移行が向きます。

• ドメインコントローラー（AD DS）
• ファイルサーバー（共有が多い、ACLが複雑、容量が大きい）
• Hyper-Vホスト（特にクラスター）
• 基幹アプリが載っていて、失敗の許容度が低い

新規構築＋移行の全体像

「新規構築」といっても、闇雲に作り直すのではなく、移行対象の役割ごとに定石があります。代表例をまとめると次の通りです。

役割／用途	移行の定石	ポイント
AD DS（ドメインコントローラー）	新2019を追加→レプリケーション→FSMO移行→旧2016を降格	インプレースで上げるより安全。DNS/GCの扱いを計画
ファイルサーバー	Storage Migration Service／Robocopy／DFS-R等	共有権限とNTFS ACLの保持、切替時の名前/IPの設計が鍵
DHCP	エクスポート→インポート	スコープ、予約、オプションを確実に引き継ぐ
IIS	設定のエクスポート、アプリの再配置、証明書移行	アプリ依存（.NET/ランタイム/URL Rewrite等）の棚卸しが重要
業務アプリ／DB	ベンダー手順に従い新環境へ再構築	サポート範囲（OS対応）を最優先。アップグレードより再配置が安全

どうしてもインプレースアップグレードしたい場合のチェックリスト

「短時間で終わらせたい」「アプリの再構築が現実的でない」などの理由で、インプレースアップグレードを選ぶこともあります。その場合は、事前に“保持できる条件”を満たしているかを確認してください。ここを飛ばすと、グレーアウトで詰むか、無理に進めて不具合を抱えます。

チェック項目	確認方法（例）	NG例	対処方針
現在のOSが本当にWindows Server 2016か	winver systeminfo | findstr /B /C:"OS 名" /C:"OS Name"	「Windows Server, version 1709」など別系統だった	サポートされるアップグレード経路を確認し、基本は新規構築へ
エディション一致（Standard/Datacenterなど）	DISM /Online /Get-CurrentEdition	ServerStandardとServerDatacenterが混在	同一エディション媒体を使用。必要なら事前にエディション変更を検討
評価版（Eval）かどうか	DISM /Online /Get-CurrentEdition slmgr /dlv	ServerStandardEvalなどEvaluation	正規版へ変換してから実施、または正規メディアで検証
言語一致	DISM /Online /Get-Intl	2016がja-JP、2019媒体がen-US	同一言語ISOを使用（多言語ISOでも選択ミスに注意）
Server Core / Desktop Experience一致	systeminfo | findstr /B /C:"OS 名" /C:"OS Name"	Core→GUI（またはGUI→Core）へ変更しようとしている	同じインストールオプションで揃える（相互変換不可）
実行方法	2016起動後にISOをマウントし、ルートのsetup.exe	ISOブートから開始	必ずOS上から開始（保持したいなら原則これ）
空き容量	エクスプローラー／fsutil volume diskfree c:	Cドライブが逼迫	目安として数十GB以上の余裕を確保（ログ・一時領域に使う）
バックアップと復旧手段	フルバックアップ／VMスナップショット／ベアメタル復旧	「うまくいかなかったら戻せない」	バックアップが取れないならインプレースは避ける

確認コマンド早見表

切り分けを早く終わらせるために、「どのコマンドが何を示すのか」を表にまとめます。監査メモとしても便利です。

目的	コマンド例	見てほしい結果
OSのバージョン確認	winver	Windows Server 2016 / バージョン1607相当であること
OS名・インストール種別の確認	systeminfo | findstr /B /C:"OS 名" /C:"OS Name"	Server Coreか、Desktop Experienceかの推測材料
現在のエディション確認	DISM /Online /Get-CurrentEdition	ServerStandard / ServerDatacenter / （Evalなら～Eval）
言語・ロケール確認	DISM /Online /Get-Intl	ja-JPなど。ISO側と揃える
ライセンス状態確認	slmgr /dlv	評価版（TIMEBASED_EVAL）かどうか

事前準備：失敗を致命傷にしないためのバックアップと保全

インプレースアップグレードは「OS自体を上書きする作業」です。成功率を上げる以前に、失敗しても復旧できる状態にしてから着手してください。やっておくべき保全をまとめます。

やること	目的	実務上のコツ
フルバックアップ（ベアメタル）	最悪でも元に戻す	バックアップから起動できる手順まで事前に確認
VMならスナップショット	短時間で切り戻す	スナップショットの保管期間・容量に注意
役割・設定の棚卸し	移行/復旧の設計に使う	インストール済みロール、共有、証明書、タスク、サービスを記録
アプリのインストーラ/ライセンス確認	再インストールに備える	「もしクリーンになる」前提で資材を揃える
メンテナンス時間の確保	想定外の延長に備える	再起動が複数回発生。停止影響の調整が重要

手順：OS上からsetup.exeでインプレースアップグレードを実行する

条件が揃っている前提で、実施手順の流れを整理します。細部は環境差がありますが、基本の型を守るだけでも事故が減ります。

1. Windows Server 2016に最新の更新プログラムを適用（可能な範囲で）し、再起動まで完了させます。
2. サードパーティ製のウイルス対策やバックアップ常駐ソフトがある場合、ベンダー推奨に従って一時停止／アンインストールを検討します（アップグレードを妨げることがあります）。
3. Windows Server 2019のISOをマウントし、ルートのsetup.exeを右クリックで管理者実行します。
4. 「更新プログラム、ドライバー、オプション機能をダウンロードしますか？」では、原則としてダウンロードするを選ぶと成功率が上がりやすいです（オフライン要件がある場合は例外）。
5. プロダクトキー入力が求められる場合は、契約形態に応じて入力します。
6. 「引き継ぐものを選ぶ」で「個人用ファイルとアプリを引き継ぐ」が選択可能になっていることを確認します。
7. 互換性チェックの警告が出たら、内容を読み、該当コンポーネントを外す／更新する／停止するなど対処します。
8. 開始後は自動で複数回再起動します。ログオンできたら、イベントログやアプリ動作を確認します。

アップグレード後に必ず行う動作確認

インプレースアップグレードが完了してログオンできても、運用開始前に確認しておくべき項目があります。特にサーバーは「起動した＝完了」ではなく、役割やアプリが想定通り動くかがゴールです。

確認項目	見るポイント	具体例
イベントログ	失敗・警告が大量に出ていないか	システム/アプリケーションの重大エラー、ドライバ関連の警告
サービス/スケジュール	自動起動が落ちていないか	業務サービス、バックアップ、監視エージェント、タスクスケジューラ
ネットワーク	IP/DNS/ルーティングが意図通りか	固定IP、DNSサーバー、NICチーミング、VLAN、FWポリシー
役割（Roles）	ロールごとの健全性	AD/DNS/DHCP/IIS/ファイル共有、管理ツールの動作
アクティベーション	ライセンス状態が正常か	slmgr /dlvで認証済みか確認
バックアップ	バックアップが動くか	ジョブの再登録、VSS連携、世代管理の確認

この流れで「引き継ぐ」が選べない場合、次の切り分けに進みます。

それでもグレーアウトする場合の具体的な切り分け

現在のOSのエディションと評価版状態を確認する

インプレースの可否は、現在のOSがどのエディションとして認識されているかに強く依存します。まずはここを確定させます。

DISM /Online /Get-CurrentEdition
DISM /Online /Get-TargetEditions
slmgr /dlv

表示例として、評価版の場合は ServerStandardEval のような表記が出ることがあります。評価版のままアップグレードを狙うと、媒体やキーの組み合わせによって引き継ぎが許可されないケースがあります。

もし評価版から正規版へ切り替えたい場合は、まず同一メジャーバージョン内でエディション変換を行い、その後にバージョンアップグレードを検討します（手順は契約形態・キー種別で変わるため、実施前に十分な検証が必要です）。

インストールメディア側が「何のISO」なのかを確認する

ISOを入手した経路（評価版ダウンロード、ボリュームライセンス、サブスクリプション等）により、含まれるイメージや選択肢が異なることがあります。ISOの中身（install.wim / install.esd）に含まれるエディションを確認すると、ミスマッチが見つかることがあります。

D:
dism /Get-WimInfo /WimFile:D:\sources\install.wim

ここで表示されるインデックスに、目的のエディション（Standard/Datacenter等）やインストールオプション（Core/GUI）が含まれているか確認します。含まれていないISOでは、どれだけ頑張っても「引き継ぐ」は選べません。

言語の一致を確認する

言語が一致しない場合、アップグレード自体は進められても引き継ぎが制限されることがあります。まず現行OSの言語を確認します。

DISM /Online /Get-Intl

続いて、ISOが多言語の場合は、セットアップ中の選択（表示言語／地域）を誤ると不一致扱いになります。「2016は日本語なのに、2019セットアップは英語で進んでいる」といった状態は要注意です。

Server CoreとDesktop Experienceの一致を確認する

Windows Server 2016/2019では、Server CoreとDesktop Experience（GUI）は後から切り替えできません。そのため、Coreで運用しているサーバーをGUI版ISOで上げようとすると、保持ができず「Nothing」固定になりやすいです。

見分けとしては、systeminfoのOS名に「Server Core」と出る環境や、GUIが存在しない環境はCoreです。アップグレードするなら、ターゲットもCoreで揃える必要があります。

「インプレースが危険」な役割が入っていないか確認する

グレーアウトの直接原因は“ミスマッチ”であることが多いですが、仮に引き継ぎが選べても、役割によってはインプレースを避けた方がよい場合があります。代表例を挙げます。

• ドメインコントローラー：ADはレプリケーションという安全な移行手段があるため、新2019 DCを追加する移行が堅いです。
• Hyper-Vホスト（特にクラスター）：ホスト側のドライバやクラスタ要件が絡みやすく、計画的なローリングアップグレードや新ホスト移行が推奨されます。
• ストレージ／バックアップ製品が深く入っている：フィルタドライバ系はアップグレード失敗の原因になりやすいです。

「保持が選べる＝安全に上がる」ではありません。サーバーの役割と許容停止時間を基準に、移行方式を選ぶのが現実的です。

移行パターン別：新規インストール＋移行の実践例

ここからは、インプレースを避ける場合に役立つ“移行の型”を紹介します。2019の機能も活用しながら、手戻りを減らすのが狙いです。

ファイルサーバー移行：Storage Migration Service／Robocopyの使い分け

ファイルサーバーは「データだけ」ではなく、共有名、共有権限、NTFSアクセス権、ローカルユーザー、パスなど、周辺要素が多いのが難所です。代表的な移行手段を比較します。

手段	向いているケース	メリット	注意点
Storage Migration Service	旧サーバーの共有を“丸ごと”新サーバーへ寄せたい	共有/ACL/ローカルユーザー移行をまとめて扱いやすい	前提要件があるため検証必須。運用手順を固めてから本番へ
Robocopy	データコピーを確実に制御したい	オプションでACL保持、差分コピーが可能。ログも取りやすい	共有設定やローカルユーザーは別途移行が必要
DFS名前空間／DFS-R	切替時にパスを変えたくない、段階的に移行したい	段階移行・冗長化に向く	設計が必要。容量と回線により同期に時間がかかる

Robocopyの例（ACL保持・ミラー）としては次のような形が定番です。環境により最適値は変わるため、まずはテストコピーでログを確認してください。

robocopy \\oldserver\share D:\share /MIR /COPY:DATSOU /DCOPY:DAT /R:2 /W:5 /MT:16 /LOG:D:\robocopy.log

AD DS移行：新DC追加→FSMO移行→旧DC降格

ドメインコントローラーは、インプレースで上げるよりも新しいOSのDCを追加して役割を移す方が、設計上の安全性が高いです。大まかな流れは次の通りです。

1. Windows Server 2019を新規構築し、ドメインに参加。
2. AD DSロールを追加し、新DCとして昇格（DNS/GCの要件を満たす）。
3. レプリケーションが正常であることを確認。
4. FSMO役割を新DCへ移行。
5. 旧2016 DCを降格し、必要なら撤去。

この方法なら、途中で問題が起きても旧DCが生きているため切り戻しが容易です。

DHCP移行：エクスポート／インポートで短時間に切替

DHCPは、スコープや予約が多いと手作業は危険です。一般的にはエクスポート／インポートで移行します。切替の瞬間は一時停止時間が必要なので、クライアント影響が少ない時間帯を選びます。

判断基準：インプレースで行くか、新規インストール＋移行で行くか

「どちらが正しいか」ではなく、サーバーの役割とリスク許容度で選ぶのが現実解です。判断の目安を表にまとめます。

観点	インプレースアップグレード	新規インストール＋移行
作業時間	短く見積もりやすいが、失敗時に延びやすい	構築期間は必要だが、切替自体は短時間に設計しやすい
リスク	失敗時の影響が大きい（復旧が難航しやすい）	並走できるため切り戻しが容易
アプリ互換	“動いていたものが動かない”が起きやすい	新環境で検証しながら進められる
構成の整理	過去の積み重なりを抱えやすい	不要な設定やサービスを整理できる
おすすめ度	条件が揃い、停止が許容できる場合のみ	原則こちらが堅い

よくある質問

Q. ISOから起動しても、OS上からsetup.exeを実行しても、引き継ぎがグレーアウトします。最初に疑うべきは？

A. まずはエディション（Standard/Datacenter）・言語・Core/GUI・評価版の4点です。特に評価版（Eval）や、Core/GUIの取り違えは「Nothing」固定になりやすい典型パターンです。

Q. 2016 Standardから2019 Datacenterにしたいのですが、引き継ぎできますか？

A. 変更したい“方向”やメディアにより挙動が変わることがあるため、安易に本番で実施せず、まずは検証環境で確認してください。確実性を求めるなら、同一エディションでインプレースするか、新規構築＋移行でDatacenterへ構築する方が安全です。

Q. アプリも設定も丸ごと移行したいのですが、インプレース以外に方法はありますか？

A. 役割によっては“丸ごと”に近い移行が可能です。例えばファイルサーバーならStorage Migration Service、ADなら新DC追加で安全に移せます。業務アプリはベンダーが用意する移行手順が最優先です。

まとめ：グレーアウトは「条件不一致」のサイン。無理に進めず最短で解決する

Windows Server 2016から2019へのインプレースアップグレードで「個人用ファイルとアプリを引き継ぐ」がグレーアウトする場合、多くはエディション／言語／Core-GUI／評価版などの不一致が原因です。まずは現行OSとISOの内容をコマンドで可視化し、条件を揃えましょう。

一方で、サーバー運用としては新規インストール＋移行が最も堅い選択肢です。特にドメインコントローラーや重要サーバーは、並走移行で切り戻し余地を残す設計が長期的に安全です。短期の手間より、復旧可能性と運用品質を優先して計画すると、結果的にコストが下がります。