Windows Server 2016の累積更新プログラムが失敗してロールバックする原因と対策：エラー0x800f0922のレジストリ修正手順

Windows Server 2016で累積更新プログラム（Cumulative Update）が「100%まで進むのに再起動後に元に戻る」「更新を完了できませんでした。変更を元に戻しています。」と表示されて適用できない。しかもエラーコードは0x800f0922──この現象に遭遇すると、セキュリティ更新が滞留し、監査や運用リスクが一気に高まります。
本記事では、特定条件で起きやすい“更新のロールバック問題”を、原因の考え方から安全な修正手順、再発防止の運用ポイントまでまとめて解説します。

Windows Server 2016の累積更新プログラムが失敗してロールバックする原因と対策：エラー0x800f0922のレジストリ修正手順

起きている症状：100%完了後に再起動でロールバック、0x800f0922が出る

問題の典型例は次の流れです。

Windows Updateまたは手動適用で累積更新が進み、完了したように見える（100%）
再起動時に更新処理が走る
途中で「更新を完了できませんでした。変更を元に戻しています。」となりロールバック
エラーコードとして 0x800f0922 が記録される

複数台のServer 2016がある環境で「一部のサーバだけ失敗する」という形で出ることも多く、原因切り分けが難しく感じられます。

影響を受けやすい環境：2012 R2からアップグレードしたServer 2016

この問題は、クリーンインストールのServer 2016よりも、Windows Server 2012 R2からアップグレードしたServer 2016で発生しやすいのがポイントです。
アップグレード過程で残った“古い登録情報”が、新しい更新プログラムが追加しようとする構成と衝突して、更新が失敗するパターンです。

原因の本質：イベントログプロバイダ（WINEVT）のレジストリ衝突

累積更新の中には、Windowsのイベントログ（WINEVT）に関する登録を更新・追加するものがあります。ここで、既存のイベントログプロバイダ登録が競合すると、更新は「適用不能」と判断してロールバックします。

焦点となるのが、次のGUIDのプロバイダ登録です。

{53e3d721-2aa0-4743-b2db-299d872b8e3d}

更新時に新しいイベントログチャネルを登録しようとした際、すでに同GUID相当の情報が存在し、整合性が取れないため失敗します。ログ（CBS.log）では、既存プロバイダ宣言との競合を示す記述が見つかることがあります。

対策の結論：競合しているレジストリキーをバックアップ後に削除する

対策はシンプルで、競合しているレジストリキーを削除してから更新を再実行することです。
ただしレジストリ操作は影響が大きいため、必ずバックアップを取ってから実施してください。運用環境では、可能ならメンテナンスウィンドウを確保し、事前にスナップショットやシステムバックアップも推奨します。

実施手順（安全第一）：バックアップ → 削除 → 更新再実行

Step 1：対象キーをエクスポートしてバックアップする

Windows + R → regedit → Enter
次へ移動
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers
サブキー {53e3d721-2aa0-4743-b2db-299d872b8e3d} を右クリック
[エクスポート] を選び、.reg を安全な場所に保存

このバックアップがあることで、万一問題が起きても元に戻す道が残ります。

Step 2：競合キーを削除する（GUIまたはコマンド）

Option A：レジストリエディタ（GUI）で削除

{53e3d721-2aa0-4743-b2db-299d872b8e3d} を右クリック → [削除]

Option B：管理者のコマンドプロンプトで削除
管理者としてコマンドプロンプトを開き、次を実行します。

bat

reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{53e3d721-2aa0-4743-b2db-299d872b8e3d}" /f

GUIより再現性が高く、手順書化にも向いています。複数台に展開する場合もコマンド運用が有利です。

Step 3：Windows Update（または手動適用）を再実行する

キー削除後、改めて累積更新を適用します。多くのケースで、これでロールバックが止まり、正常に更新が完了します。

失敗が続く場合に見るべき追加ポイント

レジストリ衝突が主因でも、環境によっては別要因が重なっていることがあります。次の観点も併せて確認すると、復旧までの時間を縮められます。

1）保留中の再起動や更新の“詰まり”を解消する

更新が連鎖的に失敗している場合、まずは確実に再起動を挟み、更新履歴や保留状態を整理します。メンテナンス手順として「更新前に再起動」を入れるだけで改善することもあります。

2）コンポーネントストアの整合性（DISM/SFC）を確認する

システムファイルやコンポーネントストアの破損があると、別の理由でロールバックすることがあります。標準的には以下の流れで検証します（運用ポリシーに従い実施）。

DISMで修復（環境によりソース指定が必要な場合あり）
SFCで整合性チェック

3）更新の適用順・依存関係を整理する

セキュリティ更新が多数滞留していると、前提パッケージやSSU相当の扱いが影響することがあります。可能なら、更新を段階的に進め、失敗点がどこかを明確にします。

再発防止の運用ポイント：同種トラブルを“面倒な一発事故”で終わらせない

この手の問題は「一度直して終わり」ではなく、運用改善に繋げると効果が大きいです。

2012 R2→2016アップグレード機の棚卸し：該当機だけに起きるトラブルを早期発見できる
更新検証用のステージング環境：本番前に“ロールバック型”を潰せる
変更手順のテンプレ化：レジストリ操作はチェックリスト化し、バックアウト手順（.reg戻し）まで含める
ログ確認の定型化：CBS.logやイベントログの当たり方を手順書に残し、属人化を防ぐ

まとめ：0x800f0922の更新ロールバックは“WINEVTの競合”を疑うと早い

Windows Server 2016の累積更新が100%からロールバックし、0x800f0922が出る場合、特に「2012 R2からのアップグレード機」では WINEVTのPublishers配下に残った競合キーが原因になり得ます。
ポイントは、該当GUIDキーを必ずバックアップしてから削除し、更新を再実行すること。これにより、長引く更新失敗を短時間で解消できる可能性が高まります。

運用上の損失（更新停滞、監査指摘、復旧作業の長期化）を避けるためにも、同様のサーバが複数あるなら、該当条件の端末を洗い出して計画的に対処していくのがおすすめです。