Windows Server 2019からWindows Server 2022へアップグレードした後、累積更新プログラムKB5005619だけが0x80073701で失敗し、DISMやSFCでも回復しない。そんな「1台だけ更新できない」状況で有効だった、同一バージョンISOを使うオフラインのインプレース修復アップグレード手順と注意点をまとめます。
発生した症状：KB5005619 のインストールが 0x80073701 で止まる
対象は Windows Server 2019 から Windows Server 2022（Server OS Version 21H2）へアップグレード済みのサーバー群で、ほとんどの端末は問題なく更新できるのに、特定の1台だけ累積更新プログラムが適用できない、というパターンです。更新の画面では次のような状況が確認されます。
更新プログラムのインストール中に問題が発生しました。(0x80073701)
- 「2021-09 累積更新プログラム for Microsoft Server OS Version 21H2 (x64) (KB5005619)」のインストールに失敗する
- エラーコードは 0x80073701
- サーバーの役割・アプリ構成が複雑で、できれば再構築や移行は避けたい
さらに厄介なのが、一般的な「更新失敗の定番手順」を一通りやっても改善しない点です。具体的には、以下を実施しても状況が変わらないケースがあります。
- KB5005619（.msu）の手動インストール
DISM /Online /Cleanup-Image /ScanHealth//CheckHealthDISM /Online /Cleanup-Image /RestoreHealth（WIMを指定しても改善しない）sfc /scannowchkdsk
この時点で「Windows Update周りの一時的不具合」よりも、OS内部のコンポーネント（コンポーネントストア／WinSxS）側に根の深い問題がある可能性が高くなります。
エラー 0x80073701 の意味：ERROR_SXS_ASSEMBLY_MISSING
0x80073701 は、Windows のエラーとしては ERROR_SXS_ASSEMBLY_MISSING（Side-by-Sideアセンブリが見つからない）に相当します。ざっくり言うと、Windowsが更新を適用するために必要なコンポーネント（アセンブリ）が、OSの内部ストアから欠落している、または整合性が壊れている状態です。
累積更新プログラム（LCU）は「差分」ではなく「その時点までの更新をまとめて適用する」仕組みなので、本来は一つ入れれば追いつける反面、適用の土台になるコンポーネントストアが破損していると、途中で一気に失敗します。DISMやSFCが効くケースも多いのですが、破損の度合いが大きいと修復しきれないことがあります。
| 用語 | ざっくり説明 | 壊れると起きやすい症状 |
|---|---|---|
| コンポーネントストア（WinSxS） | 更新や機能追加のための部品を保管する場所 | 累積更新が失敗、役割追加が失敗、DISMがエラーで止まる |
| SxSアセンブリ | Windows内部で参照されるコンポーネント単位の「部品」 | 「必要な部品が見つからない」系のエラー（0x80073701 等） |
| CBS（Component Based Servicing） | 更新の適用を司る仕組み。ログもここに集まる | CBS.log に「Missing」「Cannot repair」などが残る |
同じ手順でアップグレードしたのに「1台だけ」壊れる理由は、現場では珍しくありません。アップグレード前後のパッチレベル差、途中の再起動タイミング、ストレージやアンチウイルスの介入、追加言語パックや機能（FOD）などの差分が、最終的にコンポーネントストアの不整合として表面化することがあります。
まずやるべき切り分け：復旧前に最低限チェックしておくポイント
インプレース修復アップグレードは強力ですが、いきなり実行するよりも、まずは「その作業が適切にできる状態か」を確認しておくと失敗を減らせます。特に、ISOの不一致（エディション・言語違い）や、再起動保留、空き容量不足があると詰まりやすいです。
| チェック項目 | 確認方法（例） | ポイント |
|---|---|---|
| OSのエディション | systeminfo / 設定画面 | Standard / Datacenter / Evaluation の一致が重要 |
| OSの言語 | 設定 > 時刻と言語 | 日本語OSなら日本語ISOを使用。言語違いは「保持」が出ない原因 |
| 現在のビルド | winver | Windows Server 2022（21H2）であることを再確認 |
| 再起動保留 | Windows Updateの画面 / サービス再起動 | 保留があると修復がこじれる。先に再起動して状態を揃える |
| 空き容量 | エクスプローラー / Get-PSDrive | システムドライブは余裕を確保（更新・修復は一時領域を多く使う） |
| バックアップ | イメージバックアップ / VMスナップショット | 「戻せる手段」がある状態で実施。特にDCや重要システムは必須 |
| ドメインコントローラー（該当時） | dcdiag / repadmin /replsummary | レプリケーションとSYSVOLの健全性を確認。可能ならシステム状態バックアップ |
ログを確認する場合は、次のあたりが入口になります（原因特定にこだわりすぎず、状況の裏取りに使うイメージです）。
- CBSログ：
C:\Windows\Logs\CBS\CBS.log - DISMログ：
C:\Windows\Logs\DISM\dism.log - Windows Update：
Get-WindowsUpdateLogで生成したWindowsUpdate.log（必要な場合）
なぜ DISM / SFC で直らないことがあるのか
DISMやSFCは万能ではありません。ざっくり整理すると、修復が成功する条件は「参照すべき正しいソースがある」「破損が軽微」「依存関係が連鎖的に壊れていない」などです。今回のように 0x80073701（アセンブリ欠落）まで進んでいると、次の理由で詰みやすくなります。
| よくある行き詰まり | 起きていること | 結果 |
|---|---|---|
| DISMが「修復できません」となる | 必要な部品がコンポーネントストア側に存在しない | 修復対象そのものが欠落していて埋め戻せない |
| WIMを指定しても直らない | WIMのインデックスが違う／エディションが違う／言語が違う | 正しい部品を参照できず、結果が変わらない |
| SFCは「修復した」と言うが再発する | 表層のシステムファイルは直るが、CBS/WinSxSの整合性が戻らない | 更新適用の段階で再び失敗する |
つまり「DISMを何度回しても同じ」段階では、アプローチを変える必要があります。そこで有効になりやすいのが、次に紹介する同一バージョンのインプレース修復アップグレードです。
解決策の結論：Windows Server 2022 を「オフライン」でインプレース修復アップグレードする
最終的に有効だったのは、Windows Server 2022 のインストールISOを使って、同一バージョンのインプレース修復インストール（アップグレード）を実行する方法です。ここでのポイントは、セットアップにインターネットから更新プログラムを取りに行かせない（Not right now）ことです。
インプレース修復アップグレードは、「OSを上書きインストールするが、役割・機能・アプリ・設定・データを可能な限り保持する」ための手段です。コンポーネントストアの部品をISO由来の正しい状態へ戻しやすく、DISMやSFCで直らない更新失敗に対して現実的な一手になります。
なぜ「オフライン」が効くのか
同じインプレースでも、セットアップにオンラインで更新を取りに行かせると、環境によっては「今の状態＋最新更新」を一気に当てにいきます。破損している環境ではその差分適用がさらに複雑になり、結果として修復の成功率が下がることがあります。まずはISOの内容で“素の部品”を揃えてから、改めてWindows Updateを実行する方が、手戻りが少ないのが現場の実感です。
実施前の準備：失敗しないためのチェックリスト
本番サーバーで作業する場合は、手順そのものよりも「準備不足で詰む」ケースが多いです。特に、ISOの不一致とバックアップ不足は致命傷になりやすいので、ここは手を抜かないでください。
| 準備 | やること | 目安・注意 |
|---|---|---|
| 完全バックアップ | システムイメージ／VMスナップショット／システム状態バックアップ | ロールバックできる状態を作る（復旧手段がない修復は危険） |
| メンテナンス時間 | 複数回の自動再起動が入る前提で確保 | 再起動回数や所要は環境依存。サービス停止影響も見込む |
| ISOの用意 | 同じエディション・同じ言語・同じメディア種類を準備 | 違うと「個人ファイルとアプリを引き継ぐ」が選べない |
| 空き容量の確保 | システムドライブの空き容量を増やす | Windows.oldや一時ファイルが増える。不要ファイル削除も検討 |
| セキュリティ製品 | 必要なら一時停止や除外設定（社内ルールに従う） | インストール時のファイル置換をブロックすることがある |
手順：Windows Server 2022 のオフライン・インプレース修復アップグレード
ここからが具体的な手順です。GUIで進めてもよいですが、サーバー管理の観点からは「どこで何を選んだか」を残せるよう、作業記録を取りながら実施するのがおすすめです。
ISO をサーバー上でマウントする
Windows Server 2022 のインストール ISO をサーバーにコピーし、マウントします。エクスプローラーから右クリックで「マウント」でも構いません。PowerShellで実施する例は次のとおりです（Server Coreでも実行できます）。
Mount-DiskImage -ImagePath "C:\ISO\WS2022.iso"マウント後、ドライブレター（例：D:）が割り当てられます。
setup.exe を実行して修復インストールを開始する
マウントしたドライブ直下の setup.exe を実行します。管理者として実行したい場合は、管理者権限のコマンドプロンプト／PowerShellから起動してもOKです。
D:\setup.exe「更新プログラムのダウンロード方法」を変更し、オフラインにする
セットアップの初期画面で「セットアップが更新プログラムをダウンロードする方法を変更」に相当するリンクを開き、「今は実行しない（Not right now）」を選択します。
この選択が、今回の解決策の核心です。ここでオンライン更新を許可すると、環境によっては修復の途中で余計な差分が混ざり、結果として更新失敗が再現することがあります。
「個人ファイルとアプリを引き継ぐ」を選択して進める
インストールの種類の選択で、「個人ファイルとアプリを引き継ぐ（すべて保持する）」を選びます。これにより、役割・機能・アプリケーション・設定を保持したまま、OSのコンポーネントが上書き修復されます。
もしこの選択肢が表示されない／グレーアウトする場合は、ほぼ確実にISOの不一致（エディション・言語・メディア種類）です。慌てて進めず、いったん中断してISOを見直してください。
完了まで進め、再起動後に Windows Update を実行する
セットアップが完了すると再起動が入り、最終的にログオン画面へ戻ります。ログオン後は、通常どおり Windows Update を実行します。修復によりコンポーネントストアの欠損が補われるため、問題のKB5005619を含めて更新が通るようになることが期待できます。
なお、使用したISOが古い場合、修復後の状態は「ISOの時点のパッチレベル」に近づきます。そのため、修復完了＝最新化ではありません。修復後に必ずWindows Updateで最新の累積更新を当て直す前提で作業計画を立ててください。
修復後にやること：成功確認と再発チェック
修復が終わったら「更新が入ったか」だけでなく、「コンポーネントストアの状態が落ち着いたか」も確認しておくと安心です。最低限、次の確認を行います。
| 確認内容 | コマンド／場所 | 期待される結果 |
|---|---|---|
| コンポーネントストアの健全性 | DISM /Online /Cleanup-Image /ScanHealth | 破損が検出されない／修復可能と判断される |
| システムファイル | sfc /scannow | 整合性違反が見つからない、または修復完了 |
| 更新の適用 | 設定 > Windows Update / 更新履歴 | KB5005619 が正常にインストールされる（または後続のLCUが適用される） |
| サービス稼働 | サービス監視／イベントログ | 役割・アプリの起動に異常がない |
| Windows.old の扱い | ディスク クリーンアップ／ストレージ設定 | 問題がないことを確認後、必要に応じて削除して容量を回収 |
特に、本番系のIIS、SQL Server、ファイルサーバー、AD DS、WSUS、バックアップエージェントなど、OSに深く依存する役割がある場合は、再起動後のヘルスチェック（サービス状態、ポート応答、ログイン、ジョブ）を一通り行いましょう。
つまずきポイント集：インプレース修復がうまくいかない典型例
ここでは「やってみたけど進めない」「選択肢が出ない」といった場面で、切り分けに使える典型パターンをまとめます。
| 症状 | よくある原因 | 対処 |
|---|---|---|
| 「個人ファイルとアプリを引き継ぐ」が出ない | ISOのエディション／言語／評価版が一致していない | 現在のOSと同じメディアを入手し直す。ISOの種類を揃える |
| セットアップが途中でエラー終了する | 空き容量不足、ドライバ互換、セキュリティ製品の介入 | 空き容量確保、不要デバイスの整理、セキュリティ製品の方針確認 |
| 完了したのに Windows Update がまだ失敗する | 追加言語パック／機能の不整合、更新コンポーネント側の破損 | WUコンポーネントのリセット、DISMのソース再確認、ログ解析へ進む |
それでも更新できない場合の次の一手
インプレース修復で改善するケースが多い一方、環境によっては「破損が深い」「過去の更新が積み残っている」「ISOと実機の状態が想定以上にズレている」などで、まだ失敗することがあります。その場合は、次の順で追加の手を検討します。
DISM のソース指定を“正しく”見直す
すでに /Source:WIM: を試していても、インデックス指定がずれていると、修復が成立しないことがあります。Windows Server 2022 のISO内には sources\install.wim（または install.esd）があり、その中に複数エディションが収録されています。まずは収録情報を確認します。
DISM /Get-WimInfo /WimFile:D:\sources\install.wim表示された一覧から、対象OSに一致するインデックス（例：Standard か Datacenter か）を選び、改めて修復します。
DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:＜Index＞ /LimitAccessWindows Update コンポーネントをリセットする
コンポーネントストアの破損とは別に、Windows Update の作業用フォルダーやカタログが壊れている場合もあります。インプレース修復後もWUが不安定なら、次のリセットを試す価値があります（実行前に業務影響と運用ルールを確認してください）。
net stop wuauserv
net stop bits
net stop cryptsvc
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start msiserver
net start cryptsvc
net start bits
net start wuauservログから「何が欠けているか」を特定して、対応を決める
原因に迫りたい場合は CBS.log が最も情報量があります。例えば、エラー行に「0x80073701」や「Missing」「Cannot repair」が含まれることが多いので、まずは抽出して眺めます。
findstr /c:"0x80073701" C:\Windows\Logs\CBS\CBS.log > C:\Temp\cbs_80073701.txt
findstr /i /c:"missing" C:\Windows\Logs\CBS\CBS.log > C:\Temp\cbs_missing.txtログ解析に時間をかける価値があるのは、同様の構成サーバーが多数あり、再発時の標準手順を作りたい場合です。単発のサーバーで「とにかく早く直す」が目的なら、インプレース修復→WUリセットまでで決着することも多いです。
最終手段：新規構築＋移行を検討する（現実的な判断基準）
更新がどうしても入らない状態を長期運用するのは、セキュリティ面でも運用面でもリスクが大きくなります。次の条件に複数当てはまる場合は、修復に固執せず「新規構築＋移行」が結果的に早いことがあります。
- インプレース修復を複数回試しても更新失敗が続く
- コンポーネントストア破損が「修復不可能」と判定される
- 重要ロールが少なく移行が比較的容易（例：単純なファイルサーバー等）
- 既存サーバーがすでにライフサイクル上限やハード老朽化に近い
ただし、今回のように「構成が複雑で移行が難しい」場合は、まずインプレース修復で直るかを試す価値が十分あります。成功すれば、設定やアプリを維持したまま更新基盤を立て直せます。
再発防止の運用ヒント：更新トラブルを起こしにくいサーバーにする
同じタイプの問題を減らすには、日々の運用で「更新が途中で壊れない」ようにすることが重要です。特に、アップグレード直後の数回のパッチ適用は失敗が起きやすいので、以下のポイントを意識すると安定します。
- 更新適用はメンテナンスウィンドウを確保し、途中で強制停止しない
- 再起動が必要な更新は、先送りせず計画的に実施する
- アップグレード前後で「言語パック」「追加機能（FOD）」「不要な役割」を整理する
- セキュリティ製品の更新・監視設定が、OS更新を妨げないように調整する
- 同一バージョンのISOを保管し、復旧手段としてすぐ使える状態にしておく
まとめ：0x80073701 の“頑固な更新失敗”は、同一バージョンISOのオフライン修復が効く
Windows Server 2022 で KB5005619 が 0x80073701 で失敗し、DISMやSFCでも改善しない場合、原因はコンポーネントストアの欠落・破損である可能性が高いです。このレベルになると、正面からの修復よりも、同一バージョンのインプレース修復アップグレードでOS内部の部品を上書きして整合性を取り戻す方が、短時間で現実的に解決しやすくなります。
重要なのは、セットアップで「今は実行しない（Not right now）」を選び、オフラインで修復すること、そして作業前に確実なバックアップを取ることです。修復後に Windows Update が正常化すれば、再構築・移行を避けつつ、セキュリティ更新のサイクルへ復帰できます。
コメント