Windows Server 2025のインプレースアップグレード前に確認したい互換性チェックは、まず 対応パスがあるか、次に 言語・エディション・Server Core/デスクトップ エクスペリエンスの一致、さらに 役割・アプリ・ハードウェア・運用形態 の順で見るのが最短です。Windows Server 2025 は非クラスター環境なら Windows Server 2012 R2 / 2016 / 2019 / 2022 から直接インプレースアップグレードできますが、クラスターは1バージョンずつ、Boot from VHD や言語変更、Core⇔GUI切り替え、一部役割ではそのまま上げられません。 (Microsoft Learn)
実務では「セットアップが開始できるか」より、「アップグレード後もその運用が成立するか」で判断するのが重要です。特にドメインコントローラー、RDS ファーム、Hyper-V/フェールオーバークラスター、Azure VM、古い業務アプリを抱えたサーバーは、インプレースアップグレードより移行のほうが安全なことが少なくありません。 (Microsoft Learn)
先に決めるべきは「インプレースで上げるべきか」です
Windows Server の公式ガイダンスでは、アップグレード方法としてインプレースアップグレード、クリーンインストール、移行、クラスター OS のローリングアップグレードが整理されています。要点だけ言うと、同じハードウェアを使い続ける非クラスター環境ならインプレース、新ハードウェアやロール単位の切り分けが必要なら移行、Hyper-V / SOFS のクラスターならローリングアップグレードで考えるのが基本です。 (Microsoft Learn)
| 方法 | 向いているケース | 互換性チェックの勘所 |
|---|---|---|
| インプレースアップグレード | 同じサーバーをそのまま使い、短時間で新OSに上げたい | OSパス、役割、アプリ、言語、インストール形式の一致が前提 |
| 新規構築＋移行 | 新ハードウェアへ寄せたい、ロールやアプリが不安、切り戻しを簡単にしたい | ロールごとに移行可否を確認しやすい |
| クラスターローリングアップグレード | Hyper-V / SOFS のフェールオーバークラスター | 1バージョンずつ進める。通常の一括アップグレードとは別ルート |
この整理は Microsoft のアップグレード方法とクラスター公式ガイダンスに基づくものです。 (Microsoft Learn)
迷ったら、「同一機への最短ルートが必要で、かつ役割とアプリの互換性確認が済んでいる」ならインプレース、そうでなければ移行を優先する考え方が失敗しにくいです。クラスターだけは最初から別物として扱ったほうが安全です。 (Microsoft Learn)
Windows Server 2025へ直接上げられるソースOSかを確認する
Windows Server 2025 では、非クラスター環境なら最大4世代先まで直接アップグレードできます。実務で見るべき対応パスは次のとおりです。 (Microsoft Learn)
| 現在のOS | 2025へ直接インプレース | 実務メモ |
|---|---|---|
| Windows Server 2012 | 不可 | まず 2016 へ上げるか、新規構築＋移行を選ぶ |
| Windows Server 2012 R2 | 可 | 直接上げられるが、周辺ソフトや古いドライバーの棚卸しは厳しめに |
| Windows Server 2016 | 可 | パスは通る。アプリと運用依存の確認が成否を分ける |
| Windows Server 2019 | 可 | Windows Update に出る場合でも計画配信で進めたい |
| Windows Server 2022 | 可 | 最も判断しやすいパターン |
表の可否は Microsoft Learn のサポートパス表に基づいています。 (Microsoft Learn)
見落としやすいのは、Windows Server 2012 R2 から直接上げられることと、安全に上げられることは別だという点です。Windows Server 2012 / 2012 R2 のサポートは 2023年10月10日に終了しているため、そこからのアップグレードでは OS よりも先にバックアップ、監視、セキュリティエージェント、ストレージ/NIC ドライバーが壁になりやすいです。これは公式のサポート状況と互換性前提から見た実務上の注意点です。 (Microsoft Learn)
パスが通っても、次の条件で止まりやすい
インプレースアップグレードには、ソースOSのバージョン以外にも制限があります。ここが合っていないと、途中でブロックされたり、「ファイル、設定、アプリを保持」が選べなかったりします。 (Microsoft Learn)
| 確認項目 | 確認内容 |
|---|---|
| 言語 | 別言語へのアップグレードは不可 |
| アーキテクチャ | 32bit→64bit は不可 |
| インストール形式 | Server Core ⇔ デスクトップ エクスペリエンス の切り替えは不可 |
| エディション | 既定では Standard→Standard、Datacenter→Datacenter。Standard→Datacenter や Datacenter: Azure Edition への変更は可能だが、逆方向は不可 |
| メディア種別 | プレビュー版からの上書きは不可。評価版メディアへの上書き前提も避ける |
| 起動方式 | Boot from VHD は不可 |
| 製品系統 | Windows Storage Server からのインプレースは不可 |
| ネットワーク | NIC Teaming は事前に無効化が必要 |
この制限は Microsoft のアップグレード制限一覧に基づきます。 (Microsoft Learn)
役割と機能は「対応しているか」より「そのまま上げてよいか」で見る
Windows Server のロールはすべてがインプレースアップグレード対応ではありません。しかも、対応していても別の方法のほうが安全な役割があります。事前判断に使いやすいように整理すると次のようになります。 (Microsoft Learn)
| 役割 / 機能 | インプレース | 実務上の見方 |
|---|---|---|
| AD DS / DNS / DHCP | 可 | ただし DC は別格。既存DCをそのまま上げるより、新しい 2025 DC を追加して旧DCを降格するほうが安全 |
| AD FS | 不可 | 新ノード追加や移行前提で考える |
| Failover Clustering / Hyper-V | 可（条件あり） | クラスターノードはローリングアップグレード。単体 Hyper-V ホストでも実行中 VM を止める/退避させる必要がある |
| File and Storage Services | 可（サブ機能次第） | ストレージは Storage Migration Service も比較候補 |
| Remote Desktop Services | 可 | mixed mode farm は非対応。段階アップグレードの設計が必要 |
| Web Server (IIS) | 可 | ただし古い管理UIや暗号・認証依存を要点検 |
| Print and Fax Services | 不可 | 役割ごと移行を前提にしたほうがよい |
この表は Windows Server のロール移行マトリックスと関連ガイダンスを基に整理しています。 (Microsoft Learn)
要するに、単体の DHCP/DNS や比較的シンプルなファイルサーバーは候補になりやすく、AD FS・Print・複雑な RDS・クラスターは「上げられるか」ではなく「そのまま上げる価値があるか」で判断したほうがいいということです。 (Microsoft Learn)
ドメインコントローラーは別枠で考える
AD DS はロール表上はインプレース対応ですが、Microsoft はドメインのアップグレード方法として、新しい Windows Server を実行するサーバーを DC に昇格し、古い DC を降格する方法を推奨しています。既存 DC をインプレースアップグレードする場合は adprep /forestprep と adprep /domainprep を手動実行する必要があり、Windows Server 2025 の DC を既存ドメインに追加するには、そのドメインが少なくとも Windows Server 2016 の機能レベルである必要があります。 (Microsoft Learn)
FSMO 役割の所在確認も、DC 関連では先にやっておきたいポイントです。Microsoft Learn では次のコマンド例が案内されています。 (Microsoft Learn)
Get-ADDomain | FL InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | FL DomainNamingMaster, SchemaMasterFSMO の位置、レプリケーション状態、機能レベル、バックアップが曖昧なまま DC を上げるのは避けたほうが安全です。DC だけは「対応しているから実施」ではなく、「冗長化された新旧共存計画があるか」で判断してください。 (Microsoft Learn)
Hyper-V ホストとクラスターは停止条件まで確認する
単体の Hyper-V ホストでインプレースアップグレードする場合でも、Microsoft は バックアップに VM を含めること、さらに アップグレード中は VM を実行したままにできない としています。フェールオーバークラスターではローリングアップグレードが前提で、Hyper-V VM や SOFS のワークロードを止めずに1ノードずつ上げられますが、クラスターで一気に複数バージョンを飛ばすことはできません。 (Microsoft Learn)
アプリ互換性は「OS対応」と分けて確認する
ここがいちばん実務で抜けやすいところです。Windows Server のアップグレード要件を満たしていても、その上で動いているアプリが Windows Server 2025 をサポートしていなければ、本番では使えません。Microsoft は Windows Server 向けのサーバーアプリ互換性表を公開していますが、これはあくまでクイックリファレンスであり、最終判断は各製品の個別ドキュメントで行うべきと明記しています。 (Microsoft Learn)
代表例として、Windows Server 2025 向けの互換性表では Configuration Manager 2409、Exchange Server、SharePoint Server Subscription Edition、SQL Server 2019 / 2022 などが確認できます。ただし、役割や構成によって条件が付きます。たとえば Configuration Manager は Server Core 上で「管理されたクライアントと配布ポイント」は可でも、「サイトサーバーとして」は不可です。OS の可否だけでなく、製品のどの役割で使うのかまで確認するのがポイントです。 (Microsoft Learn)
Windows Server 2025で引っかかりやすい古い依存関係
Windows Server 2025 では、古い仕組みやコンポーネントの扱いが変わっているものがあります。インプレースアップグレード前に棚卸ししておきたい項目を絞ると次のとおりです。 (Microsoft Learn)
| 依存関係 | 2025での扱い | 事前に見ること |
|---|---|---|
| Internet Explorer 単体アプリ | 削除 | iexplore.exe 前提、ActiveX、古いローカル管理UIがないか |
| Windows PowerShell 2.0 | 2025 の 2025年9月以降更新で同梱されない | 古いスクリプトやモジュールを PowerShell 5.0 以降へ移せるか |
| SMTP Server 機能 | 削除 | ローカル SMTP リレーやアラートメールの送信経路を見直す |
| TLS 1.0 / 1.1 | 既定で無効 | 複合機、旧式アプリ、古いミドルウェアとの通信可否 |
| WMIC | FOD化、将来削除予定 | wmic バッチの置き換えが必要か |
| WID | 非推奨、将来削除予定 | AD FS、IPAM、RD Connection Broker、WSUS などの構成確認 |
| NLB | 非推奨 | 今回は動いても、中長期では代替構成を検討したい |
この表のどれかに引っかかるなら、OS のアップグレード前に運用変更も必要です。ここを無視すると、セットアップは完了しても、アップグレード後に通知、認証、ローカル管理、監視連携が壊れることがあります。 (Microsoft Learn)
ハードウェア・仮想化・クラウド側の互換性も見る
Windows Server 2025 の最低ラインとして、CPU は 1.4GHz 以上の x64 で、NX/DEP、CMPXCHG16b、LAHF/SAHF、PrefetchW、EPT/NPT、SSE4.2、POPCNT が必要です。RAM は Server Core / デスクトップ エクスペリエンスともに最低 2GB、システムパーティションは 32GB が絶対的な最小値 で、ネットワークインストール時や RAM が 16GB を超える場合は追加容量が必要です。CPU 機能の確認には Sysinternals の Coreinfo が案内されています。 (Microsoft Learn)
ただし、現場では「最小要件を満たす」だけでは足りません。ストレージコントローラー、HBA、NIC、バックアップ製品、EDR、監視エージェントが Windows Server 2025 をサポートするかは、必ずベンダー側でも確認してください。Microsoft 自身もアップグレード前提として、Microsoft 製サーバーアプリと非 Microsoft 製アプリ双方のサポート要件を確認するよう案内しています。 (Microsoft Learn)
仮想化と起動方式も要注意です。NIC Teaming は事前に無効化が必要で、Boot from VHD と Windows Storage Server からのインプレースアップグレードは非対応です。また、Microsoft の通常のインプレースアップグレード手順は 非 Azure のサーバー/VM向け であり、他社クラウドはプロバイダーの対応可否を確認する必要があります。 (Microsoft Learn)
Azure VM はさらに別枠です。Azure 上でインプレースアップグレードすると、VM の元イメージ情報は変わらず OS だけが更新されるため、Auto guest patching、Auto OS image upgrades、Hotpatching、Azure Update Manager などの Azure 機能が使えなくなります。これらを重視する運用なら、新しい VM を作って移行するほうが整合的 です。 (Microsoft Learn)
本番前にやる具体的な互換性チェック手順
インプレースアップグレード前の確認は、机上確認だけでは不十分です。公式情報の照合 → スキャン実行 → ログ確認 → バックアップ → 本番 の順に進めると、判断ミスを減らせます。 (Microsoft Learn)
現状情報を保存する
Microsoft は、失敗時の診断に備えて事前に情報採取しておくことを推奨しています。まずは現在のビルド、エディション、ネットワーク構成をファイルに落として保存します。 (Microsoft Learn)
Get-ComputerInfo -Property WindowsBuildLabEx,WindowsEditionID | Out-File -FilePath .\computerinfo.txt
systeminfo.exe | Out-File -FilePath .\systeminfo.txt
ipconfig /all | Out-File -FilePath .\ipconfig.txtこの3つを残しておくと、失敗後の切り分けや、アップグレード前後の差分確認がかなり楽になります。 (Microsoft Learn)
互換性スキャンだけ先に走らせる
いきなり本番アップグレードに入らず、セットアップの互換性スキャンだけ実行 するのが効果的です。Windows Setup には /compat scanonly があり、完全実行せずに互換性だけを判定できます。 (Microsoft Learn)
setup.exe /auto upgrade /noreboot /eula accept /compat scanonly /compat ignorewarningこのコマンドは、起動中の Windows Server 上で、マウントしたインストールメディアの setup.exe から実行します。あわせて、動的更新を使って最新の互換性情報で判定するのが無難です。 (Microsoft Learn)
判定結果はコードとログで見る
互換性エラーの典型は 0xC1900208 で、これは 互換性のないアプリまたはドライバーがある ことを示します。逆に 0xC1900210 なら、互換性問題は検出されていません。ログは C:\$WINDOWS.~BT\Sources\Panther\CompatData<date-time>.xml と、*_APPRAISER_HumanReadable.xml を見ると把握しやすいです。 (Microsoft Learn)
XML を読むときは、CompatData*.xml で BlockingType="Hard"、*_APPRAISER_HumanReadable.xml で DT_ANY_FMC_BlockingApplication=True と LowerCaseLongPathUnexpanded を探すと、どのアプリやファイルがブロックしているかを見つけやすくなります。 (Microsoft Learn)
バックアップは「OSだけ」で終わらせない
公式手順では、フルバックアップには OS、アプリ、データ、そしてそのサーバー上で動く VM を含めるよう案内されています。Hyper-V ホストなら、アップグレード中に VM を実行したままにはできないため、事前に停止、クイック移行、ライブマイグレーションのどれで退避するかも決めておく必要があります。 (Microsoft Learn)
失敗したときの見る場所を先に決めておく
アップグレードが失敗した場合、Windows Setup は SetupDiag を使って原因解析できます。SetupDiag の結果は %WinDir%\Logs\SetupDiag\SetupDiagResults.xml に出力され、主要ログとしては setupact.log が最重要です。setupact.log は $Windows.~BT\Sources\Panther や $Windows.~BT\Sources\Rollback など、フェーズごとに保存場所が変わります。 (Microsoft Learn)
Windows Update任せにしない
Windows Server 2019 / 2022 環境では、Windows Server 2025 が Windows Update 上で Optional upgrade として提示されることがあります。Microsoft は、パッチ管理ツール側でもこれを Recommended ではなく Optional として解釈すべき と案内しています。検証前に自動承認で配ってしまう運用は避け、ISO もしくは明示的な計画配信で進めるほうが安全です。 (Microsoft Learn)
こういうサーバーはインプレースより移行を選んだほうが安全です
次のどれかに当てはまるなら、インプレースアップグレードを無理に通すより、新規構築＋移行のほうが結果的に短時間で終わりやすいです。 (Microsoft Learn)
- AD FS や Print and Fax Services を使っている
これらはロールとしてインプレースに向きません。最初から移行計画を組んだほうがきれいです。 (Microsoft Learn) - ドメインコントローラーで、冗長化・機能レベル・adprep が整理できていない
DC はロール表だけで判断せず、新しい 2025 DC 追加→旧DC降格のルートを優先したほうが安全です。 (Microsoft Learn) - IE 単体アプリ、PowerShell 2.0、SMTP Server、TLS 1.0/1.1 依存など、古い仕組みが残っている
OS だけ上げると、アプリや運用が後で壊れる典型です。先に依存関係の置き換えを進めるべきです。 (Microsoft Learn) - クラスター、Azure VM、Boot from VHD、言語変更、Core⇔GUI切替が絡む
これらは通常の単純なインプレース前提で考えないほうがよく、専用手順か別方式が必要です。 (Microsoft Learn)
最後に整理すると
Windows Server 2025 のインプレースアップグレード前に確認したい互換性チェックは、対応パス、制限事項、役割、アプリ、古い依存関係、ハードウェア、実行方式 の順で潰すのが最も実用的です。非クラスターの単体サーバーで、役割とアプリが整理されているならインプレースは有力ですが、DC、クラスター、RDS、Azure VM、古い業務アプリがある環境では、移行を前提にしたほうが事故を減らせます。 (Microsoft Learn)
次にやるべきことはシンプルです。対象サーバーごとに、ソースOSと制限事項の確認、役割とアプリの一覧化、/compat scanonly の実行、バックアップと切り戻し条件の確認 を先に終わらせてください。この4つが揃ってからメンテナンスウィンドウを切れば、互換性チェックが「読むだけの確認」ではなく、実行できるアップグレード計画になります。 (Microsoft Learn)
コメント