Windows Server 2008 R2 で更新プログラムが入らず「Windows Modules Installer（TrustedInstaller）」関連のエラーになるとき、更新キャッシュ破損よりも “ESU（延長セキュリティ更新）の前提不足・未有効化” が根本原因になっているケースが少なくありません。症状別に、最短で原因へ到達する切り分けと復旧手順をまとめます。
まず押さえる：2008 R2 の「更新が出ない／入らない」は仕様に近い落とし穴がある
Windows Server 2008 R2 は、延長サポート（Extended End Date）が 2020年1月14日で終了しています。そのため、それ以降のセキュリティ更新を適用するには、原則として ESU（Extended Security Updates：延長セキュリティ更新）に加入し、前提更新とライセンス有効化が完了している必要があります。ESU には年次（Year 1〜Year 3、Azure では Year 4）という区切りがあり、提供期間も明確に分かれています。
ここが重要で、「SSU（Servicing Stack Update）を入れた」「SURT（System Update Readiness Tool）で No errors detected」といった状態でも、ESU の前提が欠けていると Windows Update に更新が出ない／手動の .msu が弾かれる、という現象が発生します。特に 2020年以降の “セキュリティ更新” を入れたい場合は、まず ESU を疑うのが最短ルートです。
症状から当たりを付ける（原因候補の優先度表）
| 症状 | 優先度の高い原因 | まずやる確認 |
|---|---|---|
| Windows Update に更新が出てこない（チェックしても 0 件） | ESU 未契約／未有効化、または ESU 前提更新不足 | 適用したい KB が 2020年1月以降か／ESU ライセンス状態（slmgr） |
| .msu の手動適用で「Windows Modules Installer」系のエラー（0x800f0823 等） | Servicing Stack（更新基盤）不足、または KB が要求する前提更新不足 | KB925316 の対象症状か／KB2533552・SSU・SHA-2 の状況 |
| SSU は入れた（例：KB4562030）なのに、セキュリティ更新が入らない | ESU キー未導入／未認証、ESU Licensing Preparation Package 未導入 | KB4538483（または該当年の準備更新）と ESU 有効化 |
| SURT が No errors detected だがログ末尾に 0x0000045D が出る | ストレージ I/O の不安要素（環境依存で“警告のみ”の場合も） | イベントログ（Disk/Ntfs/Storport）、chkdsk、コントローラ／仮想化設定 |
切り分けの最短手順：その更新は ESU 対象か？
最初にやるべきことはシンプルで、「入れようとしている更新（KB）が ESU を前提としているか」を確定させることです。ESU を前提とする更新を ESU なし環境へ入れようとすると、以下のような“行き止まり”になりやすいからです。
- Windows Update からは更新が提示されない（0 件のまま）
- Microsoft Update Catalog から .msu を落としても、適用時に失敗する／適用不可扱い
- 更新の失敗が「Windows Modules Installer」や「スタンドアロン インストーラー（wusa.exe）」に見える
判断材料としては、次のどれかが分かれば十分です。
- 適用したい更新の公開日（2020年1月14日以降の “Security Only / Monthly Rollup” は ESU 前提になりやすい）
- 更新の分類（Security Update / Security Only / Monthly Rollup）と対象 OS（Windows Server 2008 R2 SP1）
- KB が “ESU” を前提にしている旨の記載（Microsoft の手順や前提条件ページ）
環境内で確定させるなら、失敗している KB 番号を 1 つに絞り、その KB が 2020年以降かどうかを確認してください。ここが確定すると「一般的な修復（WU リセット等）で直る系」か「ESU の前提不足」かが一気に分かれます。
ESU を使うなら必須：前提条件の“漏れ”を潰す
ESU は「契約（キー）を入れれば終わり」ではありません。2008 R2 の更新基盤は、2019年以降の署名方式（SHA-2）や Servicing Stack（SSU）に依存しており、前提が欠けると更新適用が成立しません。Microsoft の案内でも、SHA-2 と SSU を前提として明記しています。
前提更新の考え方（よくある誤解）
- 「SSU を 1 個入れた」だけでは不足することがある（時期によって“必要な SSU の世代”が違う）
- SHA-2 対応がないと署名検証で詰む（更新が落ちるのに SURT は No errors になることもある）
- ESU Licensing Preparation Package は “ESU キーをインストールするための準備更新” で、ここが欠けると ESU が有効化できない（または更新適用が進まない）
実務で使える「前提条件チェック表」
まずは以下を “漏れなく” 入っているか確認してください（WSUS/Update Catalog で配布されるものもあります）。
| 区分 | 代表的な KB | 役割 | ポイント |
|---|---|---|---|
| 署名方式（SHA-2） | KB4474419（2019/09/23 以降の SHA-2 更新） | 2019年以降の更新の署名検証に必須 | 導入後に再起動が必要（手順上も強調される） |
| SSU（基礎） | KB4490628（2019/03/12 以降の SSU） | 更新を適用する「土台」 | SSU はアンインストール不可。新しい SSU に置換される |
| SSU（例：ユーザー環境で導入済み） | KB4562030（2020/06/09 SSU） | Servicing Stack の品質改善 | 前提として SHA-2（KB4474419）と SSU（KB4490628）を要求 |
| ESU 準備（オンプレ Year 1〜3 の基礎） | KB4538483（ESU Licensing Preparation Package） | ESU キー導入・適用に必要なライセンス関連変更 | 導入後は再起動必須。前提として SHA-2/SSU を要求 |
| ESU 確認用（テスト更新） | KB4528069（※現在は提供終了） | ESU 適格性を“確認するため”のテスト更新 | 前提条件に SHA-2/SSU/追加 SSU + 月例ロールアップ、そして ESU キー有効化を要求 |
| Azure 年4（該当者のみ） | KB5017397（SSU）, KB5016892（ESU 準備） | 2023年以降 Azure 環境で ESU を継続する手順 | 「Azure で追加 1 年」対象の手順として明記（オンプレ一般用途とは切り分け） |
ポイントは、「SSU は入っている」だけでは判断できないことです。対象年次の ESU や、適用したい月例更新が要求する “世代の SSU” を満たしているかで成否が分かれます（特に 2022〜2023 にかけて前提が更新されています）。
ESU キーの導入・有効化：ここが未完了だと更新が“出ない／入らない”
ESU を使う前提なら、最終的に ESU キーが「インストール済み」かつ「ライセンス状態が Licensed」 になっていないと、セキュリティ更新が適用できません。UI の「Windows のライセンス認証」画面は OS 本体の認証であり、ESU の有効化とは別物です。
コマンドで確認・有効化する（slmgr）
管理者のコマンドプロンプトで実行します。
slmgr /ipk ＜ESU MAKキー＞続けて、ESU の Activation ID（SKU ID）を確認します。
slmgr /dlvESU の対象年次に対応する Activation ID で有効化します。
slmgr /ato ＜ESU Activation ID＞Windows Server 2008 / 2008 R2（Server）の ESU Activation ID は Microsoft の案内に一覧があります（Year 1〜Year 4）。
| ESU 年次 | Windows Server 2008/2008 R2（Server）Activation ID | 補足 |
|---|---|---|
| Year 1 | 553673ed-6ddf-419c-a153-b760283472fd | 2020/01 〜 2021/01 の ESU |
| Year 2 | 04fa0286-fa74-401e-bbe9-fbfbb158010d | 2021/01 〜 2022/01 の ESU |
| Year 3 | 16c08c85-0c8b-4009-9b2b-f1f7319e45f9 | 2022/01 〜 2023/01 の ESU |
| Year 4（Azure のみ） | 32163ff8-e96d-40b1-973c-44b9bf096d83 | Azure 追加 1 年（2023/02 〜 2024/01 の扱いが案内される） |
最後に、再度 slmgr /dlv で該当する ESU の License Status が Licensed になっていることを確認してください。ここが Unlicensed のままだと、Windows Update に出ない／手動適用で落ちる方向に寄ります。
「Windows Update で更新が出ない」場合にやるべき基本点検
ESU の前提・有効化が整っていても、環境要因で “検索結果が 0” になることはあります。ここでは、2008 R2 でありがちな見落としを順に潰します。
WSUS（社内更新サーバ）を見に行っていないか
グループポリシーで WSUS を指定していると、インターネットへ出られる状態でも Microsoft Update を見に行きません。まずはどこへ問い合わせているかを確認します。
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /sWUServer/WUStatusServerが入っている → WSUS 指定の可能性が高い- WSUS 側で 2008 R2 の分類（Security Updates / Updates）が無効、または ESU 対象が承認されていない → “見えていない” だけの可能性
更新関連サービスの状態（TrustedInstaller も含む）
「Windows Modules Installer（TrustedInstaller）」という名前が出る以上、サービスが無効化されている／依存関係で停止しているケースも切り分け対象です。
| サービス | 表示名 | 確認ポイント |
|---|---|---|
| TrustedInstaller | Windows Modules Installer | 無効化されていないか（通常は手動） |
| wuauserv | Windows Update | 停止していないか |
| BITS | Background Intelligent Transfer Service | 停止していないか |
| cryptsvc | Cryptographic Services | 証明書・署名周りで重要 |
| msiserver | Windows Installer | MSI 依存の更新で関係することがある |
コマンドで一括確認する場合の例です。
sc query trustedinstaller
sc query wuauserv
sc query bits
sc query cryptsvcWindows Update コンポーネントのリセット（更新キャッシュ破損の切り分け）
ESU の条件を満たしているのに “検索 0” や “インストール開始直後に失敗” が続く場合、更新キャッシュ破損を切り分けます。運用影響を避けるため、バックアップ／スナップショット取得後に実施してください。
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この手順で直るなら「更新の配信・検出」は復旧しており、次は “適用の失敗” を個別 KB と前提条件で詰める段階に進めます。
手動インストールで「Windows Modules Installer must be updated…」が出る場合
.msu を入れたときに「Windows Modules Installer must be updated before you can install this package」と表示される場合、Microsoft も KB で症状・原因・対処を整理しています。原因は “Windows Modules Installer（更新基盤）または Servicing Stack のバージョン不足” とされ、2008 R2 では KB2533552 の導入が対処として示されています。
ただし、質問の前提のように KB925316 相当の対処を済ませても改善しない場合、次の 2 つを疑ってください。
- その更新自体が ESU 前提で、ESU が未有効化（検出されない／適用が進まない）
- SHA-2 と SSU の前提が実は満たせていない（SSU の KB を入れるにも、さらに前提があることがある）
特に KB4562030（SSU）ですら、前提として SHA-2（KB4474419）と SSU（KB4490628）を要求します。つまり「SSU は導入済み」と思っていても、前提不足のまま別の更新で失敗している可能性が残ります。
SURT で No errors なのに 0x0000045D が出る：ディスク I/O は“警告だけ”と“本物の障害”がある
0x0000045D は、Win32 エラーとしては ERROR_IO_DEVICE（I/O device error） に該当します。つまり、何らかの I/O（読み書き）で OS がエラーを返したことを示します。
一方で、SURT のログに出る IOCTL_STORAGE_QUERY_PROPERTY Disk Cache は “ディスクキャッシュ情報の取得に失敗した” という意味合いで、仮想環境や一部のストレージドライバでは警告として出ることがあります。警告があるから即ハード故障、と決め打ちしない代わりに、更新処理はディスク I/O を大量に使うため、次のような確認をセットで行うのが安全です。
| チェック項目 | 確認方法 | 見るべきポイント |
|---|---|---|
| イベントログ（System） | Event Viewer → Windows Logs → System | Disk / Ntfs / storport などの警告・エラーが頻発していないか |
| ファイルシステム整合性 | chkdsk C: /F（必要に応じて再起動時実行） | 不良セクタや整合性修復の有無 |
| 空き容量 | システムドライブ（C:）の空きを確認 | 更新は一時領域を使うため、空きが少ないと失敗が連鎖しやすい |
| ストレージドライバ／FW | RAID/HBA/VM のドライバ・FW 更新履歴を確認 | 古い storport/コントローラで I/O 周りが不安定なことがある |
| 仮想環境の設定 | VMware / Hyper-V の仮想 SCSI コントローラ種別、ツール類 | キャッシュ情報取得が失敗する構成がある／I/O 遅延が更新失敗を誘発 |
更新が失敗しているサーバは、同時にバックアップやアプリ I/O が重なっていることも多いです。SURT の警告は「ストレージに不確実性があるかもしれない」というサインとして扱い、イベントログと chkdsk の結果で“本物かどうか”を判定するのが実務的です。
ログで一気に原因を狭める：見るべき場所と典型エラー
ESU と前提更新が揃っているのに更新が入らない場合、次のログを見れば “前提不足なのか、署名問題なのか、コンポーネント破損なのか” の方向性がほぼ決まります。
- CheckSUR.log：
C:\Windows\Logs\CBS\CheckSUR.log - CBS.log：
C:\Windows\Logs\CBS\CBS.log - WindowsUpdate.log：2008 R2 は
C:\Windows\WindowsUpdate.log（テキスト）
| よく見るエラーコード/兆候 | 意味合い | 打ち手の方向性 |
|---|---|---|
| 0x800f0823（wusa） | 更新基盤（Modules Installer / Servicing Stack）不足の典型 | KB925316 の考え方で SSU/前提を再点検（2008 R2 は KB2533552） |
| 0x800B0100 / 0x80096004 など署名系 | 署名検証・証明書・SHA-2 周りの問題を示唆 | KB4474419（SHA-2）と cryptsvc 周り、日時ずれを確認 |
| 「適用対象外」や 0x800f081e | その KB がその OS/エディション/前提に合っていない | KB の対象 OS、SP1、言語、ESU 対象可否を再確認 |
| TrustedInstaller が開始できない／停止する | サービス無効化、依存サービス停止、破損 | サービス状態、イベントログ（Setup/System）、sfc/SURT で切り分け |
復旧の実務テンプレ：安全な順序で進める手順（推奨）
現場で遠回りを減らすために、実行順をテンプレ化すると安定します。以下の順序は「やり直しが効く」「副作用が比較的少ない」ものから並べています。
- 対象 KB が ESU 前提かを確定（2020年以降のセキュリティ更新か）
- SHA-2（KB4474419）と SSU（KB4490628 以上）を満たす
- ESU Licensing Preparation Package（例：KB4538483、または対象年次/環境の準備更新）を入れて再起動
- ESU キーを導入し、slmgr で ESU を有効化（Licensed を確認）
- Windows Update の経路（WSUS/インターネット）を確認し、必要なら WU コンポーネントをリセット
- 失敗した KB を 1 つに絞り、ログ（CBS/WindowsUpdate.log）でエラーコードを拾って対処
- 0x0000045D が絡むならストレージ健全性（イベントログ、chkdsk、空き容量、ドライバ）も同時に確認
重要な注意：ESU がない（または期間外）の場合、更新は“復旧”できない
ここまでの手順は「ESU の権利があり、有効化できる」ことが前提です。ESU は年次ごとに提供期間があり、既に提供期間外であれば、それ以降のセキュリティ更新は存在しない（または提供対象外）ため、Windows Update を“復旧”する方向では解決しません。まずは自環境が ESU のどの年次の範囲まで更新できるのかを、サポート期限・ESU 年次と照らして整理してください。
アプリ互換性で 2008 R2 を継続せざるを得ない場合でも、次のような「被害を小さくする運用」は現実的に検討すべきです。
- インターネット直結を避け、必要最小限の通信だけ許可（ホワイトリスト）
- 管理経路を限定（踏み台、MFA、RDP 制限）
- バックアップと復旧手順を定期的に検証（更新失敗やディスク劣化に備える）
- 段階的な移行計画（アプリ更改、仮想化基盤の刷新、同居サーバ分離）
まとめ：チェックリスト（ここを埋めれば原因に最短で到達できる）
- 適用したい KB は 2020年1月以降のセキュリティ更新か（＝ESU 前提の可能性が高い）
- SHA-2（KB4474419）と SSU（KB4490628 以上）が入っているか
- ESU Licensing Preparation Package（例：KB4538483 など）が入っているか
- ESU キーを
slmgrで導入し、ESU の License Status が Licensed になっているか - Windows Update の参照先（WSUS/インターネット）が意図どおりか
- WU リセットで “検出 0” が改善するか
- CheckSUR/CBS/WindowsUpdate.log で、最初のエラーコードを拾えているか
- 0x0000045D が出るなら、イベントログと chkdsk で I/O を切り分けたか
このチェックリストを上から埋めるだけで、「ESU 前提不足」「ESU 未有効化」「更新基盤（SSU/SHA-2）不足」「キャッシュ破損」「ストレージ I/O」のどこに問題があるかが、かなりの確度で切り分けできます。特に “更新が出てこない＋手動適用も TrustedInstaller 系で落ちる” の組み合わせは、ESU 周りの未整備が主因になりやすいので、まずは ESU の前提と有効化を最優先で確認してください。
コメント