これまでの連載で説明したように、レガシーシステムのハードウェアをオンプレミスのHyper-V環境や、Microsoft Azure、Azure Stack HCI、他社クラウドなどのIaaS(Infrastructure as a Service)環境の仮想マシンに移行してしまえば、その運用環境と並行する形でレガシーシステムのアップグレード方法の方針を検討し、時間的余裕を持って移行作業を実施することができます。
今回は、レガシーシステムのWindows Server 2012/2012 R2のOSを最新のWindows Server 2022にアップグレードする際の選択肢と、アップグレード前後で注意したい点について解説します。
仮想化の利点:アップグレードが容易になり、ライセンスも簡素化
レガシーシステムをオンプレミスまたはクラウド上の仮想マシンにいったん仮想化してしまえば、運用環境とは別のネットワークでその仮想マシンのコピーを起動して、運用環境と並行しながらOSアップグレードの作業を進めることができます。
仮想マシンに対するリソースの割り当ては、ホスト環境のリソース量が許す限り、柔軟にカスタマイズでき、チェックポイントやバックアップコピーを利用することで何度でもやり直しができます。固有のハードウェアの縛りが無くなるという意味でも、アップグレードの作業は進めやすくなるはずです。
Windows Server 2022 DatacenterのHyper-V環境や、Azure Stack HCIのWindows Serverサブスクリプションライセンスを購入した場合は、ゲストOSのライセンスについて考える必要もありません。別途、仮想マシン自動ライセンス認証のセットアップは必要ですが、旧バージョンから最新のWindows Server 2022までのサーバOSの仮想マシンを無制限に実行できます。
バージョンの隔たりはアップグレードを難しくする
サーバOSを新バージョンにアップグレードする方法としては、 大きく次の3つの方法があります。
- インプレースアップグレード(アップグレードインストール)
- 新規インストールしたサーバへの旧サーバからの役割と機能の移動
- ローリングアップグレード(Active Directoryドメインやフェイルオーバークラスター)
最も簡単なのはサーバの役割や機能、システム設定、データを維持しながら、新バージョンに移行することができるインプレースアップグレードです。しかし、マイクロソフトは、あるバージョンのWindows Serverへのインプレースアップグレードのサポートを、最大で2つ前のバージョンからに限定しています。
Windows Server 2012は、Windows Server 2012 R2またはWindows Server 2016への、Window Server 2012 R2はWindows Server 2016またはWindows Server 2019へのインプレースアップグレードがサポートされますが、Windows Server 2022への直接的なインプレースアップグレードはサポートされません。
これはWindowsセットアップがサポートされないアップグレードパスでのインプレースアップグレードをブロックするものではありませんし、続行すればOSのアップグレードは成功する可能性もあります。しかし、公式にサポートされない形でのアップグレードによってどのような影響があるかわかりません。
公式にサポートされる方法でWindows Server 2012/2012 R2から最新のWindows Server 2022にアップグレードするためには、途中のバージョンへのアップグレードを行う必要があるのです。
-
Windows Server 2012 R2からWindows Server 2022にインプレースアップグレードできそうに見えるが、これはサポートされないアップグレードパス。Windows Server 2012はWindows Server 2016を、Windows Server 2012 R2はWindows Server 2016または2019を経由してアップグレードを行わなければならない
Windows Server 2022 DatacenterのサーバライセンスやAzure Stack HCIのWindows Serverサブスクリプションライセンスがあれば、途中のバージョンを含むライセンスについて考慮する必要はありません。時間はかかりますが、Windows Server 2012/2012 R2から最新バージョンまでインプレースアップグレードすることは可能です。しかし、同様の役割を担うシステムを比較的簡単に構築できる場合は、新規インストールして再構築する方が早いこともあります。
単純にOSを最新バージョンにアップグレードするだけでは、その上で動くことになるアプリケーションやサービスが以前と同様に問題なく動くとは限りません。バージョンの隔たりは、インプレースアップグレードを難しくするだけでなく、後継バージョンのWindows Serverで行われた仕様変更、サーバの役割や機能の廃止、既定の設定の変更、セキュリティ強化など、さまざまなことが影響して、期待通りに動かないこともあり得ます。
Windows Serverの各バージョンで削除されたり、非推奨にされたりした機能の一覧については、以下のドキュメントを参照してください。
非推奨機能や問題解決ツールの提供終了などを確認
ただし、この一覧は完全なものではありません。例えば、Windows Server 2012 R2までは利用できたサーバの役割の1つである「ネットワークアクセス保護(NAP)」(クライアントに要求するセキュリティ設定などの準拠レベルに応じて、運用ネットワークからクライアントを隔離するソリューション)は、Windows Server 2012 R2の時点ですでに非推奨となりました。そして、上記の「Windows Server 2016の削除された機能」の一覧には記載されていませんが、実際にはWindows Server 2016で削除されています。
-
Windows Server 2012 R2のNAPを含む「ネットワークポリシーとアクセスサービス」の役割サービス(画面上)と、Windows Server 2022の同役割サービス(画面下)。Windows Server 2016以降のネットワークポリシーサーバ(NPS)からはNAPが削除された
NAPクライアント機能については、Windows 10で削除されています。また、同様にWindows Server 2012 R2の時点で非推奨となったサーバの機能「SMTPサーバ」は、最新のWindows Server 2022ではまだ削除されていませんが、正常に機能しない(設定を参照、変更しようとするとMMCスナップインがクラッシュする)という問題があります。
これまで同機能をメールの中継に利用してきた場合は、Windows Server 2022にするまでに代替の方法を検討する必要があります。ただし、Windows Server 2019までは同機能は正常に動作します。
サーバOSのバージョンアップに伴うこういった問題を事前に回避するため、アップグレード前の調査とアップグレード後の動作テスト、影響を受ける場合の代替策の検討と導入は重要な作業になります。同様の問題は、後継バージョンがリリースされた直後には話題になりますが、時間が経つにつれ、情報を得るのが難しくなります。以前は提供されていた問題解決のための公式ツールが、提供終了になっていることもあります。
また、後継バージョンで追加された新しい技術についても、すでに状況が変化しているものもあります。例えば、Windows Server 2016で初めて導入されたコンテナ技術。当時は、「Docker Enterprise Edition(Docker EE)」をマイクロソフトが使用ライセンスとサポートを込みで提供していました。しかし、後に「Docker Enterprise」に改称され、現在は「Mirantis Container Runtime」にとして提供されており、ライセンスとサポートはMirantisの有償サブスクリプションに移されました。
現在、Windows Server(2019以降)は、「Docker CE/Moby」、「Mirantis Container Runtime」、「Containerd」をWindowsコンテナのランタイムとしてサポートしていますが、マイクロソフトが製品サポートを提供しているのはContainerdランタイムを使用するAzureと、Windows ServerまたはAzure Stack HCI上の「Azure Kubernetes Service(AKS)」のみです。インターネットの検索結果には、この状況を反映していない古い情報がたくさんあるので注意が必要です。