Windows Server 2022 オフライン更新方法|インターネット接続なしで最新Windows Updateを適用

Windows Server 2022 が社内の閉域網や検証ネットワークで稼働していて、サーバー自身はインターネットに接続できない――それでも脆弱性対策として「最新の Windows Update(主に累積更新プログラム)」を適用したい場面は多いです。本記事では、別PCで更新プログラムを入手してUSB等で持ち込み、確実にオフライン更新するための手順とつまずきポイントをまとめます。

目次

Windows Server 2022は「インターネット接続なし」でも最新更新を適用できる

結論から言うと、Windows Server 2022(Standard / Datacenter など)がオフライン環境でも、最新の累積更新プログラム(LCU)を含む Windows Update を適用できます。やり方はシンプルで、インターネットに出られる別PCで更新ファイル(.msu/.cab)を入手し、USBメモリ等でオフラインサーバーへ転送してインストールします。

オフライン環境であってもパッチ適用が重要なのは、USBや持ち込み端末、内部ネットワークからの侵入、横展開など「インターネット起因ではない攻撃」も現実的だからです。特にサーバーは役割(AD DS、ファイルサーバー、Hyper-V、IISなど)によっては停止できる時間が限られるため、安全に・手戻りなく更新するための段取りが欠かせません。

全体像:オフライン更新の“王道フロー”

工程実施する端末目的ポイント
KB番号の特定インターネット接続できるPC最新の累積更新(LCU)と前提条件を把握Update Historyで製品/ビルドを間違えない
更新ファイルの入手インターネット接続できるPCMicrosoft Update Catalogから正しいパッケージをダウンロードx64/ARM64、製品名表記ゆれに注意
整合性チェックインターネット接続できるPC改ざん・誤ダウンロードを防ぐデジタル署名/ハッシュを確認
持ち込み・検疫USB/共有フォルダ等オフライン環境へ安全に搬入ウイルススキャン、改ざん防止、ログ保全
インストールオフラインのWindows Server 2022更新適用(.msuはwusa、.cabはDISM)SSU→LCUの順序、再起動計画
適用確認オフラインのWindows Server 2022KB・ビルド番号・再起動要否の確認Get-HotFix / DISM / winver で二重確認

事前準備:失敗しないために最初に確認すること

「更新ファイルを持ってきたのに適用できない」「途中でエラーが出た」を避けるには、ダウンロード前の確認が重要です。特に Windows Server 2022 は同じ“Server 2022”でも、適用対象(製品表記・アーキテクチャ・更新の種類)を間違えると簡単に“適用不可”になります。

確認1:OSのエディション/インストール形態/アーキテクチャ

確認項目確認方法(例)なぜ必要?
エディション(Standard/Datacenter)systeminfo | findstr /B /C:"OS Name" /C:"OS Version"同じKBでも製品表記が異なる場合がある
Server CoreかGUI(Desktop Experience)か画面有無、または機能確認手順自体は同じだが、操作方法が変わる
アーキテクチャ(多くはx64)echo %PROCESSOR_ARCHITECTURE%Catalogでx64/ARM64を取り違えると適用不可

確認2:現在のOSビルドと、既に入っているKB

“最新更新”と言っても、更新は積み重なります。まず現状を把握し、更新順序や前提条件の不足を見落とさないようにします。

Windows Server 2022 は、Update History上でも「OS build 20348.xxxx」として扱われます。例えば手元のビルドが 17763 なら Server 2019 系、14393 なら Server 2016 系の可能性が高く、「Server 2022用のKBを持ってきても適用できない」典型パターンになります。

目的コマンド例見どころ
OSビルド表示winver「20348.xxxx」かどうか、更新後にビルドが上がるか
インストール済み更新(KB)の確認powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20"直近の累積更新が入っているか
パッケージ状態の確認dism /Online /Get-Packages /Format:Table | morePending状態がないか、適用済みか

確認3:バックアップとメンテナンスウィンドウ

  • 可能なら更新前にスナップショット(仮想環境)またはバックアップを取得します。
  • ドメインコントローラーやクラスターなど、役割によっては手順が変わるため、事前に復旧手順も用意します。
  • 「再起動が必要」になる前提で、停止できる時間と影響範囲を整理しておくと、運用が安定します。

更新プログラム入手の王道:Update Historyで最新KBを確認 → Microsoft Update Catalogでダウンロード

オフライン更新の最短ルートは、Windows Server 2022 の更新履歴(Update History)で“最新の累積更新(KB番号)”を特定し、そのKBを Microsoft Update Catalog で検索してダウンロードする方法です。製品名で探すより、KB番号で探す方が確実です。

ステップ1:Update Historyで対象のKB番号を特定する

更新履歴ページでは、次の点を意識して確認します。

  • 最新の「累積更新プログラム(Cumulative Update)」のKB番号(例:KB50xxxxxx の形式)
  • 前提条件(必要に応じてServicing Stack Update(SSU)や関連更新)
  • 通常版か、プレビュー版(Preview)か

運用上は、原則としてプレビューではなく、定例の累積更新(いわゆるPatch Tuesdayの更新)を選ぶのが無難です。緊急の帯域外(Out-of-band)更新が出ている場合は、同じ手順で適用できます。

ステップ2:Microsoft Update CatalogでKB検索し、正しいパッケージを選ぶ

Update Catalog では「KB番号」で検索します。検索結果には似た名称が並ぶことがあり、選び間違えると適用できません。以下の観点で見極めます。

チェックポイント見るべき場所判断のコツ
対象製品製品名(Product)「Windows Server 2022」または「Microsoft server operating system version 21H2」相当になっているか
分類Classification多くは「Security Updates」または「Updates」
アーキテクチャTitle / Products / Details基本はx64。ARM64を取り違えない
サイズ/更新日Last Updated / Size同一KBでも複数がある場合、更新日の新しい方が対象に合うことが多い

「Catalogに .msu が見当たらない」と感じるケースの多くは、製品名の表記ゆれで検索結果が散らばっている、またはKB番号を使わず製品名だけで探していることが原因です。迷ったら、更新履歴で確認したKB番号をそのまま検索するのが確実です。

ステップ3:必要になりやすい更新の種類を把握する

一般的に「まずは累積更新だけでOK」と言われがちですが、サーバー用途では追加で意識したい更新がいくつかあります。

種類目的補足
累積更新プログラム(LCU)OSの主要なセキュリティ/品質修正毎月更新。まずこれが本命
Servicing Stack Update(SSU)更新を適用する仕組み自体の更新不足するとLCUが失敗しやすい。最近はLCUに同梱されることもあるが要確認
.NET Framework の累積更新.NET関連の脆弱性/不具合修正役割やアプリによって重要度が上がる
Microsoft Defender の定義更新マルウェア検知の最新化オフラインの場合、定義ファイルを別途持ち込む運用が必要

ダウンロードした更新ファイルの整合性を確認する(改ざん対策)

Update Catalog から入手したファイルでも、運用上は「正しいファイルを取れているか」「壊れていないか」を確認しておくと、後工程の切り分けが速くなります。特に閉域では再ダウンロードが簡単ではないため、持ち込む前にチェックしておくのがおすすめです。

確認方法コマンド例ポイント
デジタル署名の確認powershell -NoProfile -Command "Get-AuthenticodeSignature 'C:\\Temp\\LCU-KBxxxxxxx-x64.msu' | Format-List"StatusがValidであることを確認
ハッシュ値の計算(社内手順がある場合)certutil -hashfile "C:\\Temp\\LCU-KBxxxxxxx-x64.msu" SHA256ハッシュを台帳に残すと、後から“同一ファイルか”確認できる

更新ファイルの種類とインストール方法(.msu / .cab)

Update Catalog から入手できるファイルは主に .msu と .cab です。どちらもオフラインで適用できますが、扱い方が異なります。

拡張子よくある中身推奨インストール方法コマンド例注意点
.msuWindows Update Standalone Installer用パッケージwusa(またはダブルクリック)wusa.exe "C:\\Updates\\windows10.0-kbXXXXXXX-x64.msu" /quiet /norestart適用後に再起動が必要なことが多い
.cabDISMで追加できるパッケージDISM /Online /Add-Packagedism /Online /Add-Package /PackagePath:"C:\\Updates\\KBXXXXXXX.cab"順序(SSU→LCU)を守る。エラー時のログ確認が重要

なお、.msu の中に .cab が入っていることもあります。より細かく制御したい場合は、expand コマンドで展開してCABを取り出し、DISMで適用する方法もあります(ただし通常は wusa で十分です)。

オフライン環境への持ち込み:USB運用で意識したいセキュリティ

「更新ファイルを持ってくる」という作業は、同時に“外部媒体の持ち込み”でもあります。更新を安全にするつもりが、USB経由でリスクを持ち込むのは本末転倒です。

  • 更新ファイルのダウンロードは、必ずMicrosoftの公式経路(Update Catalog)から行う。
  • 持ち込み前に、インターネット接続PC側でウイルススキャン(可能ならEDR)を実施する。
  • 更新ファイル専用のUSBを用意し、普段使いのUSBと混ぜない。
  • オフライン側でのコピー先は、例:C:\\Updates\\YYYYMM\\ のように月別に整理し、ログとセットで保管する。
  • オフライン側での作業は、できれば管理者用の作業手順書(紙/社内Wiki)に沿って実施し、作業者判断の余地を減らす。

実作業:Windows Server 2022 に累積更新プログラムをオフライン適用する手順

ここからは、実際に適用する手順を“現場で迷わない”粒度で整理します。基本は「前提条件→本体(LCU)→必要に応じて追加(.NETなど)→再起動→確認」です。結果として、.msu ファイルを wusa で実行するだけでオフライン更新が成立します。

手順1:更新ファイルを所定フォルダへ配置する

例として、オフラインサーバーのローカルに次のようなフォルダを作って格納します。

C:\\Updates\\2025-12\\
  01-SSU-KBxxxxxxx-x64.msu
  02-LCU-KBxxxxxxx-x64.msu
  03-dotnet-KBxxxxxxx-x64.msu

ファイル名の先頭に連番を振っておくと、複数ファイルを順番に適用する運用が安定します。

手順2:再起動保留(Pending Reboot)がないか確認する

前回の更新や役割追加で再起動待ちの状態だと、更新が失敗しやすくなります。まずは再起動を済ませ、クリーンな状態にしてから適用するのが安全です。

powershell -NoProfile -Command "Test-Path 'HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Component Based Servicing\\RebootPending'"

手順3:SSUが別途必要な場合は先に適用する

更新履歴ページでSSUが前提条件として示されている場合は、先にSSUを入れます。最近はLCUにSSUが同梱されるケースもありますが、前提条件の記載があるなら従うのが無難です。なおSSUはアンインストールできない(または実質できない)ことが多いため、検証環境での事前確認を推奨します。

wusa.exe "C:\\Updates\\2025-12\\01-SSU-KBxxxxxxx-x64.msu" /quiet /norestart

手順4:累積更新プログラム(LCU)を適用する

wusa.exe "C:\\Updates\\2025-12\\02-LCU-KBxxxxxxx-x64.msu" /quiet /norestart

手順5:必要に応じて .NET 更新などを追加適用する

業務アプリが .NET を使っている場合、.NETの累積更新も同じタイミングで入れる運用が多いです。

wusa.exe "C:\\Updates\\2025-12\\03-dotnet-KBxxxxxxx-x64.msu" /quiet /norestart

手順6:再起動し、適用を確定させる

更新は再起動で確定するものが多いため、最後に計画通り再起動します。

shutdown /r /t 0

適用後の確認:更新が入ったかを“二重で”チェックする

「インストールは成功と出たが、実は入っていない」「別のKBを入れてしまった」を避けるため、複数の観点で確認します。

確認観点コマンド/操作期待する結果
KBが入っているかpowershell -NoProfile -Command "Get-HotFix | Where-Object {$_.HotFixID -eq 'KBXXXXXXX'}"該当KBが表示される
OSビルドが上がったかwinverビルド番号が更新後の値になっている
パッケージ状態dism /Online /Get-Packages /Format:Table | findstr /I KBXXXXXXXInstalled になっている
イベントログイベントビューア(WindowsUpdateClient等)更新の成功/失敗が記録されている

ログの見方:エラー時に見るべき場所を押さえる

オフライン環境では「外部に問い合わせられない」「再現しづらい」ことも多いので、ログの場所を事前に把握しておくと強いです。

ログ場所用途
DISMログC:\\Windows\\Logs\\DISM\\dism.logDISMでの追加/削除が失敗したときの原因確認
CBSログC:\\Windows\\Logs\\CBS\\CBS.logコンポーネントストアや更新適用全般の詳細
イベントログイベントビューアWindowsUpdateClientなどでエラーコードの手がかりを得る

ログは容量が大きくなることがあるため、障害解析のためにコピーする場合は、更新用の作業フォルダと分けて保管すると管理しやすいです。

よくあるつまずきと対処法(オフライン更新の現場QA)

オフライン更新で詰まりやすいポイントは、ほぼパターン化しています。症状から原因を切り分け、最短で復旧できるようにしておきましょう。

症状ありがちな原因対処
Catalogで目的の更新が見つからない製品名で探している、表記ゆれに吸われているUpdate HistoryでKB番号を特定→CatalogでKB検索に切り替える
「この更新プログラムはこのコンピューターに適用できません」製品/アーキテクチャ違い、既に適用済み、前提SSU不足x64/ARM64、対象製品を再確認。前提条件を確認しSSUから入れる
wusaが成功したのに反映されない再起動未実施、保留状態(Pending)再起動して確定。Pendingが残るならdism /Online /Cleanup-Image /RestoreHealthも検討
DISMでエラーが出る順序ミス、コンポーネントストア破損、ディスク不足SSU→LCUの順序、DISM/CBSログの確認、空き容量確保
更新適用に時間がかかる/止まって見えるサーバー性能、役割、ストレージ速度、バックグラウンド処理“無反応”に見えても処理中のことがある。ログとCPU/I/Oを見て判断

ロールバック(アンインストール)も知っておくと安心

累積更新は原則として最新が正義ですが、まれに業務アプリやドライバとの相性で不具合が出ることもあります。閉域だと情報が入ってきにくいので、切り戻し手段も把握しておくと安心です。

目的方法コマンド例注意点
特定KBのアンインストールwusawusa.exe /uninstall /kb:XXXXXXX /quiet /norestart削除後は再起動が必要。SSUは対象外のことが多い
パッケージ単位で削除DISMdism /Online /Remove-Package /PackageName:<PackageName>PackageNameの特定が必要。手順を誤ると復旧が難しい

運用上は「本番に入れる前に検証」「バックアップ/スナップショットで戻せる状態にする」を前提にし、アンインストールは最後の手段として位置づけるのが安全です。

Microsoft Defenderの定義更新をオフラインで更新する(必要な場合)

Windows Server 2022 では Microsoft Defender Antivirus が有効な構成も多く、定義ファイル(シグネチャ)の鮮度がセキュリティに直結します。インターネットに出られない環境では、OS更新(LCU)とは別に定義更新の運用を考えます。

方法概要例
定義更新ファイルを持ち込んで実行オンラインPCで定義更新ファイルを入手し、オフラインへ転送して実行取得したファイルをオフラインで実行し更新
共有フォルダを更新ソースにする閉域内に定義更新の置き場を作り、そこから更新powershell -NoProfile -Command "Update-MpSignature -UpdateSource FileShares"

Defenderの定義更新は頻度が高いため、月次のLCUとは分けて運用設計すると回しやすいです。

複数台を運用するなら:オフライン更新を“仕組み化”すると楽になる

サーバーが1台なら手作業でも回りますが、複数台になると「毎月ダウンロード→コピー→手動実行」は属人化しがちです。次のように仕組み化すると、更新の品質と作業速度が上がります。

案1:更新ファイルの保管場所を決め、資産として管理する

  • オンラインPCでダウンロードした更新ファイルを、月別・KB別に整理して保管する。
  • 「どのサーバーに、いつ、どのKBを適用したか」を台帳(Excel等)で残す。
  • 障害時にロールバックできるよう、更新前のバックアップ/スナップショットと紐づける。

案2:PowerShellで“ローカルフォルダの.msuを順番に適用”する

標準機能だけでも、ローカルフォルダ内の .msu を順番に適用する簡易スクリプトが組めます(運用に入れる場合は検証環境でテストしてください)。

powershell -NoProfile -ExecutionPolicy Bypass -Command ^
  "$dir='C:\\Updates\\2025-12';" ^
  "$msu=Get-ChildItem $dir -Filter *.msu | Sort-Object Name;" ^
  "foreach($f in $msu){ Write-Host ('Installing: ' + $f.FullName); Start-Process wusa.exe -ArgumentList ('\"'+$f.FullName+'\" /quiet /norestart') -Wait -PassThru }" ^
  "Write-Host 'Done. Please reboot.'"

ポイントは、順序(SSU→LCU→.NET等)をファイル名で担保し、ログや台帳とセットで運用することです。

案3:内部ネットワークにWSUS等を置き、サーバーは“社内更新サーバー”から取る

オフラインと言っても「インターネットに出られないだけで、社内ネットワークには出られる」ケースもあります。その場合、WSUS(Windows Server Update Services)などの更新基盤を用意し、サーバーは社内更新サーバーから更新を受け取る設計にすると、月次運用が格段に楽になります。完全に閉域で外部接続ができない場合でも、更新基盤サーバーを定期的に“持ち出し同期”する運用を検討する価値があります。

まとめ:Windows Server 2022のオフライン更新は「KB特定→Catalog入手→USB適用」で確実に回せる

Windows Server 2022 がインターネット接続できない環境でも、最新の累積更新プログラムを適用することは可能です。ポイントは、Update Historyで最新KBを特定し、Microsoft Update CatalogでKB検索して正しい更新ファイルを入手すること、そしてSSUなど前提条件と適用順序を意識してオフラインサーバーへインストールすることです。

一度手順を固めてしまえば、毎月の更新作業は「同じ型」で回せます。まずは1回、検証環境または影響の少ないサーバーで成功体験を作り、ログと台帳を残しながら運用を安定させていきましょう。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次