
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:不足パッケージを特定して手動導入する
-
CBS / WindowsUpdate のログから、欠けているパッケージ名(Package_for_KBxxxxxxx…)を拾う
-
Microsoft Update Catalog から対象 KB/関連パッケージを探す
-
通常インストールでダメなら、依存順や前提 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 を追加して役割移行した方が早いことが多いです。大枠の流れは次の通りです。
-
新しい Windows Server 2022 を用意
-
ドメイン参加 → AD DS 追加で 追加DC化(DNSも必要に応じて)
-
レプリケーション正常化を確認
-
FSMO など役割があれば移行
-
旧DCに同居している役割(DHCP等)を計画的に移す
-
旧DCを降格(demote)して撤去
ポイント:
-
「DC はクリティカルだがディスポーザブル」という考え方はかなり実務的です。
-
DHCP などが同居している場合でも、移行手順を切れば十分置き換え可能です。
-
“更新できないDC”を抱え続ける方が、セキュリティ面でも運用面でも損失が大きくなります。
失敗しないためのチェックリスト
最後に、どの道を選んでも事故率が下がる実務チェックをまとめます。
-
変更前に バックアップ(可能ならシステム状態)
-
DC が複数なら、レプリケーション健全性を先に確認
-
役割同居(DHCP/DNS/ファイル共有等)の洗い出し
-
直す作業は「小さく」「戻せる」単位で実施(1回ごとに更新再実行)
-
長期化しそうなら、早めに 置き換え案へスイッチ
0x80073701 は「原因の芯」に当たれば直せますが、DC という前提がある以上、“修理”と“交換”のコスト比較が重要です。低リスク策で改善しないなら、CBS 欠損パッケージの整理に進み、それでも長引く兆しがあれば、追加DCを立てて置き換えるのが最短で安全な着地になりやすいです。