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で製品/ビルドを間違えない |
| 更新ファイルの入手 | インターネット接続できるPC | Microsoft Update Catalogから正しいパッケージをダウンロード | x64/ARM64、製品名表記ゆれに注意 |
| 整合性チェック | インターネット接続できるPC | 改ざん・誤ダウンロードを防ぐ | デジタル署名/ハッシュを確認 |
| 持ち込み・検疫 | USB/共有フォルダ等 | オフライン環境へ安全に搬入 | ウイルススキャン、改ざん防止、ログ保全 |
| インストール | オフラインのWindows Server 2022 | 更新適用(.msuはwusa、.cabはDISM) | SSU→LCUの順序、再起動計画 |
| 適用確認 | オフラインのWindows Server 2022 | KB・ビルド番号・再起動要否の確認 | 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 | more | Pending状態がないか、適用済みか |
確認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 です。どちらもオフラインで適用できますが、扱い方が異なります。
| 拡張子 | よくある中身 | 推奨インストール方法 | コマンド例 | 注意点 |
|---|---|---|---|---|
| .msu | Windows Update Standalone Installer用パッケージ | wusa(またはダブルクリック) | wusa.exe "C:\\Updates\\windows10.0-kbXXXXXXX-x64.msu" /quiet /norestart | 適用後に再起動が必要なことが多い |
| .cab | DISMで追加できるパッケージ | DISM /Online /Add-Package | dism /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 KBXXXXXXX | Installed になっている |
| イベントログ | イベントビューア(WindowsUpdateClient等) | 更新の成功/失敗が記録されている |
ログの見方:エラー時に見るべき場所を押さえる
オフライン環境では「外部に問い合わせられない」「再現しづらい」ことも多いので、ログの場所を事前に把握しておくと強いです。
| ログ | 場所 | 用途 |
|---|---|---|
| DISMログ | C:\\Windows\\Logs\\DISM\\dism.log | DISMでの追加/削除が失敗したときの原因確認 |
| 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のアンインストール | wusa | wusa.exe /uninstall /kb:XXXXXXX /quiet /norestart | 削除後は再起動が必要。SSUは対象外のことが多い |
| パッケージ単位で削除 | DISM | dism /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回、検証環境または影響の少ないサーバーで成功体験を作り、ログと台帳を残しながら運用を安定させていきましょう。

コメント