Windows Server 2012/2016 のクラウド環境で、IIS の構成保存が突然できず、applicationHost.config 自体が消えている――現場でよく遭遇する深刻なインシデントです。本記事は実運用での復旧を前提に、原因の切り分けから安全な再生成・権限修復・恒久対策までを一気通貫でまとめました。最短復旧ルートと再発防止の両立を狙います。
目次
IIS の applicationHost.config 消失・保存不可の症状整理
対象は Windows Server 2012 / 2016（クラウドインスタンス含む）。IIS マネージャーでバインド追加やアプリケーションプール変更などを保存する際に 「Error: Cannot write configuration file」 が表示され、C:\Windows\System32\inetsrv\config\applicationHost.config が存在しない、または書き込みできない状態です。さらに C:\inetpub\history にも世代バックアップが残っていないケースがあります。
影響する操作の例
- サイト／バインドの追加・編集・削除
- アプリケーションプールの追加・設定変更（.NET CLR / パイプライン / ID 変更 など）
- 認証方式・モジュール・ハンドラー・圧縮などサーバーレベル設定の変更
よくある発生契機
- Windows Update 適用直後に消失（複数事例）。例として 2025年3月前後の累積更新（KB5032974 など） で報告あり（公式な事象公開は無し）。
- 誤った ACL 変更・権限剥奪による書き込み失敗
- セキュリティ製品による隔離・削除
- 運用スクリプトの誤動作／人的ミス
- 共有構成（Shared Configuration）やリダイレクション設定の不整合
主な原因候補（一覧）
| 区分 | 内容 | 確認ポイント |
|---|---|---|
| Windows Update | 特定の累積更新で IIS 関連ファイルが誤って削除・移動された事例。 | 適用履歴・再起動直後に事象発生／更新アンインストールで改善するか。 |
| アクセス権 | C:\Windows\System32\inetsrv\config の ACL 変更により IIS が書き込めない。 | 所有者・権限の逸脱（TrustedInstaller、Administrators、SYSTEM）。 |
| セキュリティ製品 | リアルタイム保護／EDR による隔離・削除。 | 当該時刻の隔離ログ・検疫ポリシー・除外設定。 |
| 手動・スクリプト | クリーンアップや構成反映バッチの副作用。 | 直近の運用変更・ジョブ履歴・変更管理台帳。 |
| 共有構成（重要） | Shared Configuration が UNC 共有を指しており、共有不通でローカルに書けない。 | IIS マネージャー「共有構成」／redirection.config の内容。 |
| スナップショット | クラウドのロールバックで一部のみ巻き戻り、履歴不整合。 | スナップショット／バックアップ・復元のタイムライン。 |
最短復旧を狙う初動（5〜10分）
- 管理者権限のコマンドプロンプト／PowerShell を起動。
- 構成フォルダーの存在・属性・権限を確認。
dir /a "C:\Windows\System32\inetsrv\config" icacls "C:\Windows\System32\inetsrv\config" attrib "C:\Windows\System32\inetsrv\config\applicationHost.config" - 共有構成の有無を確認（有効ならまず共有パスの可用性を回復）。
- IIS マネージャー（サーバー直下）→「共有構成」
- または
C:\Windows\System32\inetsrv\config\redirection.configを確認
C:\inetpub\historyにバックアップがあるか照会。dir /ad "C:\inetpub\history" dir /b /od "C:\inetpub\history\CFGHISTORY_*"- イベントログで削除・アクセス拒否・共有エラーの痕跡を確認（Application/System、IIS-Configuration）。
復旧パスの選択ガイド
以下の優先順で判断すると、ダウンタイムを最小化しやすくなります。
- 共有構成が有効 → 共有パス（UNC）の復旧または一時的にローカル構成へ戻す。
C:\inetpub\historyにバックアップがある → 最新世代を復元。- 同一 OS / IIS バージョンの別サーバーがある → ひな形としてコピーし、固有値を修正。
- バックアップも代替も無い → 既定ファイルを再生成（DISM / IIS 再インストール）。
詳細手順：権限（ACL）を正す
権限不整合は復元に先立って是正します。まず継承を有効化し、基本主体に付与します。
icacls "C:\Windows\System32\inetsrv\config" /inheritance:e ^
/grant "NT SERVICE\TrustedInstaller:(F)" ^
/grant "Administrators:(F)" ^
/grant "SYSTEM:(F)"IIS_IUSRSとNETWORK SERVICEに読み取り（RX）があるかも確認。- 所有者が
TrustedInstallerでない場合の例（必要時のみ）：takeown /F "C:\Windows\System32\inetsrv\config" /A /R icacls "C:\Windows\System32\inetsrv\config" /setowner "NT SERVICE\TrustedInstaller" /T
詳細手順：バックアップから復元
C:\inetpub\history\CFGHISTORY_XXXXXXXXを参照し、最も新しい世代を選択。- 同フォルダー内の
ApplicationHost.configをapplicationHost.configにリネームしてコピー。copy "C:\inetpub\history\CFGHISTORY_0000000XXX\ApplicationHost.config" ^ "C:\Windows\System32\inetsrv\config\applicationHost.config" - IIS を再起動。
iisreset
補足：バックアップが空の場合は、履歴の保持が既定（10世代）で上書き済みか、保護ソフト／清掃ジョブで削除された可能性があります。
詳細手順：別サーバーからのコピー（テンプレート化）
同一 OS・IIS バージョン、可能なら同一ロール構成のサーバーから applicationHost.config をコピーし、環境差分を手で調整します。
コピー後に必ず見直す固有項目
| 項目 | 確認・修正の要点 |
|---|---|
| サイト ID / 名前 | <sites> 内の id（重複禁止）、name。 |
| バインド | ポート／ホスト名／IP、証明書の拇印（thumbprint）。 |
| 物理パス | ローカル／UNC の有無、権限。 |
| アプリケーションプール | 存在と設定（.NET CLR、パイプライン、ID）。 |
| モジュール・ハンドラー | 不要なカスタム拡張の有無。 |
構文と参照整合性のクイックチェック：
"%windir%\System32\inetsrv\appcmd.exe" list site
"%windir%\System32\inetsrv\appcmd.exe" list apppool詳細手順：既定ファイルの再生成
OS 構成が破損している場合は、コンポーネント修復 → IIS の再インストールで既定の applicationHost.config を生成します。
- コンポーネント修復：
dism /online /cleanup-image /restorehealth sfc /scannow - 必要に応じて IIS の機能を一旦外し、再追加（設定を維持したい場合は事前にエクスポートを検討）。
dism /online /disable-feature /featurename:IIS-WebServerRole /Remove dism /online /enable-feature /featurename:IIS-WebServerRole /All - 再生成後は
iisresetを実行し、正常起動と既定サイトの応答を確認。
時短の裏技：最小構成で自動生成させる
ひとまず動く最小テンプレートが必要な場面では、空のファイルを置いてから appcmd で構成操作を促すと自動生成されます。
type nul > "C:\Windows\System32\inetsrv\config\applicationHost.config"
"%windir%\System32\inetsrv\appcmd.exe" add site /name:dummy /bindings:http/*:8080: /physicalPath:C:\inetpub\wwwrootその後、正規の設定へ書き換えてください（テンプレートは最小限です）。
IIS のリセットと検証ポイント
applicationHost.config復元後にiisresetを実施（空の状態では効果なし）。- バインドの整合性（重複ポート・重複ホスト名）。
- SSL バインドと証明書の拇印（
netsh http show sslcert）。 - アプリケーションプールの起動（停止→開始、イベントログにエラーがないか）。
共有構成（Shared Configuration）起因の典型例
共有構成を有効にしているサーバーでは、applicationHost.config はローカルではなく共有先を参照します。共有が切断・資格情報失効・SMB ポリシー変更などで読めなくなると、保存不可・消失に類似した挙動になります。
診断の要点
- IIS マネージャーの「共有構成」で有効か確認。
redirection.configに UNC パスが記載されていないか確認。- 共有先の可用性（ネットワーク／認証／権限）を回復。
- 緊急時は一時的に無効化してローカル構成に戻し、復旧後に再有効化。
イベントログとセキュリティログで削除トリガーを特定
- アプリケーション／システム：WAS/IIS 構成エラー、アクセス拒否。
- アプリケーションとサービスログ → Microsoft → Windows → IIS-Configuration（Operational）。
- セキュリティ製品（AV/EDR）の隔離ログ。
- グループポリシーや構成管理ツールの配布ログ。
恒久対策：消えない・戻せる・気づけるの三本柱
1) 消えない：権限・除外
C:\Windows\System32\inetsrv\configを誤検知しないよう、保護製品に適切な除外を設定。- 運用スクリプトは削除対象のパスをホワイトリスト方式で厳格化。
2) 戻せる：履歴の増加とオフサーバーバックアップ
IIS の履歴は既定で 10 世代。クリティカルなサーバーでは世代数の引き上げと外部保管を推奨します。
"%windir%\System32\inetsrv\appcmd.exe" add backup "daily-%DATE%"タスクスケジューラで毎日実行し、生成フォルダーを別ボリューム／別サーバーへコピーします。
3) 気づける：変更監査とアラート
- 監査ポリシー「オブジェクトアクセス」を有効化し、構成フォルダーへ成功・失敗の監査を設定。
- SIEM/ログ分析で削除イベントや権限変更を検知し、即時通知。
よくある追加質問（FAQ）
| 質問 | 回答 |
|---|---|
他サーバーの applicationHost.config をそのまま流用してよいか？ | 可能。ただしサイト ID、物理パス、証明書バインド等の固有値を編集しないと起動時エラーになります。コピー後は appcmd list site で構文確認を。 |
iisreset だけで直るか？ | ファイル自体が無い場合は効果がありません。復元または再生成後にサービス再起動が必要です。 |
| ファイル消失を引き起こす具体的な更新プログラムは？ | 2025年3月頃の KB5032974 で一部報告があります（公式公表は無し）。影響が疑われる場合はアンインストールまたは置き換えを検討してください。 |
| セキュリティ製品が原因か判別する方法は？ | 当該時刻の隔離ログ、リアルタイム保護を一時停止 → ファイル復元 → 再保存で再現有無を確認します。 |
履歴（C:\inetpub\history）が作られないのは？ | 既定設定の変更・権限不足・共有構成の有効化などが原因です。復旧後に履歴の世代数や保存先を見直してください。 |
32bit/64bit の appcmd はどちらを使う？ | 基本は 64bit（%windir%\System32\inetsrv\appcmd.exe）。混在環境ではコマンドパスを明示しましょう。 |
| 一時的に空ファイルを置くのは安全？ | 緊急避難としては有効ですが、テンプレートは最小限です。正規設定への置換を前提にしてください。 |
実運用で役立つコマンド集（そのまま貼り付け可）
権限の標準化と読み取り付与
icacls "C:\Windows\System32\inetsrv\config" /inheritance:e ^
/grant "NT SERVICE\TrustedInstaller:(F)" ^
/grant "Administrators:(F)" ^
/grant "SYSTEM:(F)" ^
/grant "IIS_IUSRS:(RX)" ^
/grant "NETWORK SERVICE:(RX)"バックアップの取得・復元
"%windir%\System32\inetsrv\appcmd.exe" add backup "manual-%DATE%-%TIME%"
"%windir%\System32\inetsrv\appcmd.exe" list backup
"%windir%\System32\inetsrv\appcmd.exe" restore backup "manual-XXXX"サイト・アプリプールの健全性チェック
"%windir%\System32\inetsrv\appcmd.exe" list site
"%windir%\System32\inetsrv\appcmd.exe" list apppool
netsh http show sslcert
netsh http show urlaclPowerShell：毎日バックアップ＋世代管理のサンプル
# 保存先：D:\IIS-Config-Backup\<yyyyMMdd> に世代保管
$stamp = Get-Date -Format 'yyyyMMdd'
$dst = "D:\IIS-Config-Backup\$stamp"
New-Item -ItemType Directory -Force -Path $dst | Out-Null
& "$env:windir\System32\inetsrv\appcmd.exe" add backup "daily-$stamp"
Copy-Item "C:\inetpub\history\CFGHISTORY_*" $dst -Recurse -Force
# 30世代を超えた分を削除
Get-ChildItem "D:\IIS-Config-Backup" | Sort-Object Name -Descending | Select-Object -Skip 30 | Remove-Item -Recurse -Force変更管理とロールバック設計の勘所
- Windows Update 適用前に VM スナップショットまたはボリュームレベルのスナップショットを取得。
- IIS 構成変更は「エビデンス（差分）」＋「即時バックアップ（appcmd add backup）」をセットで。
- 共有構成や自動デプロイ（CI/CD）を併用する場合、構成の単一系統化（ソースオブトゥルース）を徹底。
トラブルシュートのフロー（テキスト版）
- 共有構成の有無を判定（有効なら共有障害を先に解決）。
- 構成フォルダーの ACL を標準化。
C:\inetpub\historyにバックアップがあれば復元。- なければ同型サーバーからテンプレートコピー → 固有値修正。
- それも不可なら DISM/SFC → IIS 再インストールで再生成。
iisreset→appcmdチェック → 動作検証。- 原因（更新、AV、スクリプト、監査）をログで特定し、恒久対策。
まとめ
applicationHost.config の消失は、原因が多岐にわたる一方で復旧の型は明確です。共有構成の判定 → 権限の是正 → バックアップ復元 → テンプレート適用 → 再生成 の順で迷わず進め、復旧後は履歴拡充・監査・除外設定の三点で再発を防ぎましょう。Windows Update 起因の可能性が疑われる場合も、更新のロールバックや置き換えで影響を遮断しつつ、構成の「消えない・戻せる・気づける」を実装することが最短の安定運用に直結します。
コメント