WSUS 役割を持つ Windows Server 2012 R2 を Windows Server 2016 へインプレースアップグレードした後、サーバー上で WSUS コンソール（MMC）を開くたびに「Post Installation Wizard」が繰り返し表示され、完了時に失敗する――そんな症状は多くの場合「アクセス許可（権限）」が原因です。この記事では、ログの見方から具体的な権限修正ポイント、再発防止までを手順で解説します。
症状：WSUS MMC を開くたびに Post Installation Wizard（ポストインストール ウィザード）が出続ける
Windows Server 2012 R2（WSUS 役割あり）から Windows Server 2016 へインプレースアップグレードした直後、次のような現象が起きることがあります。
- WSUS 自体は稼働しており、更新の同期やクライアント配布も「動いているように見える」
- 別端末からリモート接続した WSUS MMCでは正常に管理できる
- しかしサーバー上で WSUS MMC を起動すると毎回 Post Installation Wizard が表示され、完了時にエラーになる
- レジストリ上の
WsusContentパスは正しく見えるのに直らない
この「ローカルだけウィザードが出続ける」パターンは、単なるパス不整合よりもアクセス許可（権限）不足が根本原因になっているケースが多いです。特に、エラー詳細に次のような例外が含まれている場合は可能性が高まります。
System.Security.SecurityException: Request for principal permission failed.
なぜリモートでは正常に見えるのに、ローカルではウィザードが出続けるのか
リモートからの WSUS MMC 接続は、基本的に「既に稼働している WSUS サービス（Update Services / IIS）」に対して管理操作を行います。つまり、サービス側が必要な権限を持っていれば、クライアント端末の MMC からでも多くの操作は成立します。
一方、サーバー上で表示される Post Installation Wizard は、初期構成（またはアップグレード後の再構成）としてローカル環境の設定情報を書き換える処理が含まれます。代表的には以下のような作業です。
- WSUSContent などのコンテンツ ディレクトリへの読み書き
- WSUS セットアップ用レジストリキーへの値の更新
- IIS（WsusPool）や関連設定ファイルへのアクセス
ここで、UAC による昇格不足や、ドライブ直下／レジストリキーの ACL が想定より厳しくなっていると、ウィザードが「途中で失敗 → 次回起動時も未完了扱い → 何度でも出る」というループになります。
まず確認したいポイント（切り分けチェック）
闇雲に権限を広げる前に、症状の再現条件と不足箇所を絞ると安全です。次の表の順で確認すると、原因に当たりやすくなります。
| 確認項目 | 見る場所・手段 | 分かること |
|---|---|---|
| ローカル MMC だけでウィザードが出るか | サーバー上で WSUS 管理コンソール起動 | 「初期構成の書き込み系」の問題に寄る |
| リモート MMC は安定して操作できるか | 管理端末から WSUS へ接続 | WSUS サービス自体は動作している可能性が高い |
| 例外に SecurityException が出ているか | ウィザードの詳細／イベントログ／WSUS ログ | アクセス許可不足の線が濃い |
| WSUSContent の配置先がローカルディスクか | ディスクの管理、net use、エクスプローラー | マップドライブ/ネットワーク経由だと失敗要因になりやすい |
| WSUS の実行主体（サービス/IIS）が何か | サービス、IIS マネージャー | 付与すべきアカウント（NETWORK SERVICE / IIS AppPool\WsusPool 等）が確定する |
解決の本筋：WSUS の「アクセス許可（権限）」を正しく整える
結論から言うと、このトラブルは権限不足で起きることが多く、対処も「どこに」「誰が」アクセスできていないかを潰していく形になります。ここからは、実際に解消報告が多い順に、具体的な対処を紹介します。
WSUSContent のあるドライブとフォルダー権限を見直す
まずはコンテンツの置き場所です。WSUS は更新ファイルの保存やメタデータ処理で、コンテンツ ディレクトリ配下へ継続的に読み書きします。インプレースアップグレード後に ACL が引き継がれず、想定より厳しくなっていると失敗します。
E: が「ローカルディスク」であることを確認する
- エクスプローラーで E: を右クリックし、種類・接続先がネットワークでないことを確認
- マップドライブが疑わしい場合は、管理者のコマンドプロンプトで
net useを実行し、E: の割り当てがないか確認
WSUSContent を UNC パスやマップドライブへ置く構成は、権限・接続状態・UAC の影響を受けやすく、ウィザード失敗の原因になりやすいです。可能であればローカルディスク上へ置くのが安全です。
ドライブ直下（例：E:\）に「読み取り」権限が必要になるケース
盲点になりやすいのがドライブ直下の ACL です。WSUSContent フォルダーに権限を付けても、ドライブ直下の「一覧表示/読み取り」が足りないことで、結果的にパス解決やアクセスが失敗する事例があります。
| 対象 | 推奨する権限（目安） | 付与候補（環境により異なる） |
|---|---|---|
| E:\（ドライブ直下） | 読み取り & 実行 / フォルダーの一覧表示 | NETWORK SERVICE、または IIS AppPool\WsusPool |
| WSUSContent フォルダー（例：E:\WSUS\WsusContent） | 変更（読み取り/書き込み/作成/削除） | WSUS が実際に使う主体（後述で確認） |
「誰に付けるべきか」は、WSUS/IIS の実行主体によって変わります。次の手順で必ず確認してください。
- サービスの実行アカウント：サービス管理ツールで「Update Services」など WSUS 関連サービスのログオン アカウントを確認
- IIS のアプリプール：IIS マネージャーで
WsusPoolの「詳細設定」→「ID」を確認（NetworkServiceやApplicationPoolIdentityなど）
アプリプールが ApplicationPoolIdentity の場合、Windows 上では仮想アカウント IIS AppPool\WsusPool としてアクセスします。ファイル ACL を付与する際は、この名前で追加できるか確認します（環境により表記揺れがあります）。
権限付与の例（icacls を使う場合）
GUI での変更が不安な場合、icacls で現状を保存してから変更すると戻しやすくなります。以下は一例です（フォルダー名や付与先は環境に合わせて読み替えてください）。
rem 現状の ACL をバックアップ
icacls E:\WSUS /save C:\Temp\wsus_acl_backup.txt /t
rem 例：ドライブ直下に一覧表示/読み取り（This folder only 相当）
icacls E:\ /grant "NETWORK SERVICE:(RX)"
rem 例：WSUSContent 配下に変更権限（継承あり）
icacls E:\WSUS\WsusContent /grant "NETWORK SERVICE:(M)" /tドライブ直下へ過剰な権限（変更/フルコントロール）を付ける必要は通常ありません。まずは「読み取り/一覧表示」で足りるかを見て、必要最小限で調整するのが安全です。
WSUS コンソール（MMC）を「管理者として実行」する
インプレースアップグレード後は、管理者グループに所属していてもUAC で昇格していないプロセスからは、レジストリの書き込みや一部フォルダーへの更新が失敗することがあります。ウィザードが「設定を書いて完了する」タイプの処理を含む場合、これだけで改善するケースがあります。
- スタートメニューから「Windows Server Update Services」を探す
- 右クリック → 管理者として実行
改善した場合でも、根本に ACL 問題が残っていることがあるため、次に紹介するフォルダー／レジストリ権限も合わせて点検すると再発しにくくなります。
WSUS セットアップ用レジストリキーの権限を確認する
ウィザードが繰り返し出る環境で、実際に効果が報告されているのが、次のレジストリキーの ACL 見直しです。
HKLM\Software\Microsoft\Update Services\Server\Setup
ここにはコンテンツ パスや構成に関わる値が格納され、ウィザードが完了処理で参照・更新することがあります。アップグレードやセキュリティ設定の影響で、このキーに対する書き込み権限が不足すると、ウィザード完了に失敗し「未完了扱い」のままになります。
安全に作業するための前準備
- レジストリを操作する前に、対象キーをエクスポートしてバックアップします
- 可能ならスナップショットやバックアップ取得など、ロールバック手段も用意します
権限の付与方針
最小権限は環境で異なりますが、トラブルシュートの観点では次の順に試すと安全です。
| 段階 | 付与先 | 権限 | 狙い |
|---|---|---|---|
| 1 | Administrators / SYSTEM | フルコントロール（既にあるか確認） | ベースの管理権限が欠けていないか |
| 2 | ウィザード実行ユーザー | 読み取り＋必要に応じて書き込み | 昇格不足やポリシーでブロックされていないか |
| 3 | WSUS が実際に使う主体 | 必要な範囲で追加 | サービス/アプリプールが更新できるようにする |
実際の解消例として、上記キーに対してフルコントロール権限を付与したところ、以降 Post Installation Wizard が表示されなくなった報告があります。運用方針上、恒久的にフルコントロールを付けたくない場合は、原因特定後に権限を絞り直す運用も検討してください。
WsusPool.config（IIS 側の一時設定）の権限を確認する
WSUS は IIS 上で動作する Web アプリケーションでもあるため、IIS のアプリプールが参照する設定ファイルの権限不足が原因になることがあります。代表例が次のような場所です（環境によりフォルダー名の大文字小文字が違うことがあります）。
C:\inetpub\temp\appPools\WsusPool\WsusPool.config
ここに対して、WsusPool の実行主体（例：NETWORK SERVICE や IIS AppPool\WsusPool）が読み取れないと、構成読み込みに失敗して間接的にウィザード失敗へつながることがあります。
このファイルは IIS が生成する一時ファイルのため、恒久的な変更が適切かは環境依存です。まずは「アクセス拒否」が出ていないか、イベントログや IIS ログと合わせて確認し、必要であれば権限を戻せる形で調整します。
実行コマンドで仕上げる：wsusutil postinstall を使った再構成
権限を整えたあとでもウィザードが残る場合、WSUS のポストインストール処理をコマンドで実行し、構成を明示的に完了させる方法があります。WSUS のツール wsusutil.exe を使います。
一般的な例（コンテンツ ディレクトリを指定するケース）は次のようになります。
"%ProgramFiles%\Update Services\Tools\wsusutil.exe" postinstall CONTENT_DIR=E:\WSUS\WsusContentデータベースを外部 SQL にしているなど、環境によっては追加のパラメーターが必要になります。まずは「現在の構成」を確認し、誤った指定で別フォルダーへ移行してしまわないよう注意してください。
確認に役立つログの見方（エラーの根拠を固める）
「権限が原因」といっても、どこで失敗しているかは環境ごとに違います。再発防止のためにも、ログから根拠を取っておくと後々ラクです。以下は代表的な確認先です。
| ログ/場所 | 確認するポイント | 補足 |
|---|---|---|
| イベント ビューアー（アプリケーション/システム） | アクセス拒否、.NET 例外、IIS 関連の失敗 | SecurityException が出る場合は特に注目 |
| WSUS 関連ログ（Update Services 配下の LogFiles など） | ポストインストール、同期、コンテンツ取得の失敗 | 環境によりファイル名/場所が異なるため「LogFiles」で検索すると早い |
| IIS ログ | WSUS サイトへの 401/403、アプリプールの停止 | WsusPool が落ちていないかも確認 |
| ウィザード実行ユーザーの一時フォルダー（%TEMP%） | セットアップ系ログ（WSUSSetup など）の出力 | 実行ユーザーごとに出力先が変わる |
ログに「アクセスが拒否されました」「権限がありません」などの表現が出る場合、対象パスや対象キーがほぼ特定できます。その場所の ACL を確認し、必要最小限で修正するのが理想です。
具体的な修正手順（おすすめの順番）
現場での手戻りを減らすため、実施順を整理します。次の順で対応すると、影響範囲を小さく保ちながら解消しやすいです。
- WSUS MMC を管理者として実行し、現象が止まるか確認する
- WSUSContent の配置先がローカルディスクであることを確認する（マップドライブ排除）
- ドライブ直下とWSUSContent フォルダーの ACL を確認し、必要な主体に権限を付ける
- レジストリ
HKLM\...\Update Services\Server\Setupの権限を確認し、必要なら修正する C:\inetpub\temp\appPools\WsusPool\WsusPool.config周辺の権限/アクセス拒否を確認する- 最後に
wsusutil postinstallを実行して構成を完了させる
上から順に実施し、各段階で WSUS MMC を閉じて開き直し、ウィザードが出るか/完了するかを確認します。原因箇所が一つとは限らないため、「直ったように見える」段階でも、少なくともコンテンツとレジストリの ACL は点検しておくのが無難です。
よくある落とし穴と対策
フォルダーだけ直して、ドライブ直下の権限を見落とす
WSUSContent フォルダーに権限を付けたのに直らない場合、ドライブ直下の「一覧表示」が足りないことがあります。特に、セキュリティ強化でドライブ直下の継承を切っている環境で発生しやすいです。
WSUS の実行主体を確認せずに、別アカウントへ権限を付けてしまう
NETWORK SERVICE で動いていると思い込んで権限を付けたが、実際は IIS AppPool\WsusPool だった、というのは頻出です。IIS のアプリプール ID と、WSUS 関連サービスのログオン アカウントは必ず確認してください。
「管理者グループだから大丈夫」と思って昇格しない
UAC が有効な環境では、管理者グループ所属でも昇格していないプロセスは制限されます。ウィザードが失敗する場合、まずは「管理者として実行」を習慣化するとトラブルシュートが早くなります。
権限を広げすぎて運用リスクを増やす
ドライブ直下へフルコントロール、Everyone へ変更権限、といった対応は短期的には直っても、監査や運用上のリスクが大きくなります。ログで原因箇所を絞り、ドライブ直下は最小（読み取り/一覧表示）、WSUS 配下だけ変更権限、というように分離するのが安全です。
最終確認：ウィザードが消えた後にチェックすべきこと
Post Installation Wizard が出なくなっても、「WSUS が本当に健全か」は別問題です。最低限、次の項目を確認しておくと安心です。
- WSUS コンソールをサーバー上で再起動しても、ウィザードが出ない
- IIS の
WsusPoolが停止していない（繰り返し落ちていない） - 同期が正常に完了し、更新がダウンロードできる
- クライアントがスキャンし、必要な更新が配布される
- イベントログにアクセス拒否や .NET 例外が継続して出ていない
ここまで確認できれば、インプレースアップグレード後の「見た目だけ直った」状態ではなく、運用に耐える状態へ戻せます。
まとめ：繰り返し表示は「未完了」ではなく「書き込みに失敗している」サイン
WSUS をインプレースアップグレードした後に、サーバー上で WSUS MMC を開くたび Post Installation Wizard が出続ける場合、権限不足が原因であることが多いです。System.Security.SecurityException が出ているならなおさらです。
ポイントは、WSUSContent フォルダーだけでなくドライブ直下、そして HKLM\...\Update Services\Server\Setup のレジストリ権限、さらに IIS（WsusPool）周辺のアクセス権までを「実行主体に合わせて」整えることです。権限が整った状態で必要なら wsusutil postinstall を実行し、構成を完了させれば、ローカルでも安定して WSUS を管理できるようになります。
コメント