Windows Server 2019＋SQL Server 2019 で WSUS を構成したのに、ポストインストールタスクが失敗して管理コンソールが開けない／同期がすぐキャンセルされる…。この手の初期トラブルは、古い設定ファイルの残骸やコンテンツフォルダーの不整合・権限が原因のことが多く、順番どおりに切り分ければ復旧できます。
よくある症状と、最初に確認するポイント
WSUS の初期構築でつまずくときは、原因が「コンテンツ保存先（WSUSContent）」「Server Manager が保持している古い設定」「IIS／DB の作り直し漏れ」のどれかに寄っていることが多いです。まずは症状を整理し、確認先を決め打ちします。
| 症状 | ログ／確認場所 | 疑うポイント | まず試す対処 |
|---|---|---|---|
| Post installation task が必ず失敗する System.TypeInitializationException → Invalid installation directory | %TEMP%\WSUSSetup.log / イベントビューアー | Server Manager 側の設定ファイルに古い ContentDirectory が残っている | UpdateServices-Services.xml を退避して再実行 |
| WSUS／IIS を入れ直したら、同期が 10 分ほどで「Cancelled」になる | C:\Program Files\Update Services\LogFiles\Change.logWSUSCtrl.log | 同期処理の途中で例外／タイムアウト／IIS 側の停止が発生 | 該当時刻のログを見て、Report Viewer／IIS アプリプール／プロキシを優先確認 |
C:\Program Files\Update Services\Tools など一部フォルダーが作成されない | 役割と機能のインストール状態 IIS のサイト／アプリプール | 過去環境の残骸、機能の取りこぼし、OS アップグレード由来の不整合 | 完全削除 → 再インストール（必要なら MMC キャッシュ削除も） |
UpdateServices-Services.xml を削除しても作り直されない | C:\Windows\System32\ServerManager\ComponentConfiguration\ | Server Manager が参照する構成が壊れている／旧パス固定 | リネーム退避＋再インストール時に新規生成させる |
WSUS の「ポストインストールタスク」で行われること
WSUS の役割追加が終わった直後に実行されるポストインストールタスクは、見た目以上にやっていることが多く、どこか一つでも食い違うと失敗します。代表的には次の初期化・生成処理が含まれます。
- コンテンツ保存先（WSUSContent）の確定と、必要フォルダーの作成
- SUSDB（WSUS のデータベース）の作成・接続設定
- IIS（WSUS Administration サイト／アプリプールなど）の構成
- WSUS サービスの初期設定（同期・メタデータ処理の準備）
つまり「コンテンツ保存先のパスが無い／アクセスできない」「DB が残っている／権限が足りない」「IIS が中途半端」など、どれかが引っ掛かると Invalid installation directory のような一見わかりにくい例外として出ることがあります。
結論から：最短で復旧させる切り分けフロー
現場で時間を溶かしやすいのは、WSUS を何度も入れ直しながら原因が残ったまま上書きしてしまうことです。次の順番に沿うと、遠回りしにくくなります。
- Server Manager 側の古い設定ファイル（
UpdateServices-Services.xml）を疑い、退避してポストインストールを通す - コンテンツフォルダーの実体・権限を確認し、必要ならローカル管理者で作り直す
- OS アップグレード由来が濃いなら、MMC キャッシュ（
%APPDATA%\MMC\WSUS）を削除してから再インストール - それでもダメなら、DB／IIS／フォルダーを含めた完全削除を行い、クリーンに入れ直す
- 再インストール後の同期キャンセルは、Change.log と WSUSCtrl.log を起点に原因を特定する
UpdateServices-Services.xml が原因で「Invalid installation directory」になるケース
ログに System.TypeInitializationException → Invalid installation directory が出ており、さらに次のような文言が見える場合は、このパターンが最優先です。
GetConfigValue with filename=UpdateServices-Services.xml item=ContentLocalInvalid installation directory
なぜ起きるのか
C:\Windows\System32\ServerManager\ComponentConfiguration\UpdateServices-Services.xml は、Server Manager が役割の構成情報を保持するためのファイルです。ここに「WSUS のコンテンツ保存先（ContentDirectory）」が記録されており、次のような状態だとポストインストールでコケやすくなります。
- 指定されているドライブ／パスがすでに存在しない（例：以前は
T:\WSUSだったが今は無い） - フォルダーはあるが、WSUS が動くサービスアカウントから書き込めない
- 過去 OS からのアップグレードで「古いパス」がそのまま残っている
対処手順（まずは退避して再実行）
最も手戻りが少ないのは、問題の XML を削除ではなくリネームして退避し、ポストインストールを再実行する方法です。
- 管理者権限で次のファイルをリネーム（退避）します。
対象：C:\Windows\System32\ServerManager\ComponentConfiguration\UpdateServices-Services.xml
例：UpdateServices-Services.xml.oldに変更 - その状態で WSUS のポストインストールタスクを再実行します。
Server Manager の「通知」から再実行するか、wsusutil.exe postinstallを使える環境ならそれでも構いません。
コマンドで行う場合の例です（環境に合わせて読み替えてください）。
ren "C:\Windows\System32\ServerManager\ComponentConfiguration\UpdateServices-Services.xml" UpdateServices-Services.xml.old追加チェック：ContentDirectory の実体と権限
リネームで通っても、根本の「コンテンツフォルダー問題」が残っていると、後で同期やダウンロードで再発します。次をセットで確認してください。
| チェック項目 | 目安 | 確認方法の例 |
|---|---|---|
| ContentDirectory のパスが実在する | ローカルディスク上の NTFS フォルダー | エクスプローラーで開ける／空フォルダーでもよい |
| NETWORK SERVICE の書き込み権限 | 変更（書き込み）相当が付与されている | icacls で ACL を確認 |
| フォルダー所有者 | 不自然に別ドメインユーザーになっていない | プロパティ→セキュリティ→詳細 |
| ドライブの空き容量 | 更新プログラムの種類に応じて十分な容量 | 少なくとも数十 GB から（運用次第） |
権限を付け直す場合の例です（誤操作防止のため、実行前にパスを必ず確認してください）。
icacls "D:\WSUSContent" /grant "NT AUTHORITY\NETWORK SERVICE:(OI)(CI)M"コンテンツフォルダーを「組み込みのローカル管理者」で作り直すケース
コンテンツフォルダー（例：D:\WSUSContent）が存在しているのにポストインストールが失敗する場合、フォルダーの所有者・継承・アクセス権が微妙に壊れていることがあります。特に、ドメイン管理者で作成したフォルダーが、意図しない ACL 継承になっているケースは見落としがちです。
対処手順
- サーバーに「組み込みのローカル管理者（Administrator）」でログオンします（ドメイン管理者ではなくローカル）。
- 既存のコンテンツフォルダーを削除します（例：
D:\WSUSContent）。 - 同じパスに、ローカル管理者で新規フォルダーを作成します。
- WSUS のポストインストールタスクを再実行します。
この作り直しで、フォルダー所有者がサーバー側に戻り、サービスアカウントからのアクセスが素直になることがあります。再実行後は、前項の表にある権限（特に NETWORK SERVICE）も合わせてチェックしておくと安全です。
OS アップグレード環境で「古い MMC 設定」が邪魔をするケース
過去バージョンの Windows Server からアップグレードした環境では、WSUS 管理コンソール（MMC）の構成ファイルが残り、インストールや初期化の挙動が不安定になることがあります。典型例が次の症状です。
C:\Program Files\Update Services\Toolsなど一部フォルダーが作成されない- ポストインストールエラーが繰り返し発生する
sfc /scannowで一時的にフォルダーが現れるが、根本的に直らない
対処手順（MMC キャッシュのリセット）
- 問題が出ているユーザープロファイルでログオンした状態で、
%APPDATA%\MMC\を開きます。 - 中にある
WSUSという名前のファイルを削除します（拡張子が無い場合があります）。 - その後、WSUS を入れ直す場合は「完全削除 → 再インストール」を先に実施します。
このファイルは MMC の保存状態（キャッシュ）に近く、旧環境の情報を引きずっていると、管理コンソール側の不整合がインストールに影響しているように見えることがあります。削除しても次回起動時に再生成されるため、切り分けとして試す価値が高い手順です。
それでも直らない場合の「完全削除 → 再インストール」
ここまでの対処で改善しない場合は、WSUS／IIS／DB のどこかに「残骸」が残っている可能性が高いです。中途半端に上書きすると状況が悪化しやすいので、思い切ってクリーンに戻すのが近道になります。
実施前に押さえること（安全策）
- 既存 WSUS を運用中なら、承認設定・ターゲットグループ・自動承認ルールなどの「設定バックアップ」を取る
- DB を削除する手順が含まれるため、必要なら SUSDB のバックアップを取得する
- 同居サーバー（同じ IIS／SQL を他用途で使っている）では、削除対象を慎重に切り分ける
完全削除のチェックリスト
| 削除対象 | やること | ポイント |
|---|---|---|
| WSUS 役割 | 役割と機能から WSUS を削除 | 管理ツールも含めて削除し、再起動を挟む |
| SUSDB | SQL 利用ならデータベースをデタッチ／削除し、物理ファイルも削除 | 同名 DB が残ると再インストール時に詰まりやすい |
| WID（利用時） | WID インスタンスや関連機能の削除（環境により） | WID を使っていたのに SQL へ切り替える場合、残骸が競合することがある |
| IIS の WSUS 構成 | WSUS 用サイト／アプリケーションプール（例：WsusPool）を削除 | IIS を他用途で使う場合は「WSUS 関連のみ」削除 |
| インストールフォルダー | C:\Program Files\Update Services\ 配下を削除 | Tools が作られない症状は、ここが壊れていることも多い |
| コンテンツフォルダー | D:\WSUSContent 等、指定していた保存先を削除 | 権限不整合の温床になりやすいので一度消すのが確実 |
| 再起動 | 一連の削除後に再起動 | IIS／サービスの掴みっぱなしを解放する |
再インストール時に失敗しにくくするコツ
- コンテンツ保存先は、事前に「ローカルディスクの NTFS」上に作る（ネットワークドライブや不安定なドライブレターは避ける）
- SQL を使う場合は、WSUS が DB を作成できる権限（少なくとも初回作成時）を満たしているか確認する
- 役割追加後は、ポストインストールを一度で通すことを優先し、途中で再起動や追加作業を挟まない
ポストインストールは、実行方法が複数あります。環境に合わせて使い分けてください。
| 実行方法 | メリット | 注意点 |
|---|---|---|
| Server Manager の通知から実行 | GUI で追いやすい | 裏で参照する構成ファイル（XML）が壊れていると失敗し続ける |
wsusutil.exe postinstall | ログと挙動が読みやすい | Tools フォルダーが作成されていないと実行できない |
参考：コンテンツディレクトリを明示する例です。
"C:\Program Files\Update Services\Tools\wsusutil.exe" postinstall CONTENT_DIR="D:\WSUSContent"再インストール後に「同期が 10 分ほどでキャンセルされる」ケース
ポストインストールが通っても、同期が短時間で Cancelled になる場合は「同期処理のどこで止まっているか」をログで把握するのが最優先です。原因はネットワーク、IIS、DB、コンソール依存コンポーネントなど多岐にわたるため、闇雲に再インストールを繰り返すほど泥沼化します。
まず確認したいログ
| ログ | パス | 見るべきポイント |
|---|---|---|
| Change.log | C:\Program Files\Update Services\LogFiles\Change.log | キャンセル直前の例外、通信エラー、タイムアウト |
| WSUSCtrl.log | C:\Program Files\Update Services\LogFiles\WSUSCtrl.log | 同期処理の進行と停止理由（サービス側の目線） |
| SoftwareDistribution.log | C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log | メタデータ処理やコンテンツ取り扱いのエラー |
| イベントビューアー | アプリケーション／システム、IIS 関連 | IIS 停止、アプリプールのクラッシュ、SQL 接続失敗など |
ありがちな原因と、対処の当たりを付ける方法
| よくある原因 | 見え方 | 対処の例 |
|---|---|---|
| コンソール側のレポート関連コンポーネント不足 | レポートビューアー関連のメッセージが出る／コンソールが不安定 | 必要な Microsoft Report Viewer と依存する .NET を整合させ、インストール後に WSUS コンソールを閉じて開き直す |
| IIS の WsusPool が落ちる／再起動している | 同期中に 503 や接続切れが発生、短時間でキャンセル | IIS マネージャーで WsusPool の状態とイベントログを確認し、リサイクル設定やメモリ制限の影響を疑う |
| プロキシ／ファイアウォール／SSL 検査 | 外部への通信に失敗、一定時間後にタイムアウト | WSUS のプロキシ設定（必要なら）を見直し、宛先へのアウトバウンドが許可されているか確認 |
| SUSDB 側の問題（接続・権限・残骸） | 同期開始直後から DB 例外 | SQL ログイン権限、SUSDB の状態、再インストール時に同名 DB が残っていないか確認 |
ポイントは、「キャンセル」そのものを追うのではなく、キャンセルの直前に出ている最初のエラーを拾うことです。Change.log は時系列で追いやすいので、同期開始時刻を控えてから該当箇所を重点的に確認してください。
再発防止のための運用上のポイント
- コンテンツ保存先は「変えない」前提で決める：後からドライブレターを変えたり、フォルダーを移動するとトラブルの引き金になります。
- 権限は最初に固める：コンテンツフォルダーは作成者の癖が出やすいので、インストール前にローカル管理者で作成し、必要最小限の書き込み権限を付与します。
- OS アップグレードサーバーは「残骸がある前提」で疑う：WSUS は特に影響を受けやすい役割のため、可能なら新規構築が無難です。
- ログの場所を決めておく：Change.log／WSUSCtrl.log の2本を基準にすると、同期トラブルの初動が速くなります。
まとめ
Windows Server 2019 上で WSUS のポストインストールタスクが失敗する／同期がうまくいかないときは、まず UpdateServices-Services.xml とコンテンツフォルダーの整合性（存在・権限）を疑うのが近道です。それでも改善しない場合は、OS アップグレード由来の MMC キャッシュを削除し、最終的には DB／IIS／フォルダーを含めた完全削除 → 再インストールでクリーンに戻すと、原因の切り分けが一気に進みます。同期がキャンセルされる場合は Change.log を起点に、直前の最初のエラーから潰していくのが確実です。
コメント