
Windows Server 2019の更新エラー0x80070005を最短で潰す:権限・CBS・更新コンポーネント復旧の実践手順
Windows Server 2019でWindows Updateが失敗し、エラー 0x80070005(アクセス拒否系)に詰まるケースは、単純なキャッシュ破損よりも「更新エンジンが参照する領域の権限・整合性」が崩れていることが多いのが特徴です。catroot2/SoftwareDistributionのリセット、SFC/DISMが“問題なし”でも止まるときに効く、現場で再現性の高い潰し方を順番にまとめます。 Microsoft Support+1
- Windows Server 2019の更新エラー0x80070005を最短で潰す:権限・CBS・更新コンポーネント復旧の実践手順
0x80070005の正体:多くは「更新が触りたい場所に触れない」
0x80070005は更新処理が必要なファイル・レジストリにアクセスできない状態で出やすいコードです。セキュリティ製品やGPO、サービス権限、CBS(Component Based Servicing)周りのACL崩れが絡むと、キャッシュ削除だけでは直りません。 Microsoft Support+1
まず押さえる前提:やるべき順番が重要
すでに以下は実施済み、という前提で「次の一手」を中心にします。
-
更新関連サービス停止 → catroot2/SoftwareDistributionリネーム
-
subinaclでCBS系レジストリ権限付与(TrustedInstaller)
-
SFC/DISM(RestoreHealth含む)でエラーなし
この状態でなお失敗するなら、次の3系統に分けて潰すのが速いです。
-
更新実行経路(サービス・タスク・権限)
-
CBS/COMPONENTS(更新の台帳)
-
外部要因(Defender含むセキュリティ/GPO/プロキシ)
手順1:Windows Updateの“実行主体”を正常化する(サービス/タスク)
更新は「自分で実行しているつもり」でも、実際は複数サービスとタスクが連携して動きます。まずは状態を揃えます(管理者のPowerShell/CLI)。
1-1. 関連サービスを既定に寄せて再起動
sc config wuauserv start= demand
sc config bits start= delayed-auto
sc config cryptsvc start= auto
sc config trustedinstaller start= demand
net stop wuauserv
net stop bits
net stop cryptsvc
net stop msiserver
net stop trustedinstaller
net start trustedinstaller
net start cryptsvc
net start bits
net start wuauserv
ポイント:TrustedInstaller(Windows Modules Installer)が止まりっぱなし/開始できない場合、CBS側(後述)の損傷や権限崩れの可能性が跳ね上がります。
1-2. タスクスケジューラの更新系タスクが無効化されていないか
サーバー運用でタスクを抑止していると、GUI上は動いて見えても内部が失敗します。最低限、以下が無効化されていないか確認します。
-
Task Scheduler Library > Microsoft > Windows > WindowsUpdate
-
… > UpdateOrchestrator
-
… > Servicing
(無効なら有効化して再試行)
手順2:CBS/COMPONENTSの整合性を疑う(“台帳”が壊れているパターン)
SFC/DISMがノーエラーでも、更新の管理台帳(CBS・COMPONENTS)側の齟齬や権限崩れが残ることがあります。現場で多いのはここです。 Sysnative Forums
2-1. CBSログで「アクセス拒否」が出ている箇所を特定
ログはまずここを見ます。
-
C:\Windows\Logs\CBS\CBS.log -
C:\Windows\WindowsUpdate.log(環境により取得方法が異なる)
CBS.log内で 0x80070005 / Access is denied / STATUS_ACCESS_DENIED を検索し、どのパス(ファイル/レジストリ)で拒否されたかを見つけます。拒否対象が分かると、修復が“当てずっぽう”になりません。
2-2. COMPONENTSハイブ(台帳)を疑うときの扱い方
更新が「何をインストール済みにするか」「どのコンポーネントが整合しているか」を掴む重要ファイルが C:\Windows\System32\config\COMPONENTS です。ここが不整合だと、通常のキャッシュ消しでは改善しません。
運用上は、バックアップ取得 → 変更前提の検証の順で進めるのが安全です(直接編集は推奨されません)。 Sysnative Forums
手順3:ACL(権限)を“広げすぎず”に再構成する
subinaclでTrustedInstallerにフル権限付与までやっても改善しないときは、次の2点が落とし穴になりがちです。
3-1. TrustedInstallerだけでなく「SYSTEM」と「Administrators」が欠けている
更新はTrustedInstaller主体でも、周辺でSYSTEMが触る領域が多いです。CBS.logで拒否対象が分かったら、その対象に対して
-
NT SERVICE\TrustedInstaller -
SYSTEM -
BUILTIN\Administrators
の権限が揃っているかを確認します(付け足す対象はログに出た箇所だけに限定すると事故りにくい)。
3-2. ルート原因がGPO/セキュリティ基準の“継続適用”で元に戻される
一度直しても再起動やポリシー更新で戻る場合、GPO(セキュリティテンプレート含む)が原因です。
-
ローカル/ドメインGPOでWindows Update関連の制限
-
セキュリティベースラインでACLが強制上書き
がないかを確認します。
手順4:Defender/セキュリティが更新をブロックするケースを切り分け
Defenderでも「リアルタイム保護」「改ざん防止(Tamper Protection)」「ASRルール」などの組み合わせで更新周辺の書き込みを邪魔することがあります。短時間で切り分けるなら、一時的な保護停止(運用ポリシーに従って)→更新実行→結果で判断が早いです。 Microsoft Support
手順5:それでもダメなら“更新の入れ方”を変える(SSU/LCU/オフライン)
Windows Server 2019(1809系)は、更新の順序やサービシングスタック(SSU)絡みで詰まることがあります。オンライン更新がこけるなら、以下の順で試すと復旧しやすいです。
-
最新SSU → 最新LCUの順で手動適用
-
カタログから取得してオフライン適用(GUI更新経路を避ける)
-
DISMでソース指定(インストールメディアの
install.wim/esdを使う) Windows Central
仕上げ:再発防止のチェックリスト
最後に、直ったあとに再発しやすい条件を潰します。
-
更新関連サービスが“無効化”されていない
-
WindowsUpdate/Servicing系タスクが無効化されていない
-
GPOでACLや更新設定が過剰に縛られていない
-
セキュリティ製品の例外(更新キャッシュやCBSログ周辺)が適切
-
ディスク空き容量・システムドライブの破損(chkdsk含む)の兆候がない
まとめ:0x80070005は「キャッシュ」より「台帳と権限」
catroot2やSoftwareDistributionで直らず、SFC/DISMも白なら、次に見るべきは CBS(COMPONENTS)とACLの“拒否箇所”の特定です。CBS.logで拒否対象を掴み、そこだけを狙って権限・ポリシー・セキュリティの3方向から矯正すると、遠回りせず復旧できます。