Windows Server 2019（1809）へ移行したあと、「Windows 10みたいにWindows Updateから1909へ上げたいのに出てこない」と戸惑うケースは少なくありません。結論から言うと、Serverは“更新の考え方”がクライアントOSと違い、さらにサービシングチャネル（LTSC / SAC）の違いが大きく影響します。1909へ上げられる条件と、ISOを使った現実的な更新手順を整理します。
Windows Server 2019（1809）から1909へ上がらない“本当の理由”
まず押さえるべきポイントは2つです。
- Windows Serverは、Windows 10のように「Windows Updateの画面で機能更新（1809→1909）を選んで実行する」運用が基本ではない
- 「1809」「1909」という数字は“サービシングチャネル”と結び付いており、同じ1809でもLTSC（Windows Server 2019）とSAC（Windows Server, version 1809）が混在する
この2点を見落とすと、「Windows Updateに1909が出てこない＝設定がおかしい」と誤解しがちです。実際は、そもそもWindows Updateで1909へ上がる設計ではない、または1909へ“アップグレードできる前提（SAC）ではない”というケースが多いです。
用語整理：LTSCとSAC、そして“1809/1909”の関係
Windows Serverには大きく分けてLTSC（長期サポート）とSAC（半期チャネル）があり、当時の“1909”は主にSAC側のリリースとして扱われました。ここが混乱の元です。
| 観点 | LTSC（例：Windows Server 2019） | SAC（例：Windows Server, version 1909） |
|---|---|---|
| 想定用途 | 安定運用（基幹系、AD、ファイルサーバー等） | 短いサイクルで更新（コンテナ/DevOps寄り、検証・用途限定） |
| サポート期間の考え方 | 長期（運用の腰を据える） | 短期（計画的に上げ続ける前提） |
| 更新スタイル | 月例の累積更新（品質更新）が中心 | リリース間の更新が前提（ただし計画・手順が重要） |
| 1809→1909の扱い | “Windows Server 2019（LTSC）を1909へ”という概念自体がズレやすい | SAC 1809→SAC 1909という形なら“上書きアップグレード（インプレース）”が現実的 |
つまり、同じ「1809」でも、あなたの環境がLTSC（Windows Server 2019）なのか、SAC（Windows Server, version 1809）なのかで、1909への進め方は大きく変わります。
最初にやること：自分のサーバーがLTSCかSACか確認する
ここが分かれば、迷いがほぼ消えます。GUIがある場合でも、サーバー運用ではコマンドで確認できるようにしておくと便利です。
| 確認方法 | コマンド / 操作 | 見どころ | 補足 |
|---|---|---|---|
| winverで確認 | winver | バージョン表記、ビルド番号 | 表示は似るので、これだけで断定しない |
| systeminfoで確認 | systeminfo | OS Nameや製品名 | 「Windows Server 2019」と出るかをチェック |
| PowerShellで確認 | Get-ComputerInfo | Select WindowsProductName, WindowsVersion, OsBuildNumber | WindowsProductNameの文字列 | Server Coreでも使いやすい |
| レジストリで確認 | reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v ProductName | ProductNameの内容 | 構成管理で収集しやすい |
| DISMでエディション確認 | DISM /online /Get-CurrentEdition | 現在のエディション | エディション切替の話と混同しない |
判断の目安としては、「Windows Server 2019」と明示される（LTSC）のか、あるいは「Windows Server, version 1809」等の表現が強い（SAC）のかを見ます。現場では「2019（1809）」と呼んでいても、実はSAC版を入れていた／逆にLTSC版を入れていた、というすれ違いが起きやすいので、ここは丁寧に確認してください。
結論：1909へ上げるルートは“Windows Update”ではなく“ISO（セットアップ）”が基本
Windows Serverでは、クライアントOSのように「更新プログラムの確認」→「1909へ機能更新」という導線が一般的ではありません。1909へ上げたい場合は、原則としてインストールメディア（ISO）を使ってアップグレード（上書き）するか、クリーンインストールで入れ替える形になります。
ここからは、あなたの環境がSACで“上書きアップグレード可能”なケースと、LTSCで“1909というゴール設定がズレている”ケースに分けて、現実的な手順を解説します。
SAC版（Windows Server, version 1809）を使っている場合：1909へ上書きアップグレードする
SACを採用している環境なら、リリース間の更新（1809→1909）は運用設計の範囲内です。ただし、サーバーの上書きアップグレードは影響範囲が大きいため、可能であっても「クリーンインストール（入れ替え）の方が安全」という判断になることも多いです。
上書きアップグレードを実行する前のチェックポイント
「setup.exeを実行すれば上がる」とはいえ、サーバーは役割（ロール）やドライバー、セキュリティ製品、業務アプリの影響を強く受けます。最低限、次のチェックを推奨します。
| チェック項目 | 具体的な確認内容 | 理由 |
|---|---|---|
| フルバックアップ | システム＋データ（可能ならベアメタル復旧まで） | 失敗時に“戻れる”ことが最重要 |
| 役割（ロール）棚卸し | AD DS / DNS / DHCP / IIS / ファイルサーバー / Hyper-V など | ロールにより推奨移行手法が変わる |
| 業務アプリの要件確認 | OSバージョン要件、.NET、SQL、ドライバー依存 | 動作保証外になると復旧が難しくなる |
| セキュリティ製品 | EDR/AV、フィルタードライバー、暗号化ソフト | アップグレード失敗の原因になりやすい |
| 空き容量 | システムドライブに十分な空き（数十GB目安） | 一時ファイル・ロールバック領域が必要 |
| メンテナンス時間 | 停止可能時間、再起動回数、影響範囲 | 想定より時間が延びることがある |
1909のISOを使った上書きアップグレード手順（基本ルート）
手順の流れはシンプルで、ISOを入手 → マウント → setup.exe実行です。Windows Updateに出てこない問題に対しては、これが最短ルートになります。
- Windows Server v1909 のISOを入手 入手経路は契約形態で変わります。一般的にはボリュームライセンスの提供ポータルや、サブスクリプション（例：開発者向けの提供）などが対象です。古いSACのISOは“いつでも誰でもダウンロードできる”形ではないことが多いため、社内のライセンス管理担当や調達フローも確認しておくとスムーズです。
- ISOをマウント GUIならISOを右クリックして「マウント」。Server Coreやリモート運用ならPowerShellが便利です。
Mount-DiskImage -ImagePath "C:\ISO\WindowsServer_1909.iso"マウント後、ドライブレター（例：D:）が割り当たります。 - setup.exeを実行してアップグレード マウントしたドライブ内の
setup.exeを起動し、ウィザードに従います。基本は「アップグレード（上書き）」の流れで進み、可能であれば引き継ぎ（アプリと設定、ファイル）を選択します。D:\setup.exe無人化や遠隔操作を前提にする場合は、事前検証のうえでコマンドラインオプション（例：自動アップグレード）も検討できます。D:\setup.exe /auto upgradeただし、サーバーは環境差が大きいため、いきなり本番で自動化するより、まずは検証環境で“手動で成功する”ことを確認してからが安全です。 - 完了後の確認 アップグレード完了後、OSバージョンやビルド番号、ロールの稼働、イベントログ、アプリの疎通を確認します。
winver Get-ComputerInfo | Select WindowsProductName, WindowsVersion, OsBuildNumber最後に、月例の累積更新（品質更新）を適用してセキュリティレベルを揃えます。WSUS運用の場合は承認状況も忘れずに確認してください。
上書きアップグレードよりクリーンインストールが推奨されやすい理由
サーバーは“長期にわたる運用の積み重ね”で、知らないうちにドライバーやフィルター、古いランタイム、レガシー設定が層のように残ります。上書きアップグレードは便利ですが、問題が起きたときに原因が追いにくいのが欠点です。
そのため、特に次の条件に当てはまる場合は、最初からクリーンインストールでの入れ替えを検討する価値があります。
- 基幹系の役割（AD、DNS、ファイルサーバー等）で、止まると影響が大きい
- 古いドライバーやセキュリティソフト、独自フィルターを多用している
- 原因不明の不調が既にある（アップグレードで増幅することがある）
- 今回を機に構成を整理したい（不要な機能・アプリを排除したい）
LTSC版（Windows Server 2019）を使っている場合：1909へは“更新”ではなく“別OSへの入れ替え”になる
もしあなたの環境がWindows Server 2019（LTSC）であれば、「1909へ上げる」という発想自体を一度見直すのが近道です。1909はSAC側のリリースとして扱われるため、Windows Server 2019（LTSC）をWindows Updateで1909へ機能更新するというルートは期待通りに動きません。
この場合、現実的な選択肢は次のどちらかになります。
- Windows Server 2019（LTSC）のまま運用し、Windows Update（またはWSUS）で累積更新を適用して最新化する
- どうしても1909相当のSACが必要なら、Windows Server, version 1909を新規インストールして入れ替える（クリーンインストール）
「1909にしたい理由」が、例えばコンテナのホスト/イメージ互換や検証用途で短期的に追従したいといったSAC向きの目的なら、最初からSACとして別サーバーを用意して移行する方がトラブルを減らせます。一方で、ADやファイルサーバーなどの安定運用が目的なら、LTSCのまま堅実に更新する方が合理的です。
クリーンインストールで1909へ入れ替える手順（安全にやるための現場ノウハウ）
クリーンインストールは手間がかかりますが、成功確率が高く、障害時の切り分けも簡単です。特に本番環境では「上書きアップグレードが通るかどうか」というギャンブルを避けられます。
クリーンインストールの全体像
- 新サーバー（1909）を用意して新規インストール
- 必要なロール・機能を最小構成でセットアップ
- データと設定を移行（アプリは再インストール前提）
- 切り替え（DNS、名前解決、負荷分散、共有パス、証明書等）
- 旧サーバーの停止・撤去（一定期間はロールバック用に残すのも手）
ブート可能USBの作成（例）
ISOからUSBを作る方法はいくつかありますが、社内標準があるならそれに合わせるのが最優先です。一般的には、マイクロソフト純正ツールや信頼できる作成手順に沿って、UEFI/BIOSやファイルシステム（FAT32/NTFS）を意識して作成します。ハードウェアにより起動要件が違うため、本番サーバーで事前に起動テストだけでもしておくと安心です。
移行でつまずきやすいポイント（ロール別）
「データをコピーすればOK」とはいかないのがサーバー移行です。役割ごとに注意点があります。
| ロール/用途 | 推奨アプローチ | 注意点 |
|---|---|---|
| Active Directory（ドメインコントローラー） | 新DC追加→複製→FSMO移行→旧DC降格 | 上書きアップグレードより“増設入替”が安全 |
| DNS/DHCP | 役割移行（エクスポート/インポート） | スコープ、オプション、固定割当、予約の移行漏れに注意 |
| ファイルサーバー | 共有・NTFS権限を保持してコピー（Robocopyなど） | ACL、所有者、監査、共有権限、DFSを含めて設計 |
| IIS（Web） | サイト/証明書/アプリプールの移行＋再デプロイ | 証明書と暗号スイート、フレームワーク依存に注意 |
| Hyper-Vホスト | 別ホスト用意→VM移動（クラスター含む） | 仮想スイッチ、NICチーミング、ストレージ設計を再確認 |
たとえばファイルサーバーなら、データ移行だけでなく、権限と属性を壊さないコピーが重要です。代表例としてRobocopyを使う場合は、オプション次第で結果が大きく変わります。
robocopy \\oldserver\share D:\share /MIR /COPY:DATSOU /DCOPY:DAT /R:2 /W:5 /MT:16 /LOG:C:\temp\robocopy.logこの例はあくまで方向性で、監査や属性、ジャンクション、除外、業務時間帯の増分コピーなど、環境に合わせた調整が必要です。重要なのは「一発で全部移す」より、事前に同期して差分を小さくし、切り替え当日に停止時間を短くする設計です。
上書きアップグレードとクリーンインストール、どちらを選ぶべきか
迷ったら、次の表で判断すると現場でブレにくくなります。
| 判断軸 | 上書きアップグレード（インプレース） | クリーンインストール（入れ替え） |
|---|---|---|
| 停止時間 | 比較的短くしやすい（ただし延びることも） | 切替設計次第で短縮可能（事前同期が鍵） |
| 失敗時の復旧 | ロールバックに依存しがち | 旧環境を残せば切り戻しが明確 |
| 構成のクリーンさ | 過去の遺産が残る | 最小構成から再構築できる |
| 推奨されやすいケース | 用途が限定的／構成が単純／検証済み | 基幹系／長期運用／複雑な依存関係がある |
「サーバーを止められない」＝上書きアップグレードが最適とは限りません。むしろ、移行設計を丁寧に行えばクリーンインストールの方が切り戻しを含めて安全に進められることがあります。
「Windows Updateに出てこない」以外にもある、更新が進まない典型原因
今回の主題は“機能更新が出てこない”ですが、実運用では品質更新（累積更新）も含めて、更新が止まる原因が混ざることがあります。切り分けとして、次の観点を押さえておくと無駄な遠回りを減らせます。
- WSUS運用：クライアント同様、サーバーも承認されない限り更新が降りません。まずは承認・分類・対象グループを確認。
- GPO（ポリシー）：更新の延期、再起動制御、配布元（WSUS）設定で想定外の挙動になることがあります。
- メンテナンスウィンドウ：再起動が必要な更新が積み残されると、次の更新が適用されにくくなることがあります。
- サーバー用途：クラスターや仮想化ホストは、更新手順（順序・ノード切替）を守らないと事故になりやすい。
ただし、“1809→1909が出てこない”という点に関しては、設定不備よりもチャネルの違い／更新経路の違いが原因であることが圧倒的に多いです。
よくある質問（現場で実際に迷うポイント）
ライセンスキーだけで運用しているが、ISOが必要？
必要になることが多いです。Windows Serverのバージョンを跨ぐアップグレードや入れ替えは、基本的にインストールメディア（ISO）ベースで進めます。Windows Updateは主に品質更新の配布経路であり、OSそのものの“リリース更新”を期待すると齟齬が起きます。
1809のまま最新化したい。1909にしないとダメ？
用途次第です。安定運用が目的なら、LTSC（Windows Server 2019）を継続し、累積更新を適用して最新状態に保つ方が運用は楽です。逆にSACが必要な理由（コンテナ互換など）が明確なら、SAC前提で計画的に更新できる体制を整えるのがポイントです。
本番サーバーで上書きアップグレードはやっていい？
不可能ではありませんが、推奨は「検証→手順確定→バックアップ→メンテナンスウィンドウ確保→実施」です。特にドメインコントローラー等の重要ロールは、上書きアップグレードより増設して切り替える移行の方が安全なことが多いです。
まとめ：1909へ上げたいなら、最初に“チャネル”を確定し、ISO前提で計画する
- Windows Server 2019（1809）をWindows Updateから1909へ上げる、という発想はズレやすい
- まずLTSCかSACか（サービシングチャネル）を確認し、1909が対象になるか判断する
- SACであれば、ISOをマウントしてsetup.exeで上書きアップグレードが基本ルート
- 安定運用や重要ロールなら、クリーンインストールでの入れ替えが結果的に安全で早いことも多い
- どちらにせよ、バックアップと検証環境での事前確認が最重要
コメント