WSUSで更新プログラムを承認しているのに、クライアントは「ダウンロードまでは進むのに、自動インストールが実行されない」――この現象は、WSUS側ではなくクライアント側のWindows Updateポリシー設定が原因で起きがちです。特に見落としやすい「自動メンテナンス中にインストール」の挙動を整理し、狙った時刻に確実にインストールさせるための設定手順と確認ポイントをまとめます。
「ダウンロードはするのにインストールしない」現象が起きる理由
WSUSは、更新プログラムの配布元（取得先）と承認（配る/配らない）を管理する仕組みです。一方で、更新プログラムをいつインストールするか（自動か、スケジュールか、ユーザー操作待ちか）は、基本的にクライアント側のWindows Update（自動更新）の設定で決まります。
そのため、WSUSで承認が正しく、クライアントが更新ファイルをダウンロードできていても、クライアント側のポリシーが「決まった時刻に入れる」モードになっていなかったり、別の仕組み（自動メンテナンス）に委ねる設定になっていると、管理者の想定どおりに自動インストールが進みません。
原因として多い「自動メンテナンス中にインストール」の落とし穴
グループポリシー（またはローカルポリシー）の「自動更新を構成する（Configure Automatic Updates）」で、一般的に選ばれるのが「自動ダウンロードしてインストールをスケジュール（オプション #4）」です。
ここで「自動メンテナンス中にインストール（Install during automatic maintenance）」が有効になっていると、挙動が「指定した曜日/時刻に必ずインストール」から外れやすくなります。
なぜ“指定時刻に必ず入る”になりにくいのか
- 自動メンテナンスは「PCが未使用」「一定時間アイドル」などの条件を優先します。業務PCが日中ずっと使われる環境、夜はスリープに入る環境だと、条件が揃わずインストールが先延ばしになりがちです。
- ノートPCの場合、バッテリー駆動を避けるなどの条件でさらに実行されにくくなります（ダウンロードはできても、インストールは実行条件待ちになるケースが出ます）。
- 数日インストールできないと、最終的にWindows Updateが前倒し適用へ動くこともありますが、“パッチはこの時間に必ず入る”という運用には寄せにくいのが実情です。
結論：スケジュール運用したいなら「自動メンテナンス中にインストール」を外す
「オプション #4（自動ダウンロードしてインストールをスケジュール）」で、曜日/時刻どおりに自動インストールさせたい場合は、「自動メンテナンス中にインストール」のチェックを外すのが定石です。
| 目的 | 推奨設定 | 狙い |
|---|---|---|
| 「決まった曜日/時刻」に自動インストールしたい | 「自動更新を構成する」＝有効／オプション #4 「自動メンテナンス中にインストール」＝無効（チェックなし） | 自動メンテナンスの条件に左右されず、スケジュール基準で動かす |
| ユーザー操作をなるべく避けて、空き時間に勝手に更新したい | 自動メンテナンスを活用（チェックあり） | 体感の邪魔を減らせるが、運用上の「時刻保証」は弱い |
設定手順（グループポリシーでの具体例）
以下は、ドメイン環境でGPOを使って設定する流れです。ローカルポリシーでも画面構成は概ね同じです。
手順の全体像
- WSUSの配布先を指定（WSUSサーバーURL）
- 「自動更新を構成する」をオプション #4（自動ダウンロード＋スケジュールインストール）にする
- 「自動メンテナンス中にインストール」をオフにする
- クライアントでポリシー反映と動作確認をする
GPOの設定箇所（代表例）
グループポリシー管理エディターで次のように辿ります（表示名はOS/ADMXの世代で多少前後します）。
コンピューターの構成
→ 管理用テンプレート
→ Windows コンポーネント
→ Windows Update最低限、次の2点をセットで見直すと切り分けが早くなります。
| ポリシー | 推奨値（例） | ポイント |
|---|---|---|
| イントラネットの Microsoft 更新サービスの場所を指定する （Specify intranet Microsoft update service location） | 有効 例）http://WSUSサーバー名:8530 | ここが未設定/誤設定だと、WSUS運用自体が崩れます（まず土台） |
| 自動更新を構成する （Configure Automatic Updates） | 有効 オプション #4：自動ダウンロードしてインストールをスケジュール 曜日/時刻：運用に合わせて設定 自動メンテナンス中にインストール：チェックを外す | 今回の主題。チェックが入っていると「時刻保証」が弱くなり、未使用条件で先延ばしになりやすい |
「オプション #4」のおすすめ設計（現場でハマりにくい考え方）
- インストール時刻は“業務時間外”に寄せる：例）毎日 03:00 など
- 曜日は「毎日」を基本：週1回に固定すると、当日PCが電源OFFやスリープだっただけで、次のチャンスが1週間後になりがちです
- 再起動が必要な更新を見越して設計：インストールできても再起動が抑止されると「適用されたように見えない」ことがあります
クライアント側での確認方法（設定できているのに動かないを潰す）
「GPOを変えたのに状況が変わらない」場合、まずはそのPCにポリシーが本当に当たっているかを確認します。WSUS運用のトラブルは、WSUS側の問題よりもGPO未適用/競合/例外OUが原因のことが珍しくありません。
適用状況の確認
- gpresultでポリシー適用を確認（管理者権限のコマンドプロンプト）
gpresult /h C:\Temp\gpresult.html出力されたHTMLで、Windows Update関連の設定が期待どおりか確認します。
- rsop.msc（結果セット）で、どのGPOが勝っているかを見る
ポリシー反映の即時実行
gpupdate /forceWindows Updateの検出・処理を促す（補助）
環境によっては検出/ダウンロード/インストールのタイミングが分散するため、切り分け目的で「動作を促す」ことがあります。代表的には次のような操作が使われます（OS世代でコマンドが変わる点に注意してください）。
- 設定画面（Windows Update）から「更新プログラムのチェック」を実行
- 再起動を挟んで、保留中の処理を進める（特にServicing Stack系や累積更新）
挙動のイメージ：チェック有り/無しで何が変わるか
同じ「オプション #4」でも、運用の読みやすさが変わります。
| 設定 | インストールの基準 | 現場で起こりやすいこと | 向いているケース |
|---|---|---|---|
| 自動メンテナンス中にインストール：チェックあり | PCのアイドル/未使用/条件成立 | 「夜間に必ず入る」になりにくい 常時稼働・常時利用・スリープ多用だと先延ばし | ユーザー体験優先、厳密な時刻拘束が不要 |
| 自動メンテナンス中にインストール：チェックなし | 指定スケジュール（曜日/時刻） | 運用設計がしやすい ただし、PCがオフ/スリープなら当然失敗しうるため、稼働設計も必要 | パッチ適用の時間を管理したい（社内標準のメンテ枠がある等） |
それでも自動インストールされない場合のチェックリスト
今回の原因が「自動メンテナンス」ではないケースもあります。次のチェックで、どこで止まっているか（承認→検出→ダウンロード→インストール→再起動）を分解して確認すると、復旧が早くなります。
| チェックポイント | よくある症状 | 確認のコツ | 対処の方向性 |
|---|---|---|---|
| WSUS承認と対象グループ | あるPCだけ入らない | WSUS側でその端末が想定グループに入っているか、承認がそのグループ向けか | グループ割当・自動承認ルール・手動承認の見直し |
| 「イントラネットの更新サービス場所」設定 | ダウンロード元がWSUSになっていない | WSUS URL（8530/8531）とHTTPS/HTTPが合っているか | GPO修正、証明書/プロキシ/名前解決の整備 |
| 「自動更新を構成する」のオプション | ダウンロードはするが、インストールが動かない | オプション #4になっているか、スケジュール時刻が現実的か | オプション・時刻・曜日の見直し |
| 自動メンテナンス中にインストール | 数日放置しても入らない | チェックが入っていないか、端末が夜間にアイドルになっているか | チェックを外してスケジュール運用へ |
| 端末の稼働（電源OFF/スリープ） | 夜間に入らない | 指定時刻に端末がスリープしていないか、電源管理でWakeが無効になっていないか | 運用ルール（電源ON維持）・Wake設定の検討 |
| 再起動が抑止されている | インストール済みにならず保留が続く | ログオンユーザーがいると再起動しない設定、アクティブ時間の影響 | 再起動ポリシーの設計、告知・再起動ルール |
| ディスク容量不足/一時ファイル詰まり | ダウンロードはするが適用に失敗する | 空き容量、SoftwareDistributionの肥大化 | クリーンアップ、原因更新の特定 |
「自動インストールしたい」運用で失敗しないための実務ポイント
端末が“インストールできる状態”にあることを前提にする
スケジュールを寄せても、端末が指定時刻に電源OFFやスリープならインストールは動きません。WSUS運用は「承認したら勝手に全台入る」ではなく、端末稼働・電源管理・再起動運用まで含めて設計すると成功率が上がります。
- 夜間パッチを狙うなら、端末を電源ONのままにする運用を作る
- スリープ前提なら、Wake（起動）を許可する設計を検討する
- ノートPCは「AC接続時のみ」など現実的なルールを定義する
「インストール」と「再起動」を分けて考える
「ダウンロードはしたのに入らない」と見えているものが、実はインストール自体は進んでいて、再起動待ちで止まっていることがあります。特に累積更新やコンポーネント更新では、最後に再起動が必要になることが多く、ここを抑止すると“未適用のまま”に見えます。
PCごとの使われ方でポリシーを分ける（同じGPO一発でやらない）
「オフィス常設デスクトップ」「営業ノート」「会議室PC」「検証用PC」など、同じWindowsでも稼働条件が違うと、同じスケジュールが最適になりません。OUを分けて、最低でも次のように設計すると事故が減ります。
| 端末タイプ | おすすめ方針 | 具体例 |
|---|---|---|
| 常設デスクトップ（夜間も電源ON） | スケジュール運用を強める | オプション #4、毎日03:00、自動メンテナンスのチェックなし |
| ノートPC（持ち歩き・バッテリー多用） | “確実性”より“現実性”を優先 | スケジュールは設定しつつ、AC接続時に適用されやすい時間帯に寄せる 必要ならユーザー告知・再起動ルールを明確化 |
| 会議室PC・共有PC（利用時間が偏る） | 未使用時間を狙う | 夜間に電源ON維持が難しいなら、起動後の猶予や再起動通知設計を重視 |
よくある質問
「自動メンテナンス中にインストール」を有効にしても、いつかは入りますか？
条件が揃えば入りますが、運用上は「いつ入ったか」「いつ入る予定か」が読みづらくなりやすいです。端末が数日連続で忙しかったり、夜はスリープ・電源OFFになりやすい環境だと、ダウンロード済みでもインストールが先延ばしになることがあります。スケジュール運用を重視するなら、チェックを外して挙動を固定化する方が管理しやすいです。
スケジュール運用にしたのに、指定時刻に入らないことがあります
指定時刻に端末が起動していない、スリープしている、あるいは再起動が抑止されているなど、OS設定以外の要因が絡むことがあります。まずは「指定時刻に端末がインストール可能な状態だったか」を切り分け、必要に応じて電源管理や再起動運用を整えるのが近道です。
WSUS側で「承認したのに入らない」時は、どこから見るのが効率的ですか？
承認・検出・ダウンロード・インストール・再起動のどこで止まっているかを分解すると速いです。今回のように「ダウンロードは進む」なら、承認・検出・配布経路は概ねOKの可能性が高く、クライアントの自動更新ポリシー（特に自動メンテナンス）や再起動条件、電源管理の影響が疑わしいポイントになります。
まとめ：WSUSの“承認”と、クライアントの“インストール運用”は別物
WSUSで更新プログラムを承認しても、クライアントがいつ自動インストールするかはWindows Updateポリシーに強く依存します。特に「オプション #4」でスケジュール適用を狙っているのに「自動メンテナンス中にインストール」が有効だと、未使用条件に左右されて想定どおりに進まないケースが出ます。
確実なスケジュール運用をしたい場合は、「自動更新を構成する」＝オプション #4にしたうえで、「自動メンテナンス中にインストール」のチェックを外す。この基本を押さえた上で、端末の稼働条件（電源ON/スリープ）と再起動運用まで含めて設計すると、「ダウンロードだけして放置される」状態を大幅に減らせます。
コメント