Server 2012は公式にサポート終了を迎えており、Server 2012 R2のサポート終了は2023年10月23日です – ですから当然、あなただけではありません。2012はできるだけ早くアップグレードすべきです。もちろん、そこに費やす時間と労力は最小限に抑え、アップグレードをできる限り自動化したいはずです。

このガイドでは、サーバーアプリケーション、データベース、ユーザープロファイル、共有、データの機能を完全に保ったまま、Server 2012を2022 / 2019へアップグレードする選択肢を紹介します。同じプロセスは2012以外のサーバーにも使えます。2012に絞っているのは、2023年のサポート終了があるからにすぎません。

Server 2012のアップグレードには、主に2つのアプローチがあります:

2012から2019 / 2022へのインプレースアップグレード: この選択肢では、元の2012の“上に”新しいサーバーバージョンをインストールすることで、2012サーバーを新しいOSへアップグレードします。
Server 2012から新しいServer 2019 / 2022への移行アップグレード: このアプローチでは、2012サーバーの中身を、2022 / 2019が動く別のサーバーへ移します。

2012から2022 / 2019へのアップグレードを自動化する方法だけを知りたくて、一般的な解説は不要ですか？
ここをクリックすると実際のアップグレード手順のパートへ飛べます。

あなたのサーバーで2012から2022へのインプレースアップグレードは可能か？

こちらがWindows Serverのアップグレードパスの図です（出典: Microsoft.com）

上の図のとおり、2012から2022へ直接インプレースアップグレードすることはできません。しかしオンプレミスのサーバー（物理・仮想とも）なら、2回の“ホップ”で実現できます:

まず、Server 2012 / 2012r2をServer 2016へアップグレードします
次に、そのServer 2016を2022へアップグレードします

ただし注意してください。 AzureサーバーやAWSサーバーはインプレースアップグレードできません – 少なくとも“従来の”方法では。そうしたクラウドホスト型サーバーには、下記の“移行アップグレード”.

インプレースアップグレード vs 移行アップグレード: 長所と短所

インプレースアップグレードの 最大の利点 は（それが実際に可能な場合の話ですが）– 少なくとも一見 – 実にシンプルで苦労がなさそうに聞こえる点です。結局のところ、新しいWindows Server OSを（2回）インストールするだけで、アプリケーション／データの再インストールに対処する必要はありません。やることは:

現在のServer 2012またはServer 2012r2の“上に”Windows 2016をインストールする
完了したら、その2016の“上に”Server 2022（またはServer 2019）をインストールする

どちらのステップも、適切なISOをダウンロードしてマウントすれば実行できます。

残念ながら、現実はいつもそれほど単純ではありません。インプレースアップグレードには3つの大きな懸念があります:

現在動いているサーバーを壊すことになる: インプレースアップグレードの最大の問題は、開始した瞬間から動くサーバーがなくなり、新しいサーバーが完全に稼働するまで戻ってこないことです。インプレースアップグレードはそういう設計なのです。もちろん元の2012のバックアップはあるでしょう（この種のアップグレードでは絶対に必要です）が、ロールバックは必ずしも簡単ではありません。しかもアップグレード処理自体が非常に長くかかることも多く – その間もやはり、稼働するサーバーはありません。これはインプレースアップグレードに内在する問題で、ミッションクリティカルなサーバーでは最初から論外になる理由でもあります。

アップグレード処理はいつもスムーズとは限らない: 紙の上では、“新しいOSを2回インストールするだけ”はそう悪く聞こえません。しかし厳しい現実として、インプレースのOSインストールは想定よりスムーズに進まないことが多いのです。移行元サーバーにOS関連の問題があれば、それを直すまでインストールが始まらないことすらあります。それに、インプレースアップグレードを何度か経験したIT管理者なら誰でも、3時間アップグレードを走らせた末に“0x800F081E The installation failed in the SAFE_OS phase with an error during INSTALL_UPDATES operation”のようなエラーを食らう気持ちを語ってくれるでしょう。

最終結果を徹底的に検証しなければならない: インプレースアップグレード（2012から2016、続いて2016から2022または2019）を完了できたとして、次はサーバー上の各コンポーネントと各アプリケーションを徹底的に検証する番です。約10年の隔たりを、クリーンインストールではなく一連のアップグレードで橋渡ししているのです。すべてのOSコンポーネントが依然として機能し、期待どおりに動いていることを確認するのが重要です。

結論として、理論上は – インプレースアップグレードは有望に聞こえます。実際には、必ずしもそうではありません。ミッションクリティカルでないサーバーを中心に、試す価値がある場合もあり – うまくいけば大量の時間と労力を節約できます。しかしほとんどのサーバーにとって、インプレースは総合的に見て最善のアプローチではありません。

実際、多くのベンダーがインプレースアップグレードは避けるべきだと明言しています – たとえば VMWareはこちらで: “ゲストOSのインプレースアップグレード（Windows Server 2016やWindows Server 2019からWindows Server 2022への、メジャーOSリリース間のもの）は推奨されません。ベストプラクティスは、新しいVMに新しいメジャーOSリリースをインストールすることです”。

2012から2019 / 2022へアップグレードする、もっと良い方法は？

以上を踏まえると、当然の疑問は – インプレースアップグレードが得策でないなら、代わりに何ができるのか？答えは – 移行アップグレード です。2012から2022 / 2019へ。

移行: Server 2012からServer 2022またはServer 2019へアップグレードするもう一つの道

移行アップグレードは、“昔ながら”のインプレースアップグレードの代替手段です。新しいServer 2022または2019をインストールし、そこへ2012 / 2012r2の中身を移します。最終的に、すべてが2022 / 2019のリプレース先で動く状態になります。

移行アップグレードが、上で挙げたインプレースの欠点のうち2つを即座に解消するのは明らかです:

非破壊的で、ダウンタイムはほぼゼロ: 元のサーバーは常に稼働し続け、破壊も影響も一切受けません。移行先が完全に稼働して使える状態になってから切り替えるだけです – これによりダウンタイムとリスクは最小化（あるいは完全に排除）されます。

最新OSから始まるクリーンインストール: 10年分の積み重ねアップグレードと3つの異なるOSバージョンを引きずることはありません。最新のOSを直接動かすのです。

残るは3つ目、アップグレード処理そのものです。

移行の問題は、手動でやると膨大な時間と労力を食うことです。アプリケーションの再インストール、構成の再構築、そもそもすべてがどう組まれていたかの思い出し作業、データと権限、共有、パーソナライズのコピー、サーバーを動かしている細々としたことすべて – リストは延々と続き、その作業は何日も続きかねません（ヒューマンエラーは言うまでもなく）。

幸い、これには解決策があります。移行は専用のサーバー移行ソフトウェア – Zinstall WinServ – で自動化でき、このチュートリアルでその方法を説明します。

これはどんなプラットフォームの組み合わせでも機能します: 物理2012から物理2022へ、物理からVM／クラウドへ、オンプレの2012r2 VMからAWSの2019サーバーへ、AzureのServer 2012 VMからAzureのServer 2022 VMへ（そう、これを使えば“不可能”なはずのAzureインプレースアップグレードを実質的に実現できます！）。

これはすべてネイティブな移行であり、アプリ仮想化／リフト＆シフト／クローンではありません。アプリケーションは移行先サーバーに実際にインストールされ、共有は設定され、データと設定は移されます。移らないのは古いOSそのものだけです。

自動化された移行は最後の欠点を解消し、2012から2022 / 2019へのアップグレードをクリーンに、効率的に、安全に実行できるようにします。

では、やり方を見てみましょう。

ビデオデモ – Server 2012から2022 / 2019への移行

始める前に: 2012サーバーの棚卸し、バックアップ、計画

サーバーを棚卸しする: 典型的な環境には、かなり多様なサーバータイプがあるはずです。Domain Controller、Active Directory、IIS、Exchange、DNS、DHCPといったWindows Serverの役割に特化した、役割指向のサーバーがあります。役割の移行は自動化されておらず、手動で行う必要があります。

しかしより多数を占めるのは、実際の基幹業務アプリケーション（LOB）を動かし、会社のデータを保管するアプリケーションサーバーとファイルサーバーです。通常、役割ベースのグループより圧倒的に数が多いのです。

アプリケーションサーバーとファイルサーバーは、サーバー移行ソフトウェアを使って自動的に、しかも大規模に移行できます（下記参照）。

計画段階では、環境内のサーバーの一覧を用意し、それぞれが何を担っているかを把握する必要があります。役割サーバーが何台、アプリケーションサーバーが何台と分かるだけでも大きな前進です。アプリケーションサーバーの移行は自動化できるため、移行に必要な時間と労力をかなり正確に見積もれるようになります。

バックアップが最新で、実際に復元可能であることを確認する: 大きなアップグレードには失敗がつきものです。有効で最新のバックアップがなければ、サーバー上のすべてを失うリスクがあります。手元のバックアップが破損しておらず、必要なときに復元できる状態であることを必ず確認してください！

リプレース先の種類を決める: サーバーの入れ替えを決めたら、リプレース先には複数の選択肢があります。オンプレミスの物理Windows 2022 / 2019サーバー、オンプレのVMサーバー（ESX / Hyper-Vなど）、あるいはオフプレミスで動くクラウドベースのサーバー（Azureへの移行、Amazon AWSへの移行など）です。WinServを使うなら、これらのどの移行もサポートされるため、選択によって移行の難易度が大きく変わることはありません。

Server 2012をServer 2022 / 2019へアップグレードする手順

以下のプロセスは、Server 2012 / 2012 R2から新しいWindows Server 2016 / 2019 / 2022へアップグレードする手順の概要です。

オンプレ移行（移行先サーバーが移行元と同じネットワーク上にある場合）と、オフプレ移行（移行先がオフサイトにある場合。Azure / AWSへのサーバー移行など）を取り上げます。

Server 2012をServer 2022 / 2019へアップグレードする – オンプレ移行

両方のサーバーで Zinstall WinServ を実行します。
両方のサーバーで、最初のシナリオ“Moving between two machines”を選びます。
2012サーバーで“This is the Source”オプションを選び、そのまま実行させておきます。新しいサーバーからの接続を待つ状態になります。
移行先のServer 2022 / 2019で、“This is the Target”オプションを選びます。
WinServが移行元サーバーを自動検出します。サーバーが異なるサブネットにある場合は、移行元サーバーのIPアドレスを手動で指定することもできます。
移すものを厳密に選びたい場合は、Advancedメニューを使ってください。すべてを移すだけなら、Advancedメニューに入る必要はありません。
NextをクリックしてからGoをクリックすると、移行が始まります。
移行には（データ量に応じて）しばらく時間がかかり、完了するとお知らせします（処理のテキストログも生成されます）。

これで完了です！移行処理はこれで全部です。もちろんアップグレード全体ではありません。実行前にサーバーを立ち上げる必要はありましたし、結果の確認（下記参照）も必要です。しかし、アップグレードの雑務の大半をたった今自動化できたのです。

Server 2012をServer 2022 / 2019へアップグレードする – オフプレ（Azure、AWS、その他の間接アップグレード）

両方のサーバーで Zinstall WinServ を実行します。
移行元サーバーで3番目のオプション“Moving from Machine to Container”を選びます。これによりサーバーを単一の“移行可能イメージ”コンテナーファイルに取り込み、後でそこから移行先へ展開できます。
コンテナーの保存先を選び（ネットワーク共有、NAS、USBドライブでも – どんなストレージでも可）、Goを押して移行元サーバーをその場所へ完全キャプチャします。
完了したら、そのコンテナーへ移行先サーバーからアクセスできるようにします。たとえば移行先がクラウドホスト型サーバーなら、移行先サーバーがアクセスできるクラウドストレージへコンテナーをアップロードします。
新しい2022 / 2019サーバーでWinServを実行し、4番目のオプション“Moving from Container to Machine”を選びます
求められたら、コンテナーの保存場所を参照します。
移すものを厳密に選びたい場合は、Advancedメニューを押してください。すべてを移すだけなら、Advancedメニューに入る必要はありません。
NextをクリックしてからGoをクリックすると、移行が始まります。
移行には（データ量に応じて）しばらく時間がかかり、完了するとお知らせします。

互換性のないアプリケーションへの対処:

Windows Server 2012上で動く一部のレガシーなサードパーティアプリケーションは、Windows Server 2022 / 2019と互換性がない場合があります。この点は“昔ながら”のインプレースアップグレードでも“移行”アップグレードでも同じです。制約はアプリケーション自体の性質だからです。

2012では、互換性のないアプリケーションはServer 2003 / 2008と比べて大幅に少なくなっていますが、それでも起こりえます – たいていは、新しいOSバージョンに向けて更新されていないレガシーソフトウェアです。

“古い”が必ずしも“動かない”を意味するわけではない点に注意してください。かなりの数の古いアプリケーションは問題なく動作します

これらのアプリケーションをすぐには廃止できず、組織の継続運用に不可欠な場合、その稼働を守る推奨手段は、それらのアプリケーションを、新しいリプレースサーバー上で動く仮想Server 2012インスタンスへ仮想化移行することです。その後、それらのアプリケーションを段階的に廃止し、仮想化された2012インスタンスの稼働を止めるための手順を進めてください。

WinServ自体は特定のアプリケーションに依存せず、外の世界に知られていないカスタム・社内アプリケーションでも移行できます – 新しいサーバーで動作可能である限り。こちらは、これまでにお客様が移行してきた一般的なアプリケーションの一部です:

SQL Server
MS SQL
MySQL
SAP（SAP Business Oneを含む）
Oracle
Sybase
DB2
Java Application Server
Crystal Reports
Avaya
PeopleSoft
JD Edwards Enterprise One (JDE E1)
Citrix
Apache（Windowsのみ）
WebSphere
Microsoft Dynamics
…その他まだまだたくさん

移行後:

移行処理が完了したら、結果を検証する時間です。

必要に応じて、ドメインのDNSが新しいサーバーを指すよう調整が必要になることがあります。たとえば、古いCRMサーバーのDNSエントリを新しいサーバーのアドレスに変更する、といった具合です。
ログインスクリプトとGPOポリシーについても同様です。
使用するすべてのアプリケーションとコンソールを起動し、正しく読み込まれることを確認します。
クライアントのワークステーションを使って、クライアントが移行後のサーバーへ正しくアクセスでき、アプリケーションが問題なく動くことを確認します。

おめでとうございます！これで2012から2022 / 2019へのアップグレードは完了です。

Server 2012を2022 / 2019へアップグレードする準備はできましたか？

Zinstall WinServの入手はこちら

評価ライセンス／ボリューム価格／詳細情報をお探しですか？

sales@zinstall.com までメールでご連絡ください。サポートいたします。

Server 2012をServer 2022 / 2019へアップグレードする方法 – インプレースまたは移行