Windows Server 2012R2のEOL（End of Life）は2023年10月10日です。
現時点（2022年5月）では後、1年半弱ありますが、そろそろ準備をしていかなきゃいけませんね。アプリケーションによっては互換性もありますので、検証を含めると、それなりの期間が必要です。
今回はAWS上のWindows Server 2012R2をWindows Server 2016にUpgrade（アップグレード）する内容について書いていこうと思います。本記事では触れないですが2012R2⇒2019も同様の手順で可能です（段階的に2016にする必要はありません）。
- アップグレードの選択肢
- インプレースアップグレードの手順
- 自動アップグレードの手順
ご参考までに今後のWindows ServerのEOLを載せておきます。
- Windows Server 2012 R2：2023/10/10
- Windows Server 2016：2027/01/12
- Windows Server 2019：2029/01/09
- Windows Server 2022：2031/10/14
*Windows Server 2022への「自動」アップグレードに関してはAWS上に記載はありませんでした（現時点では未サポートの可能性があります）。
では早速！
2022.11.07：誤字脱字修正、windows.oldフォルダに関する補足を追記。
アップグレードの選択肢
AWS公式サイトのWindows Serverアップグレードに関する記事は次の通りです。
上記記事を元にアップグレードの選択肢を以下にまとめました。さらに、実際に検証した結果を踏まえて私なりにメリット・デメリットも合わせて記載しました。
| 選択肢 | 概要 | メリット | デメリット |
|---|---|---|---|
| インプレース アップグレード | インストールディスクをマウントして アップグレードする。 | 既存EC2内で完結 | 少し条件が厳しい 少し面倒 |
| 自動アップグレード | SSMのAutomationで アップグレードされたAMIを作成する。 | 簡単 (条件をクリア出来る前提) | 条件が厳しめ 後でAMI展開が必要 |
| 新規インストール | 新規サーバを別途用意して 自分でアプリやデータを移行する。 | 確実 | 面倒 |
本記事では「インプレースアップグレード」「自動アップグレード」を実際に試してみましたので、以降に手順を載せていきます。
インプレースアップグレードの手順
概要
AWS公式サイト上の手順は以下になります。
- 既存EC2に対して事前準備（AWS関係サービスのインストールやアップデート等）が必要です。手操作です。
- 既存EC2に対してアップグレードを実施します（わかりやすい）。
インプレースアップグレードの全体的な流れは次の通りです。
- PV(準仮想化)ドライバのアップグレード。
※既に新しめであればスキップしても良いと思います。 - EC2Configサービスのアンインストール。
- EC2Launchサービスのインストール。
- AWS Systems Manager SSM Agent のインストール。
- Windows Server インストールメディアのスナップショットより新しいEBSを作成して対象EC2にアタッチ。
- アップグレードを実行。
- インストールメディア用のEBSをデタッチ。
対応時間は大きな問題がなければ約2時間です。
- 上記記載の通り対象EC2にSSM Agentが必要になるためSSM Agentがインターネット経由や社内プロキシ経由等でAWS側と通信できる必要があります。
- 少なくとも 2 つの vCPU と 4GB の RAM を持つインスタンスでオペレーティングシステムのアップグレードを実行することをお勧めします。t3a.medium等ですね。
- 自動アップグレードWindows インスタンス上のルートボリュームに十分な空きディスク容量があることを確認します。20GB程度は必要です。不足しているとアップグレード前のチェックでエラーになります。
- アンチウイルスとアンチスパイウェアのソフトウェアとファイアウォールを無効にしておきます。悪さすることがあるようです。
他にも細かい前提条件がありますが、詳細は上記のAWS公式サイトから確認可能です。
今回はお試し実施になるため、バックアップ（AMI）から検証用EC2を作成してアップグレードをしてみました。
PVドライバのアップグレード
Windows PowerShellを使って、現在のPVバージョンを確認しておきます。
# バージョン確認コマンド
Get-ItemProperty HKLM:\SOFTWARE\Amazon\PVDriver
# 実行結果の例
Version : 8.3.4
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Amazon\PVDriver
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Amazon
PSChildName : PVDriver
PSDrive : HKLM
PSProvider : Microsoft.PowerShell.Core\Registry
PVドライバの更新履歴は以下AWSサイトから確認可能ですが、新しければ問題ないでしょう。
そこそこ古い場合は以下の手順でアップグレードします（PowerShell利用）。
# ダウンロード＆解凍
invoke-webrequest https://s3.amazonaws.com/ec2-windows-drivers-downloads/AWSPV/Latest/AWSPVDriver.zip -outfile $env:USERPROFILE\pv_driver.zip
expand-archive $env:userprofile\pv_driver.zip -DestinationPath $env:userprofile\pv_drivers
※もしもプロキシ問題でダウンロード出来ない場合は「Invoke-WebRequest」にオプション「-Proxy http://proxy.co.jp:8080」を付けましょう（urlやポートは適宜変更ください）。フォルダ内容を確認して「AWSPVDriverSetup.msi」よりPVドライバをアップグレードします。実行中はインスタンスが最大15分間利用出来ないため注意しましょう。
EC2Configサービスのアンインストール
プログラムと機能から「EC2ConfigService」を見つけてアンインストールします。
なお、EC2ConfigServiceのアンインストールによって「SSMAgent」も削除されました（環境依存かもしれませんが私の場合はそうでした）。
EC2Launchサービスのインストール
Windows PowerShellを使ってダウンロード及びインストールしていきます。
# ダウンロード先作成
mkdir $env:USERPROFILE\Desktop\EC2Launch
# ダウンロード１
$Url = "https://s3.amazonaws.com/ec2-downloads-windows/EC2Launch/latest/EC2-Windows-Launch.zip"
$DownloadZipFile = "$env:USERPROFILE\Desktop\EC2Launch\" + $(Split-Path -Path $Url -Leaf)
Invoke-WebRequest -Uri $Url -OutFile $DownloadZipFile
# ダウンロード２
$Url = "https://s3.amazonaws.com/ec2-downloads-windows/EC2Launch/latest/install.ps1"
$DownloadZipFile = "$env:USERPROFILE\Desktop\EC2Launch\" + $(Split-Path -Path $Url -Leaf)
Invoke-WebRequest -Uri $Url -OutFile $DownloadZipFile
# インストール
& $env:USERPROFILE\Desktop\EC2Launch\install.ps1もしもプロキシが必要でダウンロード出来ない場合は「Invoke-WebRequest」にオプション「-Proxy http://proxy.co.jp:8080」を付けましょう。プロキシのURLやポートは環境に合わせて調整ください。
AWS Systems Manager SSM Agentのインストール
※元々の環境にSSM Agentはインストール済みでしたが、EC2ConfigServiceのアンインストール時に消えてしまいましたので、再度インストールします。
SSM Agentの稼働状況は「AWS Systems Manager」サービスの「フリートマネージャー」より確認するのが確実かと思います。オンラインでなければ対処しましょう。
Windows PowerShellを使ってダウンロード及びインストールしていきます。
# ダウンロード
Invoke-WebRequest -Uri https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/windows_amd64/AmazonSSMAgentSetup.exe -OutFile $env:USERPROFILE\Desktop\SSMAgent_latest.exe
# インストール
Start-Process -FilePath $env:USERPROFILE\Desktop\SSMAgent_latest.exe -ArgumentList "/S"
# サービス再起動
Restart-Service AmazonSSMAgent
# サービス状態確認
Get-Service AmazonSSMAgent
# インストールオブジェクト削除
rm -Force $env:USERPROFILE\Desktop\SSMAgent_latest.exeもしもプロキシが必要でダウンロード出来ない場合は「Invoke-WebRequest」にオプション「-Proxy http://proxy.co.jp:8080」を付けましょう。プロキシのURLやポートは環境に合わせて調整ください。
SSM Agentはインターネットを超えてSSMと通信出来る必要があります。
- インターネット接続出来ない場合はVPCエンドポイントを設定する。
- Direct Connect等で社内プロキシ経由の場合はSSM Agentに対してプロキシ設定を行う。
- 該当EC2のIAMロールに「AmazonSSMManagedInstanceCore」が無い。
等を疑いましょう。
インストールメディア(EBS)のアタッチ
WindowsServer2016用のスナップショットがAWSより提供されているため、該当az内にEBS化した後、該当EC2にアタッチしましょう。EC2は開始状態のままでOKです。
最初にEC2サービス内のスナップショットからパブリックスナップショットとして、「所有者のエイリアス：amazon」「説明：windows」を条件にスナップショットをフィルタします。今回はWindows 2016の日本語版にアップグレードしたいため「Windows 2016 Japanese Installation Media」を選択します。選択後に右上のアクション⇒スナップショットからボリュームを作成をクリックします。
ボリュームの作成画面となるため、内容を確認後、ボリュームを作成します。変更点は作成対象のAZや名前ぐらいで後はデフォルトのまま進めます。
↓
作成されたボリュームをアップグレード対象のEC2にアタッチします（手順は簡単なためここでは省略します）。
アップグレードの実行
インストールメディアのEBSがアタッチされると、EC2（Windows OS）に新しくドライブが追加されます（既存ドライブ構成によりますがDやEドライブ等として追加される）。ここではEドライブで追加されたとして進めていきます。Windows PowerShellを起動し、次のコマンドを入力してアップグレードを実行します。
# ドライブeに移動
e:
# セットアップ実行
./setup.exe /auto upgrade /dynamicupdate disable※「dynamicupdate disable」はアップグレード中の更新を無効化するオプションです。エラー発生の可能性を軽減する。更新といっても具体的なKBがインストールされるわけではありません。アップグレード後に確実にKBをあてていきましょう。
セットアップ画面が表示されるため、後は手順に沿って実施を進めます。
↓ 約5分
イメージの選択となるため、アップグレード対象のイメージを選択します。
ここで異なるエディション（例えば元々の環境がデスクトップだったが、非デスクトップにアップグレード）は、アプリや設定を引き継ぐことが出来ないため注意しましょう。一般的には同じエディションを選ぶかと思いますが・・・。
↓
↓
↓
イメージの選択画面から約15分～約20分後に、ようやく確認画面にたどり着きます。
「次の作業が必要です」
Windows Server のアップグレードはお勧めしません。最適な結果を得るためには、Windows Server 2016 をクリーン インストールしてください。アップグレードが必要な場合は、続ける前に、お使いのアプリがWindows Server 2016 に対応していることを確かめてください。アップグレード前後に行う推奨手順がある場合は、それに従ってください。詳細については、http://go.microsoft.com/fwlink/?LinkId=243105 を参照してください。重要：ソフトウェアが Windows Server 2016 に対応していない場合や、アプリ ベンダーがアプリをサポートしていない場合は、Windows をインストールする前にそのアプリをアンインストールしてください。このようなアプリをアンインストールしないと、システムが正しく動作しなかったり、アプリが動作しなかったり、設定やその他の情報が失われたりする可能性があります。
・・・と書きましたが、つまり最後の警告ですね。必ず表示されるようです。アップグレードは出来ますけど、自己責任で実施してくださいねってことです。
- 引き継ぐものを変更
→ 「イメージの選択」画面に戻ります。 - 情報の更新
→ 特に何も起こりません。
「確認」ボタンが表示されていない場合はクリック後に暫くすると表示されるようになります。 - 確認
→ 次へ進みます。
内容は理解したため、「確認」をクリックして次に進みます。
インストールがついに始まります。
再起動中（約1時間弱）はリモートデスクトップで接続することが出来ないため、不安です。アップグレードが進行中かどうかは、インスタンスのスクリーンショットを取得して確認すると不安を少しでも取り除くことが出来ます。
アップグレードが完了するとリモートデスクトップでログイン可能です。コンピュータ情報を確認すると無事に「2016」になっていました。
特にソフトウェアの互換性問題がなければ、比較的にわかりやすく進めることが出来ると思います。
EBSのデタッチ
アップグレードが正常に完了したのであれば、インストールメディア用のEBSは不要になります。具体的な手順は特に載せませんが、以下の対応をしましょう。
- 該当EBSをデタッチする。
- 該当EBSが不要であれば削除する。
その他
インプレースアップグレードの場合、回復操作に備えて「windows.old」フォルダが残り、それなりの容量（20GB等）を消費しています。しかし10日経過すると自動的に削除されるため、気にする必要はないでしょう。
その一方で容量カツカツですぐに削除したい場合はディスクのクリーンアップから削除することが出来るようです（未検証）。
自動アップグレードの手順
概要
AWS公式サイト上の手順は以下になります。
- 該当EC2を直接アップグレードするわけではありません。
- SSMのAutomationを開始すると、該当EC2から一時的なAMIが作成され、それを元にインターネット接続可能なサブネット上で仮EC2が自動起動し、アップグレードが行われます。
- 最後に、仮EC2からAMIが作成されてSSMのAutomaitionは終了となります。
全体的な流れは次の通りです。
- SSMのAutomaitionで「AWSEC2-CloneInstanceAndUpgradeWindows」を実行する。
- アップグレードされたAMIよりEC2を起動する。
本手順は該当EC2が直接アップグレードされるわけではありません。
対応時間は大きな問題がなければ約2～３時間です。
- 上記記載の通り対象EC2にSSM Agentが必要になるためSSM Agentがインターネット経由や社内プロキシ経由等でAWS側と通信できる必要があります。
- 自動アップグレードWindows インスタンス上のルートボリュームに十分な空きディスク容量があることを確認します。20GB程度は必要です。不足しているとアップデート前のチェックでエラーになります。
- 仮EC2が起動するためのサブネットは自動割り当てパブリック IPv4 アドレスがtrueである必要があります。さらに該当サブネットからはパブリックIPv4を利用して、AWSやMicrosoftにアウトバンド接続できる必要があります。（わざわざパブリックIPv4を利用することから、恐らく社内プロキシ経由は厳しいです。）
- ホスト名が一時的に重複するため、問題ないサブネットを指定しましょう。
他にも細かい前提条件がありますが、詳細は上記のAWS公式サイトから確認可能です。
今回はお試し実施になるため、バックアップ（AMI）から検証用EC2を作成してアップグレードをしてみました。個人的にはサブネットの制約が厳しかったですが・・・。
Automation実行
AWS Systems Managerサービスに移動し、メニュー「自動化」を選択すると、オートメーション画面が表示されます。続いてオートメーションの実行をクリックします。
ドキュメントの選択画面となるため「AWSEC2-CloneInstanceAndUpgradeWindows」を選択して「次へ」をクリックします。
＊なお、AWSEC2-CloneInstanceAndUpgradeWindows2019はAWSEC2-CloneInstanceAndUpgradeWindowsのサブモジュールです。選択しません（だったら画面に出さないで欲しい・・・）。
↓
必要なパラメータを入力します。
- インスタンスID
- IamInstanceProfile
⇒ AmazonSSMManagedInstanceCoreが含まれるIAMロールを入力します。 - SubnetId
⇒ アップグレード用の仮EC2が起動するサブネットです。外部接続可能＆自動パブリックIP割付が有効なサブネット名を入力します。 - TargetWindowsVersion
⇒ 2016を選択します。 - BYOLWindowsMediaSnapshotId
⇒ オプション。持ち込みライセンスの場合に使うようです。 - AlternativeKeyPairName
⇒ オプション。対象EC2にキーペアが無い場合は、任意キーペア名を入力します。 - KeepPreUpgradeImageBackUp
⇒ オプション。アップグレード用の仮EC2を起動するために、現EC2のAMIを作成しますが、それを残すがどうか。デフォルトは残さない。 - RebootInstanceBeforeTakingImage
⇒ 上記AMI作成前にEC2を再起動させるかどうか。デフォルトは再起動しない。
入力・選択を終え、実行ボタンをクリックすると、オートメーションが実行されます。ここから約2時間～3時間かかります。
以下が自動的に行われます。
- 既存EC2から仮AMI作成
- 仮AMIから仮EC2作成（AWSEC2_UpgradeInstance_…）
- 仮EC2アップグレード ← ここが長い
- 仮EC2からアップグレード済AMI作成
数々のステップで構成されています（内部には多くのサブステップがあります）。
無事にAutomationが完了すると、アップグレードされたAMI（AWSEC2_UPGRADED_AMI_TO_2016_FOR_INSTANCE_i-02 …）が自動的に作成されます。
Automationは多くのステップで構成されています。実際に試してみると途中で失敗するケースも多いと思います。以下、私が遭遇したエラーを載せておきます。
- 「assertSubnetHasAutoAssignIPV4」
Step fails when it is Execute/Cancelling action. Property value ‘False’ from the API output is not in the desired values. Desired values: [‘True’].. Please refer to Automation Service Troubleshooting Guide for more diagnosis details.
→ サブネットの自動割り当てパブリック IPv4 アドレスがtrueになっていない。trueにしましょう。 - 「runUpgradeFrom2012R2Or2016（serverUpgradeInstanceWithOriginalKeyPair）」
→ Automation Step Execution fails when it is launching the instance(s). Get Exception from RunInstances API of ec2 Service. Exception Message from RunInstances API: [The key pair ‘{{ describeOriginalInstanceDetails.KeyName }}’ does not exist (Service: AmazonEC2; Status Code: 400; Error Code: InvalidKeyPair.NotFound; Request ID: xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxx; Proxy: null)]. Please refer to Automation Service Troubleshooting Guide for more diagnosis details.
→ EC2にキーペアが存在しない。対処方法としてAutomation実行時にキーペアをオプション指定してあげましょう。 - 「runUpgradeFrom2012R2Or2016（assertSupportedWindowsVersion2019）」
→ Validate-InstanceLicensing : Unable to connect to the remote server …..
→ 通信エラー。ということなので、該当サブネットのアウトバウンド接続を確認します。
AMIからEC2起動
アップグレードされたAMIは作成されました。
ここでは具体的な手順までは書かないですが、次のような選択肢になるかと思います。
- 現EC2を停止または終了して、新EC2をAMIから起動する。
- 新EC2をAMIから起動し、並行期間を経た後に、旧EC2を停止または終了する。
※ドメイン参加の場合はホスト名の重複に注意する。
最後の一手間ですね。本当は自動アップグレードでも既存EC2をアップグレードできるオプションが欲しいですが、失敗時のEC2に対するロールバック処理を考慮すると、複雑化してしまうため、その選択肢は無いのでしょうね。
(その他) Windows update
Windows 2016の場合、結構大変です。
基本は
- サービス スタック更新プログラム
- 累積更新プログラム
を適用することになりますが、いきなり最新の累積パッチ適用は恐らくエラーになります。累積更新プログラムは2018年5月提供の「KB4103723」辺りを最初にあてたほうが良いでしょう。サーバ性能によりますが、最新含めた全部の適用が終わるまで2時間～4時間はかかるでしょう。
Trusted Advisorで怒られるんだけど・・・
「Microsoft Windows Server を使用する Amazon EC2 インスタンスのサポートの終了」
もう2012じゃないのに、なんでや・・・。
こんな警告です↓
最後に黄色線を引きましたがどうも「EC2Config」が使われているっぽいです。
★以下、Systems Managerのパッケージを使った簡単な解決方法★
run commandが実行できるのであれば、パッケージ「AWSEC2Launch-RunMigration」を利用して簡単に移行可能です。（ドキュメントの説明：Command document for migrating from EC2Config and EC2Launch v1 to EC2Launch v2）
1分程度で実行完了するので簡単です。
まとめ
本記事ではAWS上のWindows Server 2012 R2をアップグレードする手順についてご紹介しました。
- アップグレードの選択肢
- インプレースアップグレードの手順
- 自動アップグレードの手順
個人的には既存アプリに互換性問題がないのであれば、既存EC2をアップグレードする方法（インプレースアップグレード）が楽かなと思いました。多くの検証が必要なサーバ・アプリケーションもあると思いますので、早めに行動できればなと思います。
本記事が、これからWindows Server 2012R2をアップグレードされる方々等、お役に立てれば幸いです。
最後までご覧いただき、ありがとうございました。
コメント