以下の内容はhttps://error-daizenn.hatenablog.com/entry/2026/01/30/003338より取得しました。


Windows Server 2022のドメインコントローラーで「0x80073701」更新失敗を直す実践ガイド(安全策から再構築まで)

 

Windows Server 2022のドメインコントローラーで「0x80073701」更新失敗を直す実践ガイド(安全策から再構築まで)

ドメインコントローラー(DC)上で Windows Update やアプリ導入のたびに Error: 0x80073701 が出る――これは現場でよくある「コンポーネントストア(CBS)」絡みの不整合が原因になりやすい厄介な症状です。しかも DC は重要なのに、役割的には“作り直せる”という性質もあり、深追いし過ぎると時間だけ溶けます。この記事では、まず試すべき安全な手当から、CBS の欠損パッケージを潰す手順、そして **DC として最も堅い解決(置き換え)**まで、判断基準付きで整理します。

0x80073701とは何が起きているのか

0x80073701 = ERROR_SXS_ASSEMBLY_MISSING(必要なアセンブリが見つからない) という系統のエラーで、更新処理が参照するはずのコンポーネント/パッケージ情報が欠けていたり、存在しないパッケージを CBS が解決しようとして失敗している状態で発生します。
体感としては「KB を当てようとすると即エラー」「何を入れても更新だけ失敗」になりがちです。

まずは“低リスク”の切り分け(30分でやる)

DC である以上、いきなり大手術をする前に、リスクが低い順に潰します。

1) 「再起動」ではなく“完全シャットダウン”を試す

Windows は再起動でも状態が残るケースがあり、更新適用のフックがうまく走らないことがあります。
完全シャットダウン → 起動を一度挟み、同じ KB/同じ操作で再現するか確認します。

2) 更新コンポーネントの一般的な修復

以下は定番の修復ルートです(DCでも実行自体は一般に問題になりにくい部類)。

  • DISM でコンポーネントストア修復

  • SFC でシステム整合性チェック

  • Windows Update 関連サービスのリセット(SoftwareDistribution / catroot2 など)

ただし、0x80073701 は「CBS が存在しないパッケージを追っている」タイプだと、この一般策だけでは戻りません。

本命:CBSが「存在しないパッケージ」を追っている場合の直し方

このエラーの典型は、CBS に“入っていない KB のパッケージ”が登録されていて、解決不能になっている状態です。ポイントは次の2択です。

方向性A:不足パッケージを特定して手動導入する

  1. CBS / WindowsUpdate のログから、欠けているパッケージ名(Package_for_KBxxxxxxx…)を拾う

  2. Microsoft Update Catalog から対象 KB/関連パッケージを探す

  3. 通常インストールでダメなら、依存順や前提 KB を含めて当て直す

この方法は「正攻法」ですが、対象が多数だと時間が溶けるのが難点です。

方向性B:レジストリ上の“幽霊パッケージ”を無効化する(慎重に)

CBS が参照するパッケージ情報は、概ね次の場所にあります。
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages<PackageName>

ここに「存在しないはずのパッケージ」が並んでいると、更新がその場でコケます。対処としては、代表的に以下の発想になります。

  • そのパッケージキーを削除(リスク高め)

  • CurrentState を調整して、CBS が“未適用/無視”扱いにする(比較的現実的)

注意点:

  • DC でこの手を打つなら、**必ず事前にバックアップ(できればシステム状態含む)**を確保してください。

  • 欠損が「1つ」ではなく「連鎖」していることがあり、1回直して再実行→次の欠損が出るを数回繰り返すケースがあります。

  • 手作業が厳しければ、PowerShell で欠損パッケージを列挙してループ処理するアプローチが現実的です(環境差が大きいので、社内の変更管理に沿って運用してください)。

「インプレースアップグレード(2022→2022)」はDCでやっていい?

結論から言うと、“可能”でも、DCでは優先順位は高くありません。理由はシンプルで、DC は役割的に「重要だが交換可能」だからです。

インプレース修復(同一バージョン上書き)は、CBS/コンポーネントストアを丸ごと整える狙いがあり、症状に刺さることはあります。ただし DC だと次の観点で慎重になります。

  • 失敗時の影響が大きい(認証・DNS・GPO・レプリケーション)

  • 追加役割(DHCPなど)が乗っていると復旧設計が難しくなる

  • そもそも“直すより置き換え”が短時間で確実なことが多い

よって推奨の判断基準はこうです。

  • DCが複数台あり、追加DCを立てられる → 置き換えが第一候補

  • 単独DC、かつ増設が難しい → 低リスク策→CBS修復→最終手段としてインプレース検討

最も堅い解決:DCを“置き換える”

経験則ですが、0x80073701 を深追いして数日溶かすより、新しい DC を追加して役割移行した方が早いことが多いです。大枠の流れは次の通りです。

  1. 新しい Windows Server 2022 を用意

  2. ドメイン参加 → AD DS 追加で 追加DC化(DNSも必要に応じて)

  3. レプリケーション正常化を確認

  4. FSMO など役割があれば移行

  5. 旧DCに同居している役割(DHCP等)を計画的に移す

  6. 旧DCを降格(demote)して撤去

ポイント:

  • 「DC はクリティカルだがディスポーザブル」という考え方はかなり実務的です。

  • DHCP などが同居している場合でも、移行手順を切れば十分置き換え可能です。

  • “更新できないDC”を抱え続ける方が、セキュリティ面でも運用面でも損失が大きくなります。

失敗しないためのチェックリスト

最後に、どの道を選んでも事故率が下がる実務チェックをまとめます。

  • 変更前に バックアップ(可能ならシステム状態)

  • DC が複数なら、レプリケーション健全性を先に確認

  • 役割同居(DHCP/DNS/ファイル共有等)の洗い出し

  • 直す作業は「小さく」「戻せる」単位で実施(1回ごとに更新再実行)

  • 長期化しそうなら、早めに 置き換え案へスイッチ


0x80073701 は「原因の芯」に当たれば直せますが、DC という前提がある以上、“修理”と“交換”のコスト比較が重要です。低リスク策で改善しないなら、CBS 欠損パッケージの整理に進み、それでも長引く兆しがあれば、追加DCを立てて置き換えるのが最短で安全な着地になりやすいです。




以上の内容はhttps://error-daizenn.hatenablog.com/entry/2026/01/30/003338より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14