WSUS（Windows Server 2019）で更新プログラムを配信しつつ、更新後の自動再起動を止めて「指定日時にインストール」「再起動はエンジニアが手動」を実現したい――現場でよくぶつかる課題です。GPO設計の考え方と、再起動待ちを定期通知する実装例まで整理します。
結論：WSUS＋Windows Update標準だけで「再起動を完全に手動管理」「再起動時刻を厳密に固定」は難しい
最初に期待値を揃えると、WSUSでできるのは基本的に「更新の配信・承認・対象グループ制御」です。実際にいつインストールされ、いつ再起動されるかは、クライアントOS側のWindows Update動作（GPO/レジストリ/更新スタックの仕様）に強く依存します。特にWindows 10/11は、古いWSUS向けポリシーの一部が期待通りに効かない・または“レガシー扱い”で将来的に変わり得るため、完全な時刻固定を前提に設計すると事故ります。
そのため現実解としては、次の役割分担が「勝手に再起動した／しない」を減らしやすいです。
| 要件 | 標準機能だけでの実現度 | 現実的な落とし所 |
|---|---|---|
| 特定の曜日・時刻にインストール | 高（GPOでスケジュール可能） | 「インストール時刻」はGPOで固定し、リング（検証→本番）で段階展開 |
| インストール後の自動再起動を抑止 | 中〜低（端末状態に左右される） | WSUS承認でdeadlineを付けない＋GPOで“自動再起動しにくい状態”に寄せる |
| 再起動待ち（Pending reboot）の定期ポップアップ通知 | 低（WSUS単体では不可） | GPOの通知設定＋スクリプト/タスクで補完（運用とセット） |
まず押さえる：「インストール」と「再起動」は別管理
更新運用がこじれやすい理由は、更新の“適用完了”に再起動が必要なケースが多いのに、「インストールが終わった＝安全」ではない点です。再起動が保留（Pending reboot）の間は、パッチが完全には反映されず、脆弱性対策としても中途半端になりがちです。
| 状態 | 端末側で起きていること | 運用上の注意 |
|---|---|---|
| ダウンロード済み | 更新ファイルは取得済みだが未インストール | インストール時刻を固定したいなら、検出頻度・メンテ時間帯も意識 |
| インストール中 | コンポーネント置換・サービス更新などが進行 | 強制シャットダウンは避ける（失敗・ロールバック・整合性崩れの元） |
| 再起動待ち（Pending reboot） | 再起動で初めて更新が有効化される状態 | 「次のメンテ窓で再起動」を確実に（通知・監視が効く） |
WSUSが“勝手な再起動”の元凶に見える理由：実際は「期限（deadline）」がトリガーになりやすい
WSUSコンソールで更新を承認する際、「期限（deadline）」を設定できます。このdeadlineは便利な反面、“手動再起動にしたい”運用と相性が悪いことが多いです。
Microsoftのドキュメントでも、deadline付き更新で再起動が必要な場合は、更新がいつインストールされたかに関係なくdeadline時刻に強制再起動が発生し得ること、さらに既に再起動保留の状態でdeadline付き更新が入ると再起動が発生し得ることが説明されています。つまり「自動再起動を抑止したつもりでも、deadlineがあると再起動が前面に出てくる」挙動になりがちです。
| WSUSの承認設定 | クライアント動作のイメージ | “手動再起動運用”への影響 |
|---|---|---|
| deadlineなし | 次の検出・インストールサイクルで順次適用 | GPO側の再起動抑止・通知設計が効きやすい |
| deadlineあり（未来） | スケジュールインストール時刻にインストールされても、再起動が未実施ならdeadline時刻に再起動し得る | 狙いと違うタイミングの自動再起動リスクが上がる |
| deadlineあり（過去日付） | “期限切れ”扱いで可能な限り早くインストールが走る | 急な適用・再起動の引き金になりやすい |
さらにベンダー資料でも、WSUSの自動承認で期限を設定していると、Windows Update側の自動再起動無効化をしていても再起動が起きる可能性がある旨が注意されています。「再起動は人が握る」方針なら、WSUS側の期限は付けないを基本ルールにしておくのが安全寄りです。
前提として知っておきたい：WSUSは「非推奨（Deprecated）」だが運用は継続可能
いまWSUSを使うこと自体は可能ですが、MicrosoftはWSUSを“非推奨”とし、新機能追加は行われないと明記しています。一方で、製品ライフサイクルに沿ったセキュリティ/品質更新は引き続き提供されます。つまり「今あるWSUSで回し続ける」はできるが、「将来はより柔軟な仕組み（例：Configuration Manager/Intune等）に寄せる」視点も持っておくと、再起動制御の不満が爆発しにくいです。
設計の骨子：WSUS・GPO・運用で“握るもの”を分ける
「指定日時インストール＋手動再起動」を狙うなら、次の3レイヤで設計するとブレが減ります。
| レイヤ | 担当 | ここで握ること | 握らないこと |
|---|---|---|---|
| WSUS | 更新配信基盤 | 承認/拒否、対象グループ、段階展開（リング） | 再起動時刻の厳密固定（deadlineは原則使わない） |
| GPO（Windows Update） | 端末制御 | インストール曜日/時刻、通知、再起動抑止（できる範囲） | 「必ずこの時刻にだけ再起動」 |
| 運用手順 | エンジニア | メンテ窓での計画再起動、未再起動端末の追跡、例外管理 | “放置してもいつか勝手に整う”前提 |
GPO設計：まずはWSUSクライアントの基本セットを固める
GPOは「1本で全部」を狙うと競合や例外が増えます。おすすめは、共通ベースGPO＋端末種別（サーバー/クライアント）やリング別GPOの分割です。
共通ベースでまず入れたい代表例をまとめます（環境差があるため、必ず検証OUでテストしてください）。
| ポリシー（日本語/英語） | 推奨値 | 狙い |
|---|---|---|
| イントラネットの Microsoft 更新サービスの場所を指定する Specify intranet Microsoft update service location | 有効： 検出サーバー/統計サーバーにWSUS URL（例：http://wsus.example.local:8530） | 端末をWSUSへ向ける（最重要） |
| 自動更新を構成する Configure Automatic Updates | リング/端末種別で後述の値に分ける | 自動更新の基本動作を決める |
| クライアント側のターゲットを有効にする Enable client-side targeting | （運用方針による）有効＋グループ名指定 | OU/セキュリティグループでリング分けしやすくする |
| Windows Update のインターネットの場所に接続しない Do not connect to any Windows Update Internet locations | （要件次第）有効 | “勝手にMicrosoftへ取りに行く”経路を減らす |
| 自動更新の検出頻度 Automatic Updates detection frequency | （要件次第）有効：例 6〜12時間 | WSUSへの問い合わせタイミングを調整 |
なお、WSUSの既定ポート（HTTP: 8530 / HTTPS: 8531）はMicrosoftの手順でも触れられています。URLのポート違いは意外と初歩ミスとして多いので、ここも先に固定しておくと運用が楽です。
指定曜日・時刻にインストールさせる：基本は「自動更新を構成する」のスケジュール
“指定日時インストール”は、GPOの「自動更新を構成する（Configure Automatic Updates）」で、「4 – 自動ダウンロードしてスケジュールに従ってインストール」を選び、曜日と時刻を設定するのが王道です。Windows Updateの再起動制御も、この「オプション4」を前提条件にしている設定が多いです。
よくある設計例です。
| 対象 | インストール曜日 | インストール時刻 | 意図 |
|---|---|---|---|
| 検証リング（IT/パイロット） | 平日深夜 | 02:00〜04:00 | 翌営業日に影響確認できる |
| 本番リング（一般端末） | 週末 | 02:00〜04:00 | 利用者影響を減らす |
| サーバー（業務影響が大きい） | メンテ窓に合わせる | メンテ窓開始直後 | インストール→手動再起動まで同一窓で完結 |
自動再起動を抑止／遅延するGPO：できる範囲と限界を知る
ここが一番つまずきます。再起動を抑止する代表的なポリシーは複数ありますが、同時に有効化すると片方が効かない、あるいはWindows 10/11では“効かない設定”も混ざるため、設計前に整理が必須です。
まず押さえるべき注意点
- 再起動制御には「どれか1つの経路を選ぶ」前提があり、競合させると想定外の挙動になり得ます。
- RDPの場合、“サインイン中ユーザー”として扱われるのはアクティブなRDPセッションのみです（切断状態だと再起動される余地が出ます）。
- Windows 10/11では、昔からWSUS資料で紹介される一部ポリシーが未実装（効果なし）です。
再起動抑止の中心になるポリシー
| ポリシー | 効く条件 | 強み | 弱み（落とし穴） |
|---|---|---|---|
| ログオン中のユーザーがいる場合、スケジュールされた自動更新のインストール後に自動的に再起動しない No auto-restart with logged on users for scheduled automatic updates installations | 「自動更新を構成する」がオプション4（スケジュールインストール）のとき | “ログオン中に勝手に再起動”を抑えられる | 誰もログオンしていない端末/サーバーは再起動され得る。RDPはアクティブのみ。さらに「説明通りに動かない場合がある」旨が注意されている |
| アクティブ時間中の更新後自動再起動をオフにする Turn off auto-restart for updates during active hours | アクティブ時間を設定している場合 | 業務時間帯の再起動を避けやすい | “狙った時刻に再起動”はできない。別ポリシー（No auto-restart等）と競合し得る |
| 更新プログラムのインストール後に自動再起動するまでの期限を指定する Specify deadline before auto-restart for update installation | Windows 10向け（レガシー） | 「放置され続ける再起動」を期限で抑える | “期限ぴったりに再起動”を保証するものではなく、期限前に再起動される可能性は残る。さらに他ポリシーが有効だと無効化されることがある |
Active hoursの上限（最大18時間）と「時刻固定できない」ポイント
Active hours（アクティブ時間）は、更新後の自動再起動を“この時間帯は避ける”ための仕組みです。ただし上限があり、Windows 10の後期バージョンやWindows Server 2016以降では最大18時間が上限、とされています。つまり「夜間だけ再起動させる」方向には寄せられても、「この時刻に再起動させる」まで厳密に追い込む用途ではありません。
ポリシー競合を先に潰す：再起動制御は“足し算”ではない
再起動制御は設定を盛るほど安全…ではなく、競合で無効化されて思った通りに動かないことが多いです。最低限、次の関係は把握してから設計してください。
| 設定A | 設定B | 起きがちなこと |
|---|---|---|
| No auto-restart with logged on users | Always automatically restart at the scheduled time | 後者が効かない（ログオン抑止が優先される） |
| No auto-restart with logged on users | Turn off auto-restart during active hours | 想定した通りに効かない場合がある（経路が競合） |
| Always automatically restart at the scheduled time | Specify deadline before auto-restart | 後者が効かないことがある |
サーバーは別設計が現実的：Option 7（インストール/再起動を通知）という手もある
サーバーで「絶対に勝手に再起動させない」を最優先するなら、クライアントと同じ“オプション4（自動インストール）”に寄せるより、サーバー専用の「7 – インストールと再起動を通知（Notify for install and notify for restart）」を検討する価値があります。Microsoftの説明では、このオプションは更新をダウンロードし、インストール準備ができたら通知、インストール後は再起動を通知するという動きです。自動化の度合いは下がりますが、再起動の主導権は握りやすくなります。
また「ポリシー一覧にオプション7が出てこない」場合、ADMXテンプレートが古い可能性があります。管理用テンプレート（ADMX/ADML）を更新し、GPOエディタ側に新しい選択肢が出るか確認してください（AD中央ストア運用だと特に重要です）。
標準機能の“通知”でできること：Windows Update通知を設計する
「定期ポップアップ」をWSUS単体で作る機能はありませんが、Windows Updateの通知自体はGPOである程度コントロールできます。まずは標準通知を整えて、足りない分をスクリプトで補う流れが現実的です。
| ポリシー | 設定の例 | 効果 | 注意 |
|---|---|---|---|
| 更新通知の表示オプション Display options for update notifications | 既定（0）を基本 | 通知を消しすぎない（再起動が必要な事実をユーザーに伝える） | 通知を抑えすぎると“気付かないまま期限超過”が増える |
| 自動再起動が必要な通知 Configure auto-restart required notification for updates | （例）ユーザー操作で消える設定 | 勝手に消える通知を減らせる | レガシー扱いでWindows 11では非該当のものがある |
| 自動再起動のリマインダー通知 Configure auto-restart-reminder notifications for updates | （例）15分→30分/60分など調整 | リマインド間隔を調整 | レガシー扱い |
| 警告通知スケジュール（リマインド/直前） Configure auto-restart warning notifications schedule for updates | Reminder(hrs)/Warning(mins)を設定 | “直前に知らせて保存させる”ができる | レガシー扱い |
| Engaged restart（ユーザーに再起動計画を促す） Specify engaged restart transition and notification schedule for updates | 移行/スヌーズ/期限を調整 | 再起動を放置させにくくする | レガシー扱い。端末の更新ポリシー全体と合わせて検証が必要 |
“定期ポップアップ通知”を実現する：スクリプト＋タスクスケジューラで補完する
再起動待ち（Pending reboot）や、更新インストール中の注意喚起を「定期的に出したい」場合は、GPO標準だけでは不足しやすいです。ここは割り切って、端末側でスクリプトを定期実行するのが再現性の高い方法です。
実装方針
- 再起動待ち判定：代表的なレジストリキーを見てPending rebootを判断
- 通知方法：サーバー/RDP中心なら msg.exe が手堅い（セッションに直接表示）
- 周期実行：タスクスケジューラで「ログオン時＋30分ごと」など
PowerShell例：Pending rebootならメッセージを出す
$ErrorActionPreference = "SilentlyContinue"
function Test-PendingReboot {
$rebootKeys = @(
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending",
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"
)
foreach ($k in $rebootKeys) {
if (Test-Path $k) { return $true }
}
$pfro = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name "PendingFileRenameOperations").PendingFileRenameOperations
if ($pfro) { return $true }
return $false
}
function Get-ActiveSessions {
# quserの出力をざっくり解析（環境により整形が異なるため、必要に応じて調整）
$lines = (quser) 2>$null
if (-not $lines) { return @() }
$sessions = @()
foreach ($line in $lines | Select-Object -Skip 1) {
$trim = $line.Trim()
if (-not $trim) { continue }
# 連続スペースで分割
$parts = $trim -split "\s+"
if ($parts.Length -ge 3) {
$user = $parts[0]
$state = $parts[3]
if ($state -match "Active") {
$sessions += $user
}
}
}
return ($sessions | Select-Object -Unique)
}
if (Test-PendingReboot) {
$message = "Windows Updateの適用は完了していますが、再起動が必要です（Pending reboot）。運用手順に従って手動で再起動してください。"
$users = Get-ActiveSessions
if ($users.Count -gt 0) {
foreach ($u in $users) {
msg $u /time:60 $message
}
} else {
# ログオンユーザーがいない場合はイベントログに残すなど、運用に合わせて拡張
Write-EventLog -LogName Application -Source "WSUS-RebootNotify" -EventId 1001 -EntryType Warning -Message $message
}
}ポイントは、タスクを「SYSTEM」で動かしてもGUIポップアップが出ないことがある点です（セッション0分離）。サーバー/RDPならmsg.exeが比較的確実ですが、クライアントPCで“確実に画面に出す”なら「ユーザーコンテキストで実行（ユーザーがログオンしている時のみ）」のタスク設計も検討してください。
タスクスケジューラ登録例（schtasks）
例として「毎日、30分ごとに繰り返し」「ユーザーがログオンしている時だけ動かす」寄せのコマンド例です（運用に合わせて要調整）。
schtasks /Create /TN "WSUS-PendingReboot-Notify" ^
/TR "powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\Notify-PendingReboot.ps1" ^
/SC MINUTE /MO 30 /RU "%USERNAME%"より確実にするなら、GPOの「スケジュールされたタスク（GPP）」で配布し、ログオン時トリガー＋繰り返しトリガーをGUIで組むのが安全です。
運用の落とし所：自動再起動を“ゼロ”にするより、事故を減らす
完全に再起動を手動化しようとすると、「再起動されない端末が永遠に残る」問題が必ず出ます。そこでおすすめは、次の三段ロケットです。
- WSUS：承認にdeadlineを付けない。リングで段階展開し、検証で問題を潰してから本番へ流す。
- GPO：インストール時刻は固定。再起動は抑止（できる範囲）＋通知は厚めに。競合する設定は入れない。
- 運用：メンテ窓で計画再起動。再起動待ち端末は“見える化”して残件を潰す。
WSUSの計画ドキュメントにも、スケジュールインストール時は必要に応じて再起動が行われ、ログオン中には警告やカウントダウンが表示される旨が書かれています。ここをGPOと運用でコントロールしていく、という発想がブレにくいです。
トラブルシュート：思った通りに動かない時のチェックリスト
| 症状 | 疑うポイント | 確認手順 |
|---|---|---|
| 勝手に再起動した | WSUS承認にdeadlineが付いている／自動承認ルールで期限付き | WSUSで当該更新の承認プロパティ確認（期限設定の有無） |
| GPOで再起動抑止したはずなのに再起動する | ログオンユーザー扱いになっていない（RDP切断、誰もログオンしていない等） | 再起動発生時刻のログイン状態、RDPセッション状態を確認 |
| 古いWSUS向けポリシーを入れても効かない | Windows 10/11で未実装のポリシーを使っている | 対象OSで“適用可否”を再確認し、効果のある設定に絞る |
| オプション7がGPOに出てこない | ADMXが古い／中央ストアが更新されていない | ADMX/ADMLを更新し、GPOエディタ側に新しい選択肢が出るか確認 |
最後に重要な補足です。WSUSは「配信のハブ」としては今でも使えますが、再起動やユーザー通知を“厳密に”やりたい場合、Configuration Managerなどのより柔軟な仕組みのほうが設計自由度が高い点は押さえておくと、将来の運用改善につながります。
コメント