Windows Server 2008 R2 を長期間更新せずに運用していると、久しぶりに Windows Update を実行したタイミングで「インストールに失敗しました（80092004）」が出て、セキュリティ更新や .NET 更新が入らないことがあります。本記事では、典型的な原因と、前提更新（SSU／SHA-2 対応）を先に適用して復旧する手順を、確認ポイントとトラブルシュート込みでまとめます。
発生する症状：古い更新が「80092004」で失敗する
1年以上など長期間 Windows Update を止めていた Windows Server 2008 R2（x64）で、次のような更新がインストール失敗になり、Windows Update からの再試行でも Microsoft Update Catalog からの手動インストールでも通らない、というケースがあります。
| 失敗しやすい更新プログラム例 | 分類 | 失敗時の見え方 | 背景で起きていること（代表例） |
|---|---|---|---|
| 2019-09 セキュリティ マンスリー品質ロールアップ（KB4516065） | OS（月例ロールアップ） | Windows Update／手動どちらでもエラー 80092004 | 更新パッケージ署名（SHA-2）を検証できない、または古いサービススタックが処理できない |
| 2020-01 .NET Framework のセキュリティ/品質ロールアップ（KB4535102） | .NET（月例ロールアップ） | インストール途中で失敗、再試行しても同じ | .NET 更新も署名検証や前提更新に依存しており、土台が不足すると同様に失敗する |
Windows Update の画面上の文言は「更新プログラムを構成できませんでした」など別の表現に見えることもありますが、ログ上は 80092004 が出ており、同じ根っこ（署名検証・前提更新不足・証明書まわり）に起因しているケースが多いです。
エラー 80092004 の意味と、なぜ「長期間未更新」で起きやすいのか
80092004 は、ざっくり言うと「暗号（証明書）関連の処理で必要な情報が見つからず失敗した」系のエラーです。Windows Update では、更新プログラム（.msu/.cab）を適用する前に、次のようなチェックが走ります。
- 更新パッケージが改ざんされていないか（デジタル署名の検証）
- 署名が信頼できる発行元か（証明書チェーンの検証）
- 更新を適用するための仕組み（サービススタック）が、現行の更新形式に対応しているか
Windows 7／Windows Server 2008 R2 世代では、2019年以降の更新適用において「SHA-2（SHA-256）署名への対応」が重要になりました。長期間未更新のサーバーは、SHA-2 を扱うための更新や、更新適用基盤であるサービススタック更新（SSU）が古いまま残っていることがあり、その状態で後続の更新を入れようとすると署名検証でつまずきやすくなります。
つまり、失敗している KB4516065 や KB4535102 が「悪い」のではなく、受け取る側（Windows Server 2008 R2）の土台が古く、必要な前提が不足しているのが主因になりがちです。
まずやるべきこと：前提更新（SSU / SHA-2）を先に入れる
80092004 の定番対処は、後続更新を適用するための前提更新を先に揃えることです。特に次の2つは、2008 R2 の「更新の通り道」を作る更新として非常に重要です。
| KB | 種類 | 目的 | ポイント |
|---|---|---|---|
| KB4490628 | サービス スタック更新（SSU） | 更新プログラムを適用する仕組み（サービススタック）を更新する | 後続の更新成功率に直結。まず最初に入れるのが基本 |
| KB4474419 | SHA-2 コード署名対応 | SHA-2 署名の更新を正しく検証・適用できるようにする | 2019年以降の更新で重要。SSU の後に入れるのが安全 |
この2つを入れて再起動した後に、失敗していた KB4516065／KB4535102 を再度適用すると通る、という流れが王道です。
手順の全体像
- 現状確認（SP1、x64、更新履歴、時刻、空き容量）
- KB4490628（SSU）をインストール → 再起動
- KB4474419（SHA-2）をインストール → 再起動
- KB4516065／KB4535102 を再インストール（Windows Update または手動）
- まだ失敗する場合は、証明書・更新コンポーネント・整合性チェックへ進む
事前チェック：更新作業を安全に進めるための確認事項
2008 R2 のように長期運用されたサーバーは、環境差が大きく、同じ KB でも適用前提や副作用が出やすいです。作業前に最低限、次を押さえてください。
- バックアップ／スナップショット：可能なら仮想基盤のスナップショット、最低でもシステムバックアップ
- メンテナンス時間：SSU と SHA-2 は再起動が絡むため、余裕を確保
- 空き容量：更新展開で一時領域が増えるため、システムドライブに余裕を確保
- 時刻の正しさ：証明書検証は時刻ズレに弱い。NTP 同期や手動補正を確認
- Windows Server 2008 R2 SP1：未適用だと後続更新の前提で詰まることがある
CLI で確認するなら次のようなコマンドが手早いです。
systeminfo | findstr /i "OS 名 OS バージョン システムの種類"
wmic qfe get HotFixID,InstalledOn | find "KB4490628"
wmic qfe get HotFixID,InstalledOn | find "KB4474419"上の find でヒットしない場合は、未インストールの可能性が高いです（環境により表示揺れがあるため、最終的には「インストールされた更新プログラム」一覧でも確認してください）。
手順：KB4490628（サービス スタック更新 / SSU）をインストールする
SSU は「更新を入れるための更新」です。これが古いと、後続更新が途中で失敗しやすくなります。Windows Update 経由で入る場合もありますが、今回のように詰まっている状況では Microsoft Update Catalog から手動取得して適用するのが確実です。
- 対象は Windows Server 2008 R2 x64（Windows 7 x64 と同系列）
- 拡張子は通常 .msu（Windows Update スタンドアロン インストーラー）
手動で適用する場合は、GUI でダブルクリックしても良いですし、リモート作業や記録を残すなら wusa.exe で実行します。
wusa.exe <KB4490628 の .msu ファイル>適用後は再起動してください。SSU は「入ったように見えるが内部的には反映待ち」になりやすく、再起動を挟まず次へ進むと失敗率が上がります。
手順：KB4474419（SHA-2 署名対応）をインストールする
SSU を入れて再起動したら、次に SHA-2 対応更新を入れます。これが入っていないと、2019年以降の更新の署名を正しく検証できず、80092004 を含む暗号系エラーが出やすくなります。
wusa.exe <KB4474419 の .msu ファイル>こちらも再起動を推奨します。特に暗号コンポーネントや更新適用の根幹に関わるため、再起動で状態を確定させてから後続更新へ進むのが安全です。
手順：失敗していた KB4516065 / KB4535102 を再度インストールする
前提が揃ったら、目的の更新を再適用します。基本は Windows Update で再試行し、うまくいかなければ Catalog のファイルを手動で当てます。
- OS のロールアップ（KB4516065）：先に OS 側を更新する
- .NET のロールアップ（KB4535102）：OS 更新後に適用するとトラブルが減りやすい
wusa.exe <KB4516065 の .msu ファイル>
wusa.exe <KB4535102 の .msu ファイル（または .exe など配布形式に応じたファイル）>Catalog では同じ KB 番号でも複数のエントリが出ることがあります。特に .NET は「対象 OS」「x64/x86」「対象バージョン（3.5.1/4.x）」で別パッケージがあるため、Windows Server 2008 R2 SP1 / x64 に一致するものを選んでください。
それでも直らない場合：80092004 を潰すための追加チェック
80092004 は「前提不足」が原因のことが多い一方で、長期運用サーバーでは別要因が重なり、同じエラーに見えることがあります。以下は、現場で効きやすい順にまとめたチェックリストです。
| チェック項目 | 確認方法 | 問題だった場合の対処 |
|---|---|---|
| 再起動を挟んだか | 更新適用後に必ず再起動し、保留中の再起動がないか確認 | SSU → 再起動 → SHA-2 → 再起動 の順でやり直す |
| パッケージが x64 か | Catalog で「x64」を選んだか、ダウンロードしたファイル名/説明 | x64 を取り直す（取り違えは意外と多い） |
| システム時刻が正しいか | タスクバー時刻、NTP 同期状況 | 時刻を補正し、証明書の有効期間チェックを通す |
| 暗号化サービスが正常か | Cryptographic Services（CryptSvc）が起動しているか | サービス再起動、catroot2 の再生成 |
| Windows Update コンポーネントの破損 | WindowsUpdate.log、イベントログ | SoftwareDistribution / catroot2 のリセット、SURT の実行 |
| 証明書チェーン（ルート証明書）の不足 | CAPI2 ログで検証失敗が出ていないか | ルート証明書の更新（オンライン取得 or オフライン配布） |
Windows Update コンポーネントをリセットする（定番）
前提 KB を入れても失敗が続く場合、Windows Update のキャッシュや署名データベースが壊れていることがあります。次の手順は副作用が比較的少なく、効果が出やすい「リセット」です。
net stop wuauserv
net stop bits
net stop cryptsvc
ren %windir%\SoftwareDistribution SoftwareDistribution.old
ren %windir%\System32\catroot2 catroot2.old
net start cryptsvc
net start bits
net start wuauserv実行後に再起動し、Windows Update または手動インストールを再試行します。catroot2 は署名検証にも関わるため、80092004 系には特に効くことがあります。
証明書まわりを疑う：CAPI2 ログで原因に当たりを付ける
80092004 は証明書チェーンの検証に失敗しても出ることがあります。イベントビューアーで次のログを確認すると、失敗した証明書や取得先が見えることがあります。
- イベント ビューアー → アプリケーションとサービス ログ → Microsoft → Windows → CAPI2 → Operational
もし CAPI2 が無効なら、Operational を右クリックして有効化し、更新の再試行でログを採取します。ログに「証明書が取得できない」「失効確認ができない」などが出る場合は、プロキシ／FW で外部の証明書配布先が遮断されている、またはルート証明書が古い、といった可能性が上がります。
システムの整合性を直す：SFC と System Update Readiness Tool（SURT）
長期運用でコンポーネントストア（CBS）が壊れていると、更新が連鎖的に失敗します。Windows Server 2008 R2 では、次の順で試すと切り分けしやすいです。
- sfc /scannow：システムファイルの整合性チェック
- System Update Readiness Tool（KB947821）：CBS の不整合を修復するためのツール（環境により効果大）
sfc /scannowSURT は実行に時間がかかる場合がありますが、Windows Update の「謎の失敗」をまとめて直すことがあります。実行後は C:\Windows\Logs\CBS\CheckSUR.log を確認し、修復できなかった項目が残っていないかも見てください。
ログで「どこで失敗したか」を見る
闇雲に再試行するより、ログで当たりを付けたほうが早いです。2008 R2 では、Windows Update のログは基本的に次です。
C:\Windows\WindowsUpdate.logC:\Windows\Logs\CBS\CBS.log
WindowsUpdate.log で 80092004 が出るタイミング前後を見れば、「ダウンロード後に署名検証で落ちたのか」「インストール段階で落ちたのか」の切り分けができます。CBS.log はインストール処理側の詳細が出るため、適用失敗の根拠になります。
補足：サーバーが“さらに古い”場合に引っかかりやすい前提
「1年以上未更新」のつもりでも、実際には数年単位で止まっている環境では、KB4490628 自体の導入前に別の土台が不足していることがあります。もし SSU のインストールからつまずく場合は、次を疑ってください。
- SP1 未適用：まず SP1 を前提にそろえる
- 極端に古いサービススタック：古い SSU が必要になるケースがある
- Windows Update の破損：先にコンポーネントリセットや SURT を当てたほうが早い場合がある
この章は「今回の KB が必ず追加で必要」という意味ではなく、どうしても前提更新が入らないときの現場的な逃げ道として覚えておくと役に立ちます。
「更新が古いが、入れるべきか？」判断の目安
結論として、運用を続けるなら入れるべきです。理由はシンプルで、未適用の脆弱性を放置するより、過去のセキュリティ更新でも適用したほうがリスクは下がるからです。
ただし、Windows Server 2008 R2 はすでにサポートが終了しており、すべての脆弱性が今後も修正されるわけではありません。更新を当てて「今日の穴」を塞いでも、サポート切れ OS である以上、明日以降の穴は塞がれない前提で運用を考える必要があります。
| 状況 | 優先順位 | 推奨アクション |
|---|---|---|
| インターネットに直接/間接的に公開（RDP、Web、VPN越し含む） | 最優先 | 更新適用は急ぐ。並行して移行計画を即開始（隔離・アクセス制御も） |
| 社内閉域だが、多数端末から到達可能 | 高 | 更新適用＋ネットワーク分離、不要サービス停止、踏み台経由に切替 |
| 単体機・閉域で用途限定（装置組み込み、オフライン） | 中 | 完全隔離、媒体持ち込み統制、ログ監視を強化（更新が難しい場合の現実解） |
「古い更新を入れる意味があるのか」という疑問は自然ですが、攻撃者は「未パッチ」を狙うため、たとえ 2019〜2020 年の更新でも、適用できるなら価値は十分にあります。
長期運用を続けるなら：更新だけでなく“守り方”を変える
サポート切れ OS は、更新だけで守り切るのが難しくなります。Windows Server 2008 R2 をやむを得ず残す場合は、「更新を通す」ことに加えて、守り方をセットで見直すのが現実的です。
最低限の追加対策チェックリスト
- ネットワーク分離：業務端末から直接到達させない（VLAN/ACL/ファイアウォール）
- 管理経路の見直し：RDP 直当てをやめ、踏み台（ジャンプサーバー）や VPN＋多要素認証へ
- 不要サービスの停止：レガシー機能（例：SMBv1 等）を無効化できるなら検討
- バックアップと復旧訓練：古い OS ほど復旧に時間がかかる。復旧手順を文書化して検証
移行の考え方（最短で事故を減らす）
移行は「いきなり OS を上げる」より、次の順に進めると破綻しにくいです。
- 現状の役割（AD、ファイル、アプリ、IIS、SQL など）と依存関係を洗い出す
- 互換性の壁が高いものから、代替（別サーバー化、アプリ改修、SaaS 化）を検討
- 新サーバーへ段階移行し、旧 2008 R2 は役割を減らして最終的に退役させる
「更新が通らない」問題は、裏を返せば「すでに運用の限界が近い」サインでもあります。今回の復旧をきっかけに、移行計画を“次の障害対応”ではなく“今のうちにやる仕事”として進めるのがおすすめです。
まとめ
- Windows Server 2008 R2 で 80092004 が出て更新が入らない場合、前提更新不足（SSU / SHA-2）が典型原因
- KB4490628 → 再起動 → KB4474419 → 再起動 の順で土台を整え、その後に目的の更新（KB4516065/KB4535102）を再適用する
- 直らないときは、Windows Update リセット、catroot2 再生成、証明書（CAPI2）ログ確認、SFC/SURTで切り分ける
- 2008 R2 はサポート終了のため、更新適用と並行して移行・分離を進めるのが根本対策
コメント