背景

Windows Server 2016は、2027年1月12日でサポートが終了する予定です。

2025年7月現在、まだ1年以上先の話ですが、基幹システムなどでは稟議や見積のスケジュールを考えると「そろそろ準備だ」という組織も出てきているでしょう。
Windowsのアップグレード先の選択肢としては、特に技術的制約が無ければ Windows Server 2025が第一優先として挙げられるでしょう。

先日、AWSのマネージメントコンソールで Windows 2025 Japanese Installation Media のパブリックスナップショットが公開されていることに気付きました。
当初は探しても English しか見当たらなかったはずでした。
これがあれば日本語のWindowsで直接アップグレードできるはず！と思って、試してみました。

そもそもサポートされているのか

Windows 2016 から 2025 に直接アップグレードってサポートされてるの？

不明だったのでマイクロソフトの公式情報をあたってみます。
https://learn.microsoft.com/ja-jp/windows-server/get-started/upgrade-overview

抜粋
Beginning with Windows Server 2025, nonclustered systems can upgrade up to four versions at a time.

お！Windows 2025 からは 4つ前のメジャーバージョンからの直接アップグレードがサポートされるようになっています！
Windows 2012 や Windows 2016 からも直接アップグレード可能ということになります。安心して進められますね。

同じEC2インスタンスのままでアップグレードできるの？

はい。それは以前から可能です。
EC2上でWindowsのインプレースアップグレードを実行するためのガイドがあります。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/os-inplaceupgrade.html

というわけで、進めていきます。

作業の流れ

今回は確認したいポイントがいくつかあるため、テスト環境を整備して進めます。
以下の流れです。

作業準備
- テスト用Windows 2016の作成（ローンチ）
- アップグレード後に確認するためのいくつかの設定
★メイン作業★
- Installation Mediaを含むEBSボリュームの準備
- インプレースアップグレードの実施
作業後の確認
- 空き容量の変化は？
- アップグレードで何が維持されるのか

アップグレードそのものの手順と実績だけ知りたい場合は、★メイン作業★を見てください。

作業準備

テスト用Windows 2016のローンチ

AWSのパブリックAMIを検索します。
Server-2016-Japanese-Full-Base を含むAMI名で検索すると、いくつかヒットします。
所有者のエイリアスが Amazon であることを確認してから（ここ大事）、検証時点(2025/7/12)の最新のものを選びました。

簡単なWebサービス(IIS)も確認したかったので、セキュリティグループは RDP(3389) と HTTP(80) を有効にしました。

ユーザーデータ(EC2ローンチ時の実行スクリプト)も使ってセットアップします。

<powershell>
tzutil.exe /s "Tokyo Standard Time"

Install-WindowsFeature Web-Server -IncludeAllSubFeature -IncludeManagementTools

$htmlContent = @"
<!DOCTYPE html><html>
<head><title>My EC2 Web Server!</title></head>
<body>
<h1>Hello!</h1><p>My Web Server!</p>
</body>
</html>
"@
$htmlContent | Out-File -FilePath C:\inetpub\wwwroot\test.html -Encoding utf8

New-NetFirewallRule -DisplayName "HTTP-In" -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow -Profile Any

Rename-LocalUser -Name Administrator -NewName svadmin
</powershell>

ユーザーデータでは、

タイムゾーンをTokyoに設定
IISのインストールとtest.htmlの配置
Windowsファイアウォールで80番ポートの許可
ビルトイン管理者のユーザー名を Administrator から svadmin に変更

を実行する内容です。
アップグレード後の確認のために設定します。

その他、検証に必要な設定をざっと入れました。

新規のキーペア
EBSボリュームのサイズは 36 GB
フリートマネージャーを使いたいので AmazonSSMManagedInstanceCore ポリシーを含むIAMロールを事前に作成して設定
インスタンスタイプは t3.medium
パブリックサブネット
パブリップIPあり（Elastic IP無し）

アップグレード後に確認するためのいくつかの設定

ローンチ4分後に、キーペアでパスワードを復元して確認します。
その後、Windows Serverへリモートデスクトップ接続でつなぎます。
IISのインストールがあるので、ユーザーデータのPowerShellが全て実行し終えるまで15分程度かかります。そのため最初はAdministratorでログインできてしまいました。
15分経つとsvadminでのみログインできるように変わりました。

Web接続もしてみます。
デフォルトのパス / も、作成したページ /test.html も、表示OKです。

さらにいくつか設定します。

アップグレード中の空き容量の確認

以下のPowerShellで、ディスクの空き容量を1分おきに取得して、ファイルに書き出します。
この ps1ファイルをタスクスケジューラーのシステム起動時トリガーでセットします。

New-Item -ItemType Directory -Path "C:\temp\log" -Force

$log = "C:\temp\log\windows-info.log"

for ($i = 1; $i -le 180; $i++) {
  "===================" | Out-File -Append $log
  Get-Date -format "yyyy/MM/dd HH:mm:ss" | Out-File -Append $log
  "C Drive Free(GB): " + $((Get-PSDrive C).Free / 1GB) | Out-File -Append $log
  Start-Sleep -Seconds 60
}

一部Windowsサービスの停止

wuauserv（Windows Update）とSpooler（Print Spooler）のサービスを停止＆無効にします。

Set-Service -Name wuauserv -StartupType Disabled
Stop-Service -Name wuauserv -Force
Set-Service -Name Spooler -StartupType Disabled
Stop-Service -Name Spooler -Force

spoolerの方は無効のままで、wuauservの方は勝手に無効→自動にされてしまうはずと予想します。どうなるかな。

フォルダの権限設定、共有フォルダ(SMB)の設定、

C:\temp フォルダにアクセス権の設定として、Guestアカウントの拒否設定を入れてみC:\temp を共有フォルダ(SMB)設定をします。こちらも同様に、Guestアカウントの拒否設定を入れてみます。
この変更点は、維持されるべきところですね。

状態の取得

いくつかのコマンドで、PowerShell、IIS、Windowsのバージョンを取得しておきます。
Windowsのバージョンは、Windows 2025 ではインストールされない wmic をあえて使って取得します。アップグレード後にも wmic が使えるでしょうか。

> # PowerShellのバージョン
> $PSversiontable

Name                           Value
----                           -----
PSVersion                      5.1.14393.8146
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.8146
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

> # IISのバージョン
> (Get-ItemProperty "HKLM:\Software\Microsoft\InetStp").VersionString
Version 10.0

> # Windowsバージョンを非推奨コマンドで取得
> wmic os get version
Version
10.0.14393

さて、ここまでがテスト環境の準備でした。

★メイン作業★

ここからがメインのアップグレード作業となります。
一昔前でいうところの、DVDのインストールメディアを入れてアップグレード、というイメージに近い作業です。

本番環境で実施する場合は、事前にAMI作成などのバックアップを取っておいたほうが良いでしょう。

Installation Mediaを含むEBSボリュームの準備

スナップショットの検索

パブリックスナップショットを選択して、 Windows 2025 を入力して検索します。
執筆時点(2025年7月13日)では、3言語のみでした。
念のため、所有者のエイリアスが Amazon であることを確認（ここ大事 2回目）。

スナップショットの左にチェックを入れる
アクション　＞　スナップショットからボリュームを作成 を選択
ボリュームの作成

アベイラビリティゾーンをEC2と同じものに合わせる必要があるので注意。ポチポチと押してしまって見落としがち。

EBSボリューム一覧で、対象ボリュームの左にチェックを入れる
アクション　＞　ボリュームのアタッチ を選択
対象インスタンスを選択
デバイスは、後ろの方の空いているデバイスを適当に選択
EC2にアタッチ
Windowsが自動的に認識してオンラインに

自動的にオンラインにならない場合は、ディスクの管理を開いて認識させます。
以下はDドライブとして認識した例です。

インプレースアップグレードの実施

Installation Mediaがドライブとして認識されたら、後は簡単です。
コマンドを1つ実行して、あとは数回のボタンクリックするだけでアップグレードされます。
Cドライブの空き容量もちゃんと10GB以上を確保して進めます。
超簡単ですね（前フリ）。

PowerShellコンソール（またはコマンドプロンプト）を管理者権限で起動
setup.exe を適切なオプションで実行

以下は、D:ドライブにインストールメディアがある場合の例です。setup.exeのスイッチオプションは、AWSガイドに従って指定します。

cd D:
.\setup.exe /auto upgrade /dynamicupdate disable

セットアップ画面が開く
イメージの選択

パブリックAMIで通常のWindowsをローンチしているので Datacenter (デスクトップエクスペリエンス) です。

ライセンス状況画面で同意するボタン

空き容量不足でエラー

はい、エラーになりました。❌
Cドライブを 10 GB 空けていたのですが、、、ダメでした。

リトライして、Cドライブを 11 GB 空けるも、再び容量不足エラー
リトライして 12 GB 空けるもエラー
リトライして 14 GB 空けるもエラー
　　：
　　：
リトライして 20 GB 空けるもエラー
リトライして 22 GB 空けるもエラー

以下は、20 GBでの失敗

最終的に、空き容量 24 GB で次に進みました！
超簡単じゃなかった。。。
10.0 GB 以上の空き、なんて言う画面表示の数字は、全くあてになりません。
Cドライブの使い方によっては、もっと空きが必要になるケースもあるかもしれません。

ただ、ここを過ぎれば本当に簡単です。
何も入力せずに、待つだけで最後まで進みました。

「で、かかった時間は？」
そこが気になりますよね。
参考までに今回のケースでは、1時間10分でした。
3つのメジャーバージョンのジャンプにしては、早いな、と思います。
ただ、AWSのAMIからローンチした直後である点、簡単な IIS のみである点が早かったポイントとおもいますので、時間は環境次第で変わるしょう。

Installation MediaのEBSボリュームの切り離し

Windowsアイコンを右クリックして、ディスクの管理
ディスクの管理で、対象の「ディスク N」を右クリック、オフラインを選択
マネージメントコンソールで、EBSボリュームを選択
アクション ＞ ボリュームのデタッチ
EBSボリュームの削除 (他のEC2で使わない場合)

として不要になったメディアを削除します。

作業後の確認

アップグレード後に色々とアップグレード前の状況と比較してみました。

空き容量の変化は？

アップグレードが終わった直後は、なぜかアップグレード前より空き容量が増えていました。
メジャーバージョンが3つも上がったのに、Windows 2025の方が空いたのです。

24 GB ってのは何だったんだよ！と思いましたが、1分おきに出力するログを見て分かりました。
一時期に空き容量が 2.8 GBまで減っていました！
最初の見積もりで 24 GB の空きが必要、というのはおおよそ正しかったことになります。
疑ってすみませんでした。

===================
2025/07/13 19:35:59
C Drive Free(GB): 24.5114822387695
===================
2025/07/13 19:36:59
C Drive Free(GB): 17.9594459533691
　：
　：
===================
2025/07/13 19:41:43
C Drive Free(GB): 7.005744934082
===================
2025/07/13 19:42:47
C Drive Free(GB): 2.83572387695313
　：
　：
===================
2025/07/13 20:32:06
C Drive Free(GB): 2.62591552734375
===================
2025/07/13 20:50:07
C Drive Free(GB): 26.5708427429199

アップグレードで維持される・されない

何点か確認したかったポイントを、テスト環境で整備していました。

簡単ですが、表でまとめます。

アップグレード前後の比較項目	維持されるか	コメント
ユーザー名をAdministratorから変更	維持される	問題なし
タイムゾーン	維持される	維持されて当然
IISバージョン	維持される	そもそも最新が 10.0
IISのWebページ	維持される	/ も /test.html もOK
外部からのポート80でのアクセス	維持される	HTTPSでなくてもOK
PowerShellのバージョン	維持される	5.1のまま
wmicの存在	維持される	アンインストールされなかった
フォルダのアクセス権限	維持される	問題なし
フォルダ共有(SMB)権限	維持される	問題なし
wuauservサービス無効化	維持されない無効→手動(トリガー開始)	変わるだろうと思ってはいた
Spoolerサービス無効化	維持されない無効→自動	予想が外れた

アップグレード後の、Windowsバージョンと、IISバージョンと、PowerShellのバージョンの出力です。
PowerShellは 5.1 ではあるものの、Windowsのバージョンと同じ数字 26100 が付いていて少し変わりました。

PS C:\Users\Administrator> wmic os get version
Version
10.0.26100

PS C:\Users\Administrator> (Get-ItemProperty "HKLM:\Software\Microsoft\InetStp").VersionString
Version 10.0

PS C:\Users\Administrator> $PSversiontable

Name                           Value
----                           -----
PSVersion                      5.1.26100.2161
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.26100.2161
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

まとめ

EC2で問題なくWindows Server 2016 を 2025 に直接アップグレードできました。

Windows Server 2025は、4つのメジャーバージョンを跨げたり、wmicを維持できたりするので、古いWindowsバージョンからの移行をしやすいように配慮している印象を受けました。

基幹業務で移行する際は、まだまだ前提チェックする項目はあるでしょうが、「ハードルが低そうかも」、と分かったのは収穫でした。
サポート切れのWindowsを使い続ける、というのをマイクロソフト社としても避けたいんだろうなと思ったりしました。