Windows 11でIISがインストールできない時の原因と対処法|エラー0x800f0922/CBS_E_INSTALLERS_FAILEDの解決手順

Windows 11 環境で IIS を有効化しようとしたとき、「エラー 0x800f0922(CBS_E_INSTALLERS_FAILED)」が出て先に進めない――しかも DISM や CBS のログにも同じエラーが並び、何を直せば良いのか分からない。この記事は、実際に同様のトラブルに遭遇したケースをもとに、原因と再現しにくい解決手順、そして再発防止策までをまとめた実践的な解説です。

目次

Windows 11 で IIS がインストールできない問題の概要

まずは、今回のトラブルの全体像を整理します。症状だけを見ると「IIS のインストールに失敗した」という一言で済みますが、背景には Windows Update とシステムファイルの破損が絡んでいました。

発生していた現象

管理者権限のコマンドプロンプト、または PowerShell から以下のコマンドを実行して IIS を有効化しようとします。

Dism /Online /Enable-Feature /FeatureName:IIS-DefaultDocument /All

ところが、処理の途中で次のエラーコードが返され、IIS を有効化できません。

  • HRESULT = 0x800f0922
  • DISM ログおよび CBS ログにも CBS_E_INSTALLERS_FAILED が記録される

コマンドライン上では「コンポーネントのインストールに失敗しました」といったメッセージで終わるだけで、何が壊れているのかは一見して分かりません。

トラブルが起こるまでの経緯

今回のケースでは、以下のようなステップで問題が発生しました。

  1. 2025 年 8 月の累積更新プログラムを適用後、IIS Manager(管理ツール)の UI が壊れる既知の不具合に遭遇。
  2. 問題を解消するため、一度 IIS をアンインストール。
  3. その後の整理中に誤操作で、以下の IIS 関連フォルダーを手動削除してしまう。
    C:\Windows\System32\inetsrv
    C:\inetpub
  4. 以降、再度 DISM で IIS を有効化しようとしても、0x800f0922 が必ず発生するようになった。

ポイントは、「単に IIS をアンインストールしただけでなく、システムが管理している IIS 関連フォルダーを手動で削除してしまった」という点です。この操作が、コンポーネントストアの整合性を大きく壊してしまいました。

エラー 0x800f0922 / CBS_E_INSTALLERS_FAILED の意味

0x800f0922 は Windows Update のエラーとしてもよく知られていますが、今回のように IIS コンポーネントの有効化時にも発生 します。CBS_E_INSTALLERS_FAILED というメッセージが表しているのは、簡単に言うと「必要なインストーラー/コンポーネントが揃わず、機能を追加できなかった」という状態です。

具体的には、以下のような状態が考えられます。

  • IIS のバイナリファイルや設定ファイルが物理的に欠損している
  • コンポーネントストア(WinSxS)内のメタデータと実体ファイルの整合性が取れていない
  • DISM や Windows Update が参照するソースに、必要なファイルが存在しない/読み取れない

今回のケースでは「IIS 関連フォルダーを手動削除したこと」により、IIS の実体ファイルが消えてしまったにも関わらず、コンポーネントストア側では「削除された」と認識されていませんでした。その結果、IIS を再度インストールしようとしても、必要な部品を正しく展開できずに 0x800f0922 で失敗していたと考えられます。

状態コンポーネントストア実際のファイル結果
正常「IIS はアンインストール済み」IIS 関連ファイルは適切に削除済み必要に応じて再インストールが可能
今回のケース「IIS はアンインストール済み」だがメタ情報が壊れているフォルダーを手動削除済みで、足りないファイルが多数再インストール時に 0x800f0922 / CBS_E_INSTALLERS_FAILED

解決の全体像:OS の整合性を戻してから IIS を入れ直す

このようにコンポーネントストアが壊れている場合、IIS だけをどうにかしようとしても解決しません。今回の根本解決は、次の 3 ステップに整理できます。

  1. DISM と SFC で OS コンポーネント全体の整合性を可能な限り修復する
  2. 修復インストールで、手動削除してしまった IIS 関連ファイルを含めて Windows を上書き修復する
  3. 改めて DISM で IIS を再インストールし、IIS Manager の UI も含めて動作を確認する

以下で、それぞれのステップを詳しく解説します。

DISM と SFC でシステムファイルを修復する

まずは、今の Windows イメージにどれだけ破損があるかを確認しつつ、自動修復を試みます。ここでは定番の DISM と SFC を使用します。

実行したコマンド

管理者権限のコマンドプロンプト(または PowerShell)で、次の順番でコマンドを実行します。

DISM /online /cleanup-image /restorehealth
SFC /scannow

DISM がコンポーネントストアの破損を検出し、可能な範囲で修復した後に、SFC がシステムファイルを正しい状態に置き換える、という流れです。ログを確認すると、多数の OS コンポーネントが修復されたことが分かりました。

コマンド役割ポイント
DISM /online /cleanup-image /restorehealthコンポーネントストア(WinSxS)の破損を検出・修復ネットワークや Windows Update の状態に影響される。時間がかかることが多い。
SFC /scannowシステムファイルを正しいバージョンに置き換えるDISM 実行後に行うことで、より多くのファイルが正常状態に戻る。

ただし、今回のように「OS に含まれているはずの IIS 関連フォルダーを手動で削除した」ケースでは、DISM と SFC だけでは完全には戻せない部分が残る場合があります。そのため、次のステップとして Windows 自体の「修復インストール」が必要になりました。

修復インストールで Windows を上書き修復する

DISM と SFC で修復できる範囲には限界があります。コンポーネントストアのメタ情報と、実際のファイル構成の差異が大きくなりすぎているときには、Windows 自体を上書き修復する「修復インストール」が有効です。

修復インストールとは

ここでいう修復インストールとは、ユーザーのデータ・アプリ・設定を保持したまま、Windows のシステムファイル一式を再展開する作業 のことです。一般的な「初期化」や「クリーンインストール」と違い、環境を維持しながら OS を健全な状態に戻せるのが特徴です。

今回のケースでは、次のような手順で実行しました。

  • [設定] > [システム] > [回復] を開く
  • 「Windows Update を使用して問題を修正」を選択
  • 「今すぐ再インストール」を実行
  • 個人ファイル・アプリ・設定を保持したまま、OS を上書き修復

複数回の再起動を挟み、今回はおおよそ 6 時間程度で完了しました。時間はネットワーク速度や PC の性能によって前後しますが、「夜間に実行して放置しておく」といった運用を想定すると安心です。

項目内容
保持されるものユーザーのドキュメント、アプリ、ほとんどの設定
上書きされるものWindows のシステムファイル、標準コンポーネント(IIS を含む)
所要時間環境によるが数時間規模(今回は約 6 時間)
メリットクリーンインストール並みに OS をクリーンアップしつつ、既存環境を維持できる

この修復インストールによって、手動削除してしまった C:\Windows\System32\inetsrv や C:\inetpub を含む IIS 関連ファイルが、クリーンな状態で復元されました。それに伴い、DISM や Windows Update が参照するソースも再構築され、コンポーネントストアの整合性も改善されました。

IIS の再インストールとエラー解消の確認

修復インストールが完了したら、あらためて DISM から IIS の有効化を実施します。

再インストールに使用したコマンド

Dism /Online /Enable-Feature /FeatureName:IIS-DefaultDocument /All

今回は、このコマンドが問題なく完走し、0x800f0922 は発生しなくなりました。必要なコンポーネントが正常に展開され、IIS の既定の Web サーバー機能が有効になっていることを確認済みです。

あわせて、以下のような確認を行っておくと安心です。

  • inetmgr コマンドで IIS Manager が起動するか
  • IIS Manager の UI が途中で真っ白になったり、スナップインエラーを出さないか
  • 「Windows の機能の有効化または無効化」で、必要な IIS 機能(ASP.NET や WebDAV など)が正しく表示されているか

IIS Manager UI の不具合も解消

もともとの発端であった「2025 年 8 月の累積更新プログラム適用後に IIS Manager の UI が壊れる」問題についても、修復インストール後に IIS を入れ直すことで解消しました。

これは、IIS に関わる管理スナップイン(MMC)や関連 DLL、UI リソースが最新の状態で再展開されたためと考えられます。Windows Update での不具合や途中失敗によって中途半端なバージョンになっていたファイルが、修復インストールによって正常な組み合わせに戻ったと推測されます。

再発防止と追加チェックポイント

今回のトラブルは、「IIS をアンインストールしたあと、関連フォルダーを手動で削除した」という操作が引き金でした。同じような問題を再発させないために、意識しておきたいポイントを整理しておきます。

項目推奨アクション補足
IIS 関連フォルダーの手動削除禁止原則として、コンポーネントストアが管理するフォルダーは手動削除しない。不要な場合は「Windows の機能」や DISM を通じてアンインストールする。手動削除は、DISM や Windows Update では検出しきれない破損を生むことがある。削除してしまった場合は、修復インストールで戻すのが現実的。
DISM + SFC の定期実行大型アップデート直後やトラブル発生時に、DISM /restorehealth と SFC /scannow をセットで実行する。早期に破損を検出・修復することで、深刻な状態になる前に手を打てる。
IIS 機能を一括指定して有効化例:
DISM /Online /Enable-Feature /FeatureName:IIS-WebServerRole /All
依存関係をまとめて導入できるため、個別機能だけを有効化するよりも失敗しづらい。
サードパーティ製 AV・セキュリティソフト必要に応じて一時的にリアルタイム保護を停止し、DISM や Windows Update を実行する。インストーラーが IIS 関連ファイルを展開するときにロックされると、エラーにつながりやすい。
オフライン ISO を使った修復ネットワークが不安定な環境では、同ビルドの Windows ISO をマウントし、DISM の /Source オプションを指定する。例:/Source:wim:X:\sources\install.wim:1 など。オンラインソースよりも安定して修復できる。

DISM・SFC 実行時の具体的なコツ

DISM と SFC は「実行するだけ」で終わらせず、ログの内容をざっと確認しておくと、後の判断がしやすくなります。

実行の順番と再起動タイミング

  • まず DISM /online /cleanup-image /restorehealth を実行し、完了を待つ
  • その後、SFC /scannow を実行する
  • SFC の結果で「いくつかのファイルを修復しました」「一部修復できませんでした」といったメッセージが出る
  • 修復が行われた場合は、一度再起動したうえで IIS の再インストールを試す

この時点で 0x800f0922 が解消されれば、修復インストールまで行く必要はありません。今回のケースのように、DISM/SFC を実行しても状況が大きく改善しないときに、修復インストールを検討する流れが現実的です。

ログ確認のポイント

時間が許すなら、以下のログを軽く眺めておくと、問題切り分けの精度が上がります。

  • C:\Windows\Logs\DISM\dism.log
  • C:\Windows\Logs\CBS\CBS.log

これらのログに 0x800f0922 や CBS_E_INSTALLERS_FAILED が集中して出ている場合、コンポーネントのインストール処理そのものが失敗していることが分かります。特定のファイル名やパスが一緒に記録されていれば、それが手掛かりになります。

IIS 周辺の状態を確認する追加テクニック

再インストールの前後で、IIS がどのような状態になっているかを確認するために、PowerShell を使うのも有効です。

Optional Feature の状態を確認する

Get-WindowsOptionalFeature -Online -FeatureName IIS-WebServerRole, IIS-DefaultDocument

このコマンドで、IIS の主要機能が Enabled なのか Disabled なのか、あるいは Enable Pending のような中途半端な状態なのかを確認できます。修復インストール後は、IIS 関連の機能が正常な状態に戻っているはずです。

GUI からの確認も併用する

コマンドラインが苦手な場合や、最終確認としては、GUI から状態を確認するのがおすすめです。

  • [設定] > [アプリ] > [オプション機能] > [その他の Windows 機能]
  • 「インターネット インフォメーション サービス」にチェックが入り、下位項目が正しく展開・選択できるか

ここで選択やチェック状態が不自然な場合は、まだ何かしらの破損が残っている可能性があります。その場合は、もう一度 DISM/SFC を実行し、必要なら修復インストールの再検討も視野に入れてください。

よくある疑問と注意点

Q. 0x800f0922 は Windows Update エラーと同じもの?

A. はい、同じ番号のエラーコードです。ただし、発生している文脈が違うため、原因も異なります。Windows Update の文脈では「予約領域不足」や「ネットワーク接続」などが原因になることが多いのに対し、今回のような IIS 有効化の文脈では「コンポーネントストアと実体ファイルの不整合」が主な原因でした。

Q. 削除した C:\Windows\System32\inetsrv をバックアップから戻せばよかった?

A. バックアップが完全で、かつ OS のビルドやパッチレベルが完全に一致しているなら可能性はありますが、実際にはリスクが高い方法です。コンポーネントストア側の情報と同期が取れない ままファイルだけ戻しても、別のエラーを誘発することがあります。現実的には、今回のように修復インストールで OS 全体を整合させる方が安全です。

Q. 修復インストールを行うタイミングの目安は?

A. 次のような条件が複数当てはまる場合は、修復インストールを検討する価値があります。

  • DISM /restorehealth と SFC /scannow を複数回実行しても、エラーが解消しない
  • 決まったコンポーネントの有効化・無効化で毎回同じエラーコードが出る
  • ログに同じエラーメッセージが繰り返し記録されている
  • 手動でシステムフォルダーを削除した覚えがある

「最後の手段」と考えがちな修復インストールですが、Windows 11 では比較的安全・手軽に実行できるようになっているため、深刻なシステム破損には積極的に活用を検討しても良いでしょう。

まとめ:IIS の 0x800f0922 は OS レベルの整合性から見直す

Windows 11 で IIS をインストールしようとした際の 0x800f0922(CBS_E_INSTALLERS_FAILED) は、単純な「IIS の設定ミス」ではなく、OS コンポーネントの整合性が崩れているサイン である可能性が高いエラーです。

今回のケースでは、

  • IIS アンインストール後に C:\Windows\System32\inetsrv と C:\inetpub を手動で削除した
  • その結果、DISM と Windows Update が期待する IIS 関連ファイルとメタ情報が噛み合わなくなった
  • DISM・SFC で多くの破損は修復できたものの、完全な整合性には至らず 0x800f0922 が継続した
  • 最終的に、修復インストールで Windows を上書き修復し、IIS を再インストールすることで問題が解消した

という流れで解決に至りました。

同様のトラブルに遭遇した場合は、やみくもにレジストリを削除したり、別のサーバーからファイルをコピーしてくる前に、

  • DISM /restorehealth と SFC /scannow のセット実行
  • コンポーネントストアとログの状態確認
  • 必要に応じた修復インストールの検討

という順番で、OS 全体の整合性から見直す ことをおすすめします。そうすることで、IIS のインストールエラーだけでなく、将来の Windows Update やその他の機能追加トラブルの予防にもつながります。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次