Windows Server 2008 R2でWindows Updateを実行すると「80092004」で失敗し、KB4524157やKB4519108など特定の更新プログラムがどうしても入らない――この症状は、SHA-2署名を検証するための前提更新が不足していることが原因のケースが多いです。必要なKB、適用順、確認コマンド、ログを使った切り分けまで手順をまとめます。
Windows Server 2008 R2でWindows Updateが「80092004」になる典型的な症状
エラーコード80092004は、更新パッケージの署名検証（暗号関連）で問題が起きたときに現れやすいコードです。Windows Server 2008 R2では、2019年以降に配布された更新プログラム（特にセキュリティ更新やロールアップ）がSHA-2署名へ移行した影響で、OS側の前提が揃っていないとインストールが失敗することがあります。
現場でよく見るパターンは次のようなものです。
- Windows Update（GUI）で更新を適用すると失敗し、詳細に80092004が出る
- Microsoft Update Catalogから手動で.msuを入れても同じく失敗する
- 失敗する更新が複数あり、例としてKB4524157 / KB4519108 / KB4535102 / KB4534976などが並ぶ
- 同じサーバーでも、ある時点までは更新できていたのに突然失敗し始めた
結論：原因はSHA-2署名対応の前提更新不足（SSU不足を含む）
Windows Server 2008 R2（Windows 7世代）は、素の状態ではSHA-2で署名された更新プログラムを正しく検証・適用できません。そこでMicrosoftは、SHA-2署名を扱えるようにする更新と、更新処理の土台であるServicing Stack（サービシング スタック）を更新するパッチを提供しています。
ポイントは「SHA-2対応だけ」では足りないことがある点です。特にServicing Stack Update（SSU）が不足していると、SHA-2対応の更新が入っていても、その後に来る更新のインストール処理でつまずき、結果として80092004に到達するケースがあります。
必須の前提更新（KB4490628 / KB4474419）
80092004をSHA-2署名未対応が原因として解消したい場合、まずは次の2つを前提として入れるのが定石です。
| KB | 種類 | 役割（何が解決するか） | 重要ポイント |
|---|---|---|---|
| KB4490628 | Servicing Stack Update（SSU） | 更新プログラムを適用する「仕組み」そのものを更新し、以降の更新を正しく処理できるようにする | 先に入れる。SSUが古いとSHA-2対応更新後でも失敗することがある |
| KB4474419 | SHA-2署名対応 | SHA-2で署名された更新プログラムの署名検証ができるようになる | SSU適用後に入れる。古い版が入っている場合は上書き適用が有効なことがある |
実際のトラブルシュートでも、「KB4474419は入っていたがKB4490628が未適用で、KB4490628を追加したら更新が通った」というケースがよくあります。失敗する更新を追いかけるより、まず前提の2つが揃っているかを確認するのが最短ルートです。
適用前のチェック（作業ミスを減らす）
Windows Server 2008 R2は運用歴が長いサーバーも多く、更新作業そのものがリスクになることがあります。以下のチェックをしてから進めると、ハマりどころを減らせます。
| チェック項目 | 確認方法 | 理由 |
|---|---|---|
| メンテナンス時間と再起動可否 | 運用手順・関係者調整 | SSUや暗号系更新は再起動が絡むことが多く、途中で止めると復旧が面倒になりやすい |
| バックアップ（可能ならスナップショット） | バックアップ製品 / 仮想基盤のスナップショット | 更新失敗からのロールバックや起動不能に備える |
| OSエディションとアーキテクチャ | wmic os get osarchitecture | ダウンロードする更新（x64/Itaniumなど）を誤ると適用できない |
| 日時ずれ | 時刻同期（NTP/ドメイン） | 証明書検証は時刻の影響を受けるため、大きくずれていると暗号関連エラーが出やすい |
KB4490628 / KB4474419のインストール手順（推奨手順）
ここでは「Windows Updateでも手動でも失敗する」状況を想定し、確実性を優先した手順を紹介します。ポイントは順番と再起動です。
インストール済みかをコマンドで確認する
まず、対象KBが入っているかを確認します。GUI（インストールされた更新プログラム）でも良いですが、サーバー作業ではコマンドが確実です。
wmic qfe | find "KB4490628"
wmic qfe | find "KB4474419"どちらもヒットしない場合は未適用です。片方だけヒットする場合でも、もう片方が不足している可能性が高いので手順を続けます。
Microsoft Update Catalogから更新を入手する
Windows Server 2008 R2では、更新エージェントや通信条件の関係でWindows Update経由が不安定なことがあります。80092004が出ているなら、まずはMicrosoft Update CatalogからKB4490628とKB4474419の.msuを入手し、手動適用するのが手堅いです。
- サーバーから直接ダウンロードできない場合は、別PCで入手してファイル転送してもOK
- ダウンロード時はx64など対象OSに一致するパッケージを選ぶ
KB4490628（SSU）を先に適用して再起動する
SSUは「更新を適用する仕組み」を変える更新です。先に入れないと後続の更新が正しく入らないことがあるため、順序を守ります。
wusa.exe Windows6.1-KB4490628-x64.msuウィザードに従ってインストールし、完了したら再起動してください。/quietで回す場合も、最終的には再起動が必要です。
wusa.exe Windows6.1-KB4490628-x64.msu /quiet /norestartKB4474419（SHA-2署名対応）を適用して再起動する
SSU適用後に、SHA-2署名対応のKB4474419を入れます。
wusa.exe Windows6.1-KB4474419-x64.msuこちらも適用後に再起動を推奨します。暗号・署名周りの更新は、再起動を挟まないと状態が揃わず「入れたはずなのにまだ失敗する」になりがちです。
失敗していた更新（例：KB4524157等）を再実行する
前提更新が揃ったら、Windows Updateを再実行するか、失敗していたKBを手動で適用し直します。多くのケースで、これまで80092004だった更新が正常にインストールできるようになります。
「KB4474419は入っているのに80092004」のときに疑うポイント
現場では「SHA-2対応（KB4474419）を入れたはずなのに直らない」という相談が少なくありません。その場合、次のどれかが当たりやすいです。
| よくある状態 | 起きること | 対処の方向性 |
|---|---|---|
| KB4490628（SSU）が未適用 | 署名検証は通っても、更新適用処理がうまく動かず失敗することがある | KB4490628を先に適用して再起動 |
| KB4474419が古い版のまま | 後から配布された更新の署名や処理に追従できず失敗することがある | Microsoft Update CatalogからKB4474419を上書き適用 |
| 再起動待ち（Pending Reboot） | インストール済み扱いでも内部状態が揃わず失敗が続く | 更新適用の区切りで必ず再起動 |
| 更新コンポーネント（CBS/WinSxS）破損 | 前提更新を入れても別の理由で失敗する | SFC / CheckSURで整合性を確認 |
SFCでシステム破損を確認する（まずは定番の切り分け）
前提更新を入れても改善しない場合は、OSのシステムファイル破損がないか確認します。サーバー用途でもsfc /scannowは最初にやる価値があります。
sfc /scannow結果として「修復できなかったファイルがある」と出る場合は、更新以前にOS側の整合性が崩れている可能性があります。その状態だと、SSUやSHA-2対応を入れても別のエラーで失敗し続けることがあるため、次のCheckSURも合わせて実施します。
System Update Readiness Tool（CheckSUR）で更新コンポーネントを確認する
Windows Server 2008 R2では、更新コンポーネントの整合性確認としてSystem Update Readiness Tool（通称CheckSUR）を使う手順が定番です。これは「更新に必要なコンポーネントの欠損や不整合」を検出・一部修復してくれるため、前提更新を入れても失敗するケースの切り分けに有効です。
実行後は、次のログを確認します。
%SYSTEMROOT%\Logs\CBS\CheckSUR.log%SYSTEMROOT%\Logs\CBS\CheckSUR.persist.log
ログ上に不足ファイルや破損が列挙されている場合、追加で修復が必要です。ここは環境ごとに内容が変わるため、ログを見ながら「何が欠けているのか」を把握するのが近道です。
Windows Update関連ログの場所と見るべきポイント
80092004の原因がSHA-2前提不足なのか、別の破損・設定問題なのかを切り分けるには、ログが最も確実です。Windows Server 2008 R2で最低限押さえたいログを表にまとめます。
| ログ | 場所 | 見るポイント |
|---|---|---|
| WindowsUpdate.log | %WINDIR%\WindowsUpdate.log | 失敗した更新のKB、エラーコード、署名検証やダウンロード段階で止まっていないか |
| CBS.log | %WINDIR%\Logs\CBS\CBS.log | パッケージ適用（CBS）の失敗内容。依存関係、破損、アクセス拒否などが残る |
| CheckSUR.log | %WINDIR%\Logs\CBS\CheckSUR.log | 更新コンポーネントの欠損・不整合。前提を入れても直らない時の手掛かり |
| イベントビューア | システム / セットアップ | 更新適用中の失敗イベント、再起動後の構成失敗、サービス停止など |
「どの段階で失敗しているか」を切り分けると、対応がブレません。署名検証で止まっているなら前提更新・証明書系、CBS適用で止まっているならコンポーネント破損や依存関係が主戦場になります。
Windows Updateコンポーネントのリセット（追加の定番手順）
前提更新は入っているのにWindows Updateが不安定、ダウンロードは進むがインストールで失敗する、といった場合は、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を再実行して動作を確認します。80092004が解消しない場合でも、ログが整理されて原因が追いやすくなるメリットがあります。
WSUS配下のサーバーで80092004が出る場合の考え方
WSUS環境では「更新は社内WSUSから取る」ため、Microsoft Updateに直接出られるかどうかよりも、WSUS側で前提更新が承認・配布されているかが重要になります。
- KB4490628（SSU）とKB4474419（SHA-2対応）が未承認だと、クライアントは必要な前提を取れず失敗し続ける
- SSUは「置き換え（Superseded）」の扱いが独特で、運用ルールによっては自動承認から漏れることがある
- 対象グループへの割り当て、期限設定、再起動ポリシー（GPO）を見直すと改善することがある
特にSSUは、月例ロールアップの前に入っていないと詰むことがあるため、WSUS運用では「SSUだけは優先して配る」ルール化が効果的です。
オフライン環境・閉域網での注意点（署名検証の落とし穴）
閉域網やインターネット遮断環境では、更新そのものはUSB等で持ち込めても、証明書（ルート証明書や中間証明書）の自動更新が効かず、暗号関連で失敗することがあります。80092004が続く場合は、前提更新に加えて次の点も確認してください。
| 確認ポイント | 症状の例 | 対処のヒント |
|---|---|---|
| Cryptographic Services（暗号化サービス）が停止していないか | 署名検証やカタログ処理で失敗しやすい | services.mscで状態確認、cryptsvcを開始 |
| 信頼されたルート証明機関が極端に古くないか | 署名の検証に失敗する／別の暗号系エラーが混ざる | 運用方針に沿ってルート証明書更新を検討（組織のセキュリティポリシー優先） |
| サーバー時刻がずれていないか | 証明書の有効期限判定で失敗する | 時刻同期の復旧、ドメイン参加ならPDCとの同期を確認 |
ただし、今回のテーマである「特定KBが80092004で失敗」では、まずKB4490628とKB4474419が揃っているかを最優先で確認するのがセオリーです。証明書更新は環境のポリシーに影響するため、必要性が見えた段階で慎重に進めるのが安全です。
更新を安定運用するための実践的なコツ（Server 2008 R2向け）
古いOSほど、更新は「一発で全部」より段階的に揃えるほうが成功率が上がります。運用で効くコツをまとめます。
- SSUは優先：毎月のロールアップやセキュリティ更新の前に、SSUが最新か確認する
- 適用順を固定：SSU → 署名/暗号（SHA-2等） → 失敗していた更新、の順を守る
- 再起動をケチらない：再起動待ちが残ると、次の更新が連鎖的に失敗する
- ログをセットで保全：WindowsUpdate.log / CBS.log / CheckSUR.logを作業単位で保管すると、次回の調査が早い
- テスト機で検証：同構成の検証機があるなら、前提更新の導入と月例更新を先に当ててリスクを下げる
よくある質問（80092004周辺）
手動で.msuを実行しても失敗します。どこから疑うべき？
まずは前提更新（KB4490628/KB4474419）の不足を疑い、インストール済みかを確認してください。次に、再起動待ちがないかを確認し、それでもダメならSFC / CheckSURでOSの整合性を確認します。手動適用で失敗するなら、原因は「ダウンロード」より「署名検証」または「適用処理」に寄っていることが多いです。
KBが「このコンピューターに適用できません」と出ます
このメッセージは、80092004とは別系統で、更新の対象（OSエディション、前提、サービスパック、言語、アーキテクチャ）が一致していない可能性が高い状態です。特にServer 2008 R2は環境により役割/機能の差が大きいため、対象KBが本当にServer 2008 R2向けか、また前提（SP1など）が揃っているかを確認してください。
KB4490628とKB4474419はどちらを先に入れる？
KB4490628（SSU）→ KB4474419（SHA-2）の順が基本です。順序が逆だと、最終的に「入っているのに更新が失敗する」状態に陥りやすいので、順番を守り、間に再起動を挟むのが安全です。
まとめ：Windows Server 2008 R2の80092004は前提更新の不足を疑う
Windows Server 2008 R2でWindows Updateが80092004で失敗し、KB4524157などが適用できない場合、まず疑うべきはSHA-2署名対応の前提不足です。KB4490628（SSU）とKB4474419（SHA-2）を正しい順序で適用し、再起動を挟んでから更新を再実行してください。それでも改善しない場合は、sfc /scannowやCheckSUR、ログ（WindowsUpdate.log / CBS.log）で原因を切り分けると、次に打つ手が明確になります。
コメント