Windows Server 2016の製品ライフサイクルとサポート終了日（End of LifeCycle《EOL》、End of Support《EOS》）である2027年1月12日までまだ1年以上ありますが、対策に着手するには遅すぎるくらいです。前回までに、サーバーの役割と機能の違い、非推奨または削除された機能について詳しく説明してきました。前回は、オンプレミスのHyper-VホストやホストクラスターのWindows Server 2025への移行について説明しました。今回は、移行時の注意点、特に不可逆的（元に戻せない）な部分について説明します。
システムの完全なバックアップを取得して失敗に備える
前回指摘したように、コピー（複製）やロールバック（チェックポイントの作成と適用）が可能な仮想マシン（VM）環境とは異なり、物理サーバーのインプレースアップグレードでは、アップグレード前のシステムのバックアップが重要です。システム（Windows Server）のベアメタル回復用バックアップ（システム状態、C:ドライブ、EFIシステムパーティション、回復パーティション）はもちろん重要ですが、内蔵、外付けに関係なく、OSドライブや別ドライブ上にあるデータ（VMを含む）のバックアップも取得しておくべきです（画面1）。なぜなら、OSのアップグレードに伴う、記憶域関連の不可逆的なアップグレードの影響を受ける可能性があるからです。記憶域を元に戻せなければ、いくらOSをロールバックできても、データを読み書きできなくなってしまいます。
画面1 アップグレード前にシステムのバックアップを実施する。完全にロールバックするためには、データ（VMを含む）をバックアップすることも重要
ReFSボリュームはバージョンの自動更新に注意
ReFS（Resilient File System）は、データの可用性を最大化し、さまざまなワークロードで大規模なデータを効率的に格納するスケーラビリティを備えながら、パフォーマンスと破損に対する回復性を備えた、アプリケーションやデータ向けのファイルシステムです（OSディスクには非対応）。例えば、ReFSは仮想化ワークロード、例えばHyper-VのVMの格納先として適しており、VMチェックポイントのマージ操作の高速化（ReFSのブロック複製機能の効果）、容量固定VHD（x）の高速なプロビジョニング（ReFSのスパースVDL機能の効果）が可能です。またReFSは、数百万TBをパフォーマンスに悪影響を与えることなくサポートするように設計されており、NTFSよりも大きなスケーリングを実現できます。
ただし、ReFSのバージョンには注意が必要です。NTFSバージョンは3.1のまま長い間変更がありませんが、ReFSはOSバージョンごとに新しいバージョンが提供されています。例えば、Windows Server 2016はReFS 3.1、Windows Server 2019はReFS 3.4、Windows Server 2022はReFS 3.7、Windows Server 2025はReFS 3.14です。新しいOSにおける下位バージョンとの互換性は「読み取り専用」でボリュームがマウントされた場合にのみ提供されます。下位バージョンのReFSボリュームが新しいOSに読み書き可能な状態でマウントされた場合、新しいOSのReFSバージョンに自動的にアップグレードされます（画面2）。そして、新しいバージョンのReFSボリュームは、以前のバージョンのOSでは認識されないファイルシステムとして扱われます（画面3）。
アップグレード対象のHyper-VホストのVMがReFSボリュームに格納されている場合、問題なくアップグレードできればよいのですが、そうでない場合、OSをロールバックしただけでは、VMのReFSボリュームを認識できなくなってしまうのです。データ（VM）のバックアップがなければ、旧OS環境にVMを復元することはできません。
画面2 アップグレード対象のサーバーにReFSボリュームが存在していた場合、そのボリュームのReFSバージョンは自動的に新OSのバージョンに更新される
画面3 ReFS 3.14のボリュームを、Windows Server 2016（既定はReFS 3.1）に接続すると、ボリュームのファイルシステムを認識できない
記憶域プールもUpdate-StoragePoolを実行すると不可逆的に
記憶域スペースの記憶域プールは、Windows Serverのバージョンをアップグレードしても、そのまま動作します。ただし、記憶域スペースの新機能を使用するには「Update-StoragePool」コマンドレットを実行して、プールのメタデータを更新する必要があります。プールを更新すると、下位互換性は提供されなくなるので注意してください。なお、Update-StoragePoolはバージョンアップのたびに毎回実行する必要があるわけではないようです。少なくとも、Windows Server 2016からWindows Server 2019以降にアップグレードする場合はUpdate-StoragePoolを実行する必要があります。
なお、Windows Serverのフェールオーバークラスタリング機能でクラスター化されたHyper-Vホストクラスターでは、Windows Server 2016以降、SAN共有ストレージや記憶域ストレージダイレクト（S2D）に作成したクラスターの共有ボリューム（Cluster Shared Volume《CSV》）のファイルシステムとして、従来のNTFSに加えて、ReFSが使用できるようになりました。ReFS形式のCSVであっても、CSVFS（CSV File System）による抽象化レイヤーがあるため（実際のI/Oは所有者ノードが実行するため）、ローリングアップグレード中のバージョン混在モードにおいても既存のReFSボリュームを継続して利用可能です。アップグレード完了後に「Update-ClusterFunctionalLevel」コマンドレットや「Update-StoragePoool」コマンドレットで最新の機能レベルや記憶域プールに更新することで、新しいクラスターの機能やReFSの新機能を利用できるようになります。ただし、実際に検証してみたことはないので、保証はできません。万が一に備えてのデータのバックアップは忘れずに。
クラスターのローリングアップグレードについては、詳細な手順が公式ドキュメントとして提供されているため、そちらに従って作業してください。
クラスター OS のローリング アップグレードを使用して Windows Server フェールオーバー クラスターをアップグレードする｜Windows Server（Microsoft Learn）
記憶域スペース ダイレクト クラスターをアップグレードする｜Windows Server（Microsoft Learn）｜Windows Server（Microsoft Learn）
NICチームスイッチはアップグレード前にSETスイッチに移行すること
vol.149で説明したように、Windows Server標準のNICチーム（NICチーミング）のネットワークアダプターを使用したHyper-V仮想スイッチ（NICチームスイッチ）は、Windows Server 2022で非推奨となり、「Hyper-Vマネージャー」による作成ができなくなりました。Windows Server 2022ではPowerShellのNew-VMSwicthの-AllowNetLbfoTeamsパラメーターを使用することで、引き続きNICチームスイッチを作成することができましたが、-AllowNetLbfoTeamsパラメーターはWindows Server 2025では使用できなくなりました。
NICチームスイッチが存在する場合は、インプレースアップグレードはブロックされ、続行できません（画面4）。その場合、アップグレード前に、現在のNICチームスイッチとNICチームを削除し、Windows Server 2016のHyper-V仮想スイッチから利用可能なSET（Switch Embedded Teaming）スイッチを作成してから、Windowsセットアップを再実行または情報の更新を実行します。
画面4 NICチームスイッチが存在すると、Windows Server 2025（またはWindows Server 2022）へのアップグレードがブロックされる
しかし、同じスイッチ名でSETスイッチを作成したとしても、その仮想スイッチに接続済みのVMのネットワークアダプターは、“構成エラー”（仮想スイッチに接続済みだが、その仮想スイッチが存在しないまたは変更された状態）の状態になることに注意してください（画面5）。「Hyper-Vマネージャー」でVMごとにそののプロパティを開いて、“構成エラー”を修正する必要があります。PowerShellで次のコマンドラインを実行すると、“構成エラー”状態のVMのネットワークアダプターに指定した仮想スイッチ（$switchName）を一括で割り当てることができます。
画面5 仮想スイッチを再作成したら、VMのネットワークアダプターの“構成エラー”状態を修正する必要がある
| $switchName = "仮想スイッチ名" Get-VM | ForEach { Get-VMNetworkAdapter -VMName $_.Name | Where {($_.Connected -eq $true) -and ($_.SwitchName -eq $null)} | ForEach { Connect-VMNetworkAdapter $_ -SwitchName $switchName } } |
または
| $switchName = "仮想スイッチ名" $vms = Get-VM ForEach ($vm in $vms) { $nics = Get-VMNetworkAdapter -VMName $vm.Name | Where {($_.Connected -eq $true) -and ($_.SwitchName -eq $null)} ForEach ($nic in $nics) { Write-Host "'$($vm.Name)' の '$($nic.Name)' が構成エラーのため修正します。" Connect-VMNetworkAdapter -VMNetworkAdapter $nic -SwitchName $switchName } } |
Windows Server 2016 EOSまであとX日（1）｜...｜（11）｜（12）
