WSUS で Windows 10 1909 を配布しているのに、Servicing Stack Update（SSU）だけ一部端末で「0%のまま」「0x80070020」「/Content の cab が 404」といった失敗を起こすケースがあります。多くはクライアントが Express（差分）用の cab を要求している一方で、WSUS 側のコンテンツ実体が欠落・不整合になっているのが引き金です。
現象の全体像：SSU だけ落ちるときの典型パターン
まず、問い合わせが多い症状を整理します。今回のように「SSU だけ」失敗する場合は、クライアント側の一時不調よりも、WSUS 側のコンテンツ不整合が絡んでいることが多いです。
| 症状 | 端末側の見え方 | サーバ側の見え方 | 疑うべきポイント |
|---|---|---|---|
| ダウンロードが 0% のまま | 「ダウンロード中」から進まない／しばらくして失敗 | WSUS コンソール上は “Ready for Installation” に見えることがある | WSUS Content の実体欠落、IIS 配下の Content 参照先ズレ、Express cab 不足 |
| エラー 0x80070020 | 更新失敗。再試行しても同じ | WSUS 側では異常が見えにくい | 共有違反（ファイルロック）に見えるが、根は 404/不整合でキャッシュがこじれる場合あり |
| WindowsUpdate.log に CreateFile / SusCreateFileRetryIfSharingViolation | 「リトライ」を繰り返す | — | ロックそのもの（AV/EDR 等）もあり得るが、まず 404 を確認 |
| /Content/<hash>.cab を直接叩くと 404 | ブラウザでも取得できない | IIS 配下に実ファイルが無い／仮想ディレクトリが別場所を指す | WSUS 側で「コンテンツが存在しない」のが確定的 |
| 手動（Catalog の .msu/.cab）だと入る | 端末は更新できるが、WSUS 配布としては回らない／履歴が期待通りでない | WSUS のインストール状況が更新されないことがある | WSUS の配布経路（コンテンツ取得）そのものが壊れている可能性 |
ポイントは、「WSUS が配るべきコンテンツ URL を端末が要求しているのに、WSUS（IIS）が 404 を返している」状況があるかどうかです。これが確認できたら、端末側で何をしても根治しません。先に WSUS 側を直す必要があります。
前提理解：SSU と Express（差分）更新が噛み合うときに起きやすい
SSU（Servicing Stack Update）は、Windows の更新を適用するための基盤（Servicing Stack）を更新するパッチです。LCU（累積更新）より先に必要になるケースがあり、SSU が入らないと後続の更新が連鎖的に失敗します。
一方、WSUS には 「Express インストール ファイル（差分）をダウンロード」というオプションがあります。Express は “全部を丸ごと” ではなく “差分ブロック” を配るための仕組みで、クライアントは WSUS から多数の cab（差分）を取りに行きます。
ここでよくあるのが、次の不整合です。
- WSUS のメタデータ上は「この更新は配布可能（Ready）」に見える
- しかし、Express 用の cab 実体が WSUSContent に存在しない（同期が未完了、途中で失敗、Content 移行後の不整合、Cleanup/手動削除で欠落など）
- クライアントは Express cab を要求するため、IIS の
/Content/<hash>.cabにアクセスする - WSUS 側が 404 を返し、ダウンロードが 0% から動かない
- 端末側では BITS やキャッシュ周りがこじれて、結果として 0x80070020 のような「共有違反っぽい」エラーが出ることがある
つまり結論としては、クライアントが欲しい形式（Express）と、WSUS が実際に持っているコンテンツがズレているのが本丸です。
最初にやるべき切り分け：WSUS 側が本当に 404 を返しているか
「サーバが原因か、端末が原因か」を短時間で決めるために、次の確認を行います。ここで 404 が取れたら、WSUS 側のコンテンツ不整合を優先して直します。
WSUS の Content URL をブラウザで直接確認
端末の WindowsUpdate.log（またはログに相当する出力）に、http(s)://<WSUSサーバ>:<Port>/Content/<hash>.cab のような URL が出てくることがあります。その URL を WSUS サーバ自身、または同じネットワークの PC のブラウザで開いて確認します。
- 200 で cab がダウンロードできる：WSUS 側の実体はある（別要因の可能性が上がる）
- 404（Not Found）：WSUS 側に実体が無い、または IIS の Content が別フォルダを指している
IIS の「Content」仮想ディレクトリの物理パスを確認
WSUS の IIS には通常 Content 仮想ディレクトリがあります。ここが、実際の WSUSContent（例：D:\WSUS\WsusContent や C:\WSUS\WsusContent）と一致しているか確認します。
Content を移行したことがある環境（wsusutil movecontent など）では、IIS の参照先ズレが残っていると「ファイルはあるのに 404」になることもあります。今回の相談内容は「フォルダにも無い」ですが、念のため確認しておくと切り分けが速いです。
WindowsUpdate.log の見方（補足）
Windows 10 では、従来の WindowsUpdate.log は ETL から生成する形になっているため、必要に応じて管理者 PowerShell で Get-WindowsUpdateLog を実行して読める形式にしてから確認します。ログの中で CreateFile のリトライや SusCreateFileRetryIfSharingViolation が見える場合でも、まずは「サーバが 404 を返していないか」を優先して確認するのがコツです。
対処の基本方針：WSUS → クライアントの順で直す
今回のタイプは、WSUS 側でコンテンツを揃えるのが第一です。WSUS 側が直っていない状態で端末だけキャッシュ削除しても、結局 404 を取りに行って再発します。
| 順番 | やること | 狙い | 完了判定 |
|---|---|---|---|
| 先 | WSUS 側で Express/Content の不足を解消 | クライアントが要求する cab を WSUS が返せるようにする | /Content/<hash>.cab が 404 ではなく取得できる |
| 後 | クライアント側で WU キャッシュをリセット | 途中ダウンロード残骸やロックを解消して正常ダウンロードへ戻す | SSU が 0% で止まらず、WSUS 配布として成功する |
WSUS 側の対処：Express cab とコンテンツ不整合を解消する
ここからは WSUS 側で行う復旧作業です。環境差はありますが、「Express を使うのに必要なファイルを WSUSContent に揃える」「コンソール上と実体のズレを補正する」が目的です。
Express インストール ファイルの設定を確認・有効化
WSUS のオプションで 「Download express installation files（Express インストール ファイルをダウンロード）」 を確認します。Express を利用する運用であれば有効化します。
注意点として、Express はファイル数・容量が大幅に増えるため、ディスク容量不足やダウンロード未完了が起きやすくなります。今回のような「コンソール上は Ready でも実体が無い」状態は、ディスク逼迫や同期失敗がきっかけで発生しがちです。
同期（Synchronization）を実行し、欠落ファイルを揃える
- 手動同期を実行し、更新ファイルのダウンロードが完了するまで待ちます
- サーバの空き容量を確認します（Express 有効時は想定以上に増えます）
- プロキシ利用環境は、WSUS サーバの外部通信が途中で止まっていないかも確認します
対象 SSU の「File Status（ファイル状態）」で実体の有無を確認
WSUS コンソールでは、更新（KB）ごとにファイル状態を確認できます。ここで「未ダウンロード」や「一部欠落」の兆候がある場合は、同期のやり直しや reset が効きます。
wsusutil.exe reset で「DB と実ファイルのズレ」を再取得させる
コンソール上は存在するのに IIS 配下の Content に実体が無い場合、wsusutil.exe reset が有効なことが多いです。これは、WSUS が管理している更新ファイルと WSUSContent の実体を突合し、不足分を再ダウンロードさせるための手段です。
運用上のポイント：
- reset は「欠落の再取得」を促しますが、ネットワークやディスクが逼迫していると完了しません
- 途中で止まる場合は、空き容量、プロキシ、TLS/証明書、上流（Microsoft Update）疎通なども併せて点検します
- ウイルス対策ソフトが WSUSContent を過度にスキャンしていると、サーバ側のダウンロードが遅延することがあります
selfupdate の疎通確認（iuident.cab）
クライアントから WSUS の selfupdate が取得できるかは、疎通チェックとして有効です。たとえば次のような URL がクライアントから取得できるか確認します（ポートやスキームは環境に合わせます）。
http://<WSUSサーバ>:8530/selfupdate/iuident.cabhttps://<WSUSサーバ>:8531/selfupdate/iuident.cab
ここが取れない場合、WSUS 全体の IIS/ファイアウォール/SSL 設定の問題も疑います。ただし今回の論点は「/Content の cab 404」なので、selfupdate は補助確認という位置付けです。
Cleanup Wizard / DB メンテナンスは「補助」。ただしやり方は重要
Server Cleanup Wizard（不要更新の整理）や DB のメンテナンスは有用ですが、今回の本丸はWSUS Content の実体不足です。Cleanup を強く回しすぎると、運用やタイミングによってはコンテンツ欠落を誘発することもあるため、まずは「必要な更新のコンテンツが確実に揃っている」状態を作ってから、補助的に整理するのが安全です。
| 施策 | 効果 | 今回の位置付け | 注意点 |
|---|---|---|---|
| Express 有効化 | 差分 cab を WSUS が保持できる | 本命 | 容量増・ファイル数増。ストレージ設計が必要 |
| 手動同期 | 不足ファイルの取得 | 本命 | 途中で失敗する要因（通信/容量/プロキシ）を潰す |
| wsusutil reset | DB と実体のズレ修正、欠落再取得 | 本命 | 時間がかかる。途中停止の原因調査が必要 |
| Cleanup Wizard / DB メンテ | パフォーマンス改善、不要更新整理 | 補助 | 先にやると必要コンテンツを削るリスクがある |
クライアント側の対処：Windows Update キャッシュをリセットして正常化
WSUS 側で cab が取得できる状態になったら、影響端末で Windows Update コンポーネントを掃除します。0% 固着や 0x80070020 を引きずる端末ほど、途中ダウンロードの残骸や SoftwareDistribution の不整合が残っていることが多いです。
以下は、現場でよく効くリセット手順の例です。管理者権限のコマンドプロンプトで実行し、実行後は再起動してから Windows Update を再実行します。
net stop bits
net stop wuauserv
Del "%ALLUSERSPROFILE%\Microsoft\Network\Downloader\qmgr*.dat"
move "C:\Windows\SoftwareDistribution" "C:\Windows\SoftwareDistribution.old"
move "C:\Windows\System32\catroot2" "C:\Windows\System32\Catroot2.old"
sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
net start bits
net start wuauservこの処理がやっていることは、ざっくり次の通りです。
| 操作 | 狙い | 副作用・注意 |
|---|---|---|
| BITS / wuauserv 停止 | 更新ダウンロード中のロックを外す | 実行中は更新が止まる。業務時間帯は避ける |
| qmgr*.dat 削除 | BITS ジョブの不整合を解消 | ダウンロード中ジョブは破棄される |
| SoftwareDistribution リネーム | 更新キャッシュ・履歴表示の元を再生成 | 設定画面の「更新履歴」が薄く見えることがある（表示上のもの） |
| catroot2 リネーム | 署名検証関連キャッシュの不整合を解消 | 初回は再生成に時間がかかることがある |
| sdset 再設定 | サービス権限の崩れを補正 | 環境標準と異なるポリシーがある場合は慎重に |
再起動後に、設定画面から更新チェックを実行します。コマンドでトリガーしたい場合は、環境により差はありますが、Windows 10 では UsoClient 系のトリガーを使う運用もあります（ただしポリシーやサービス状態によって結果が変わるため、まずは GUI の更新チェックで確認するのが確実です）。
0x80070020 が濃厚なときの追加観点（AV/EDR・バックアップ・監視ツール）
0x80070020 は「他プロセスがファイルを使用中」という意味合いで、以下が引き金になることもあります。
- ウイルス対策／EDR が
C:\Windows\SoftwareDistribution配下をリアルタイムスキャンしてロック - バックアップソフトやエンドポイント管理ツールが更新キャッシュを監視・保護してロック
- ディスクが逼迫して断続的に処理が止まり、リトライが多発してロック扱いになる
ただし今回のケースは「/Content の 404」が明確なので、まず WSUS 側の cab 実体を揃えるのが最短です。その上でまだ 0x80070020 が残る端末だけ、AV/EDR の例外設定やスキャン方針を点検すると、手戻りが減ります。
「一部の PC だけ」起きる理由：同じ WSUS でも端末ごとに挙動が揺れる
同じ WSUS を見ているのに、端末によって成功・失敗が分かれるのは珍しくありません。主な理由は次の通りです。
- 取得方式の差：端末が Express を要求する/しない、必要な差分が多い/少ないで、取りに行く cab が変わる
- キャッシュ状態の差：過去の途中ダウンロード、破損キャッシュ、古い BITS ジョブ残骸がある端末だけ 0% 固着しやすい
- 端末の更新レベル差：SSU/LCU の適用状況が違うと、要求するコンテンツ（差分ブロック）の組み合わせが変わる
- セキュリティ製品の動作差：同じ製品でもポリシー適用漏れや例外差でロックの出方が変わる
今回のトリガーは「WSUS 側に Express cab が無い（または不整合）」なので、端末差があっても根治策は共通で、WSUS の Content を正し、影響端末のキャッシュを掃除するのが王道です。
手動インストールが“入るのに回らない”理由：WSUS 配布の成否は別物
Microsoft Update Catalog から .msu/.cab を手動で入れると、その端末自体は更新できます。しかし WSUS 運用としては、次の点で噛み合わないことがあります。
- WSUS のレポートが更新されない：端末が次回の検出・報告サイクルを回していないと、WSUS 側の「必要/不要」が変わらない
- Windows Update の履歴表示に出ない/薄い：UI の「更新履歴」は表示用データが消える・欠けることがある（特にキャッシュリセット後）
- 同じ KB でも配布チャネルの差：WSUS で承認している更新と、手動で入れた更新の内部構成（適用判定）が一致しない場合がある
「入ったかどうか」を確認したい場合は、履歴画面だけで判断しないのがコツです。環境に応じて以下を併用します。
- コントロール パネルの「インストールされた更新プログラム」
winver（ビルド更新の確認）- DISM でパッケージ一覧を確認（SSU は CBS パッケージとして入ることがある）
再発防止：WSUS を「コンテンツ欠落させない」運用チェック
一度直しても、WSUSContent がまた欠落すると再発します。特に Express を使う環境は、ストレージと同期品質が生命線です。
| チェック項目 | 推奨頻度 | 見るべき観点 | ひとこと |
|---|---|---|---|
| WSUSContent の空き容量 | 週次 | 急激な増加、空き逼迫、ボリューム拡張計画 | Express 有効時は“余裕があるつもり”でも足りなくなる |
| 同期結果（失敗/警告） | 週次 | 途中失敗、上流接続、プロキシ、証明書 | 同期が欠けると「Ready でも実体が無い」が起きる |
| IIS の Content 参照先 | 構成変更時 | Content 仮想ディレクトリの物理パス | コンテンツ移行後のズレは 404 の典型 |
| wsusutil reset の計画実行 | 不整合兆候時 | DB と実体の突合、欠落再取得 | 常用より“異常時の復旧手段”として位置付ける |
| セキュリティ製品のスキャン対象 | 導入/更新時 | WSUSContent・SoftwareDistribution の過剰スキャン | ロックや遅延が疑われるなら例外も検討 |
また、Windows 10 1909 はサポートが終了しているため、セキュリティと運用負荷の観点では、可能な範囲でサポート期間内のバージョンへ移行すること自体が再発防止になります。現実的に残る端末がある場合でも、WSUS 側の不整合が出たときに素早く復旧できるよう、上記の監視ポイントを運用に組み込むのが効果的です。
よくある質問
Express を有効にすると WSUS のディスクが持たない。どうする？
Express は確かに容量・ファイル数が増えます。ただし今回のようにクライアントが Express cab を要求している状況では、WSUS 側に実体が無いと配布が破綻します。ストレージ増設が難しい場合は、WSUS の運用設計（製品/分類の見直し、不要更新の整理、コンテンツ置き場の移行など）を含めて “欠落しない形” に整えるのが現実的です。
WSUS コンソール上は Ready なのに、なぜ Content が無いことがある？
WSUS の「承認状態」「メタデータ」と、実際の WSUSContent 上の「ファイル実体」は別管理です。同期途中の失敗、容量不足、Content 移行後の不整合、手動削除、過度な Cleanup などで、コンソール上の見え方と実体がズレることがあります。404 が出たら実体不足が最優先です。
キャッシュリセットしたら更新履歴が消えた。問題？
表示上の「更新履歴」は、SoftwareDistribution をリネームすると薄くなることがあります。重要なのは実際に更新が適用されているかどうかなので、インストール済み更新や DISM のパッケージ一覧など、別の観点でも確認するのがおすすめです。
まとめ：最短で復旧するための流れ
- /Content/<hash>.cab が 404 かどうかを最初に確認し、WSUS 側の実体不足を確定させる
- WSUS の Express インストール ファイル設定を見直し、同期で不足ファイルを揃える
- コンソール上はあるのに実体が無い場合は wsusutil.exe reset で再取得を促す
- WSUS 側が直った後、影響端末で Windows Update キャッシュをリセットして 0% 固着・0x80070020 を解消する
SSU が落ちない状態は、その後の累積更新にも影響しやすいので、まずは「WSUS が 404 を返さない」状態を作り、次に端末側をクリアにする順序で進めるのが最も手戻りが少ない復旧手順です。
コメント