Windows Server 2025：長期間更新未適用に見える状態の切り分けと、再起動時プレシャットダウン失敗について

Question

Windows Server 2025：長期間更新未適用に見える状態の切り分けと、再起動時プレシャットダウン失敗について

yi 0

※本サーバは Azure VM ではなく、オンプレミスの Windows Server 2025 です。　Windows Update の適用挙動・再起動遅延についての技術確認依頼です。 ■ 環境・OS: Windows Server 2025 ・運用: 毎日 00:15 に定例サーバ再起動・同サーバ上で、毎日 01:00〜03:25 頃に定時処理を実行（01:15 にタスクスケジューラ起動の処理あり） ■ 発生事象（2026/08/13）・00:15 定例再起動開始直後、Windows Update（wuauserv）がプレシャットダウンに失敗・その後も wuauserv 停止待ち／関連タイムアウトが継続し、再起動処理が遅延・01:20 Windows Modules Installer のプレシャットダウン失敗・01:21 User Access Logging Service のプレシャットダウン失敗・結果として、01:15 起動予定のタスクが実行できず、定時処理に影響・なお、同サーバではこれまで同時間帯の定例再起動運用で同様の事象は発生しておらず、今回が初めてです。(1年ほど運用) ■ 更新プログラムについて・「更新の履歴」「インストールされた更新プログラム」上、確認できる更新は概ね 2026/08/13〜08/14 付が中心・品質更新（セキュリティ／.NET）、Broadcom ドライバ（system / Net / SCSI）、定義更新、MSRT 等・稼働後しばらく、同種の品質更新が履歴上ほとんど見えない状態に見えたため、長期間未適用（または未検出）だった可能性を疑っています　※履歴GUIが全期間を保持しない場合がある点は認識しています ■ 確認したいこと

これまで同様の定例再起動運用で問題が無かったのに、今回このようなプレシャットダウン失敗／再起動遅延が発生した主な要因として、どのような可能性が考えられるか　（例: 当該日に適用された更新の種類・量、ドライバ更新の同時適用、保留更新の有無、サービス停止待ちの長期化等）
当該サーバで品質更新が長期間入っていない／見えない場合に確認すべき設定・ログは何か　（例: 更新の一時停止、Windows Update for Business の延期、GPO、WSUS/配信の最適化、更新確認自体の失敗等）
上記プレシャットダウン失敗イベントの意味と、ドライバ更新等と同時に定例再起動した場合の注意点・調査観点
再発防止として、次の運用は妥当か。改善点があれば指摘してほしい　・アクティブ時間: 毎日 00:00〜13:00 　・Windows Update 適用: 毎日 10:00 　・定例サーバ再起動: 毎日 13:00 ■ 補足・本件は原因の技術確認と再発防止のための問合せです。

0 件のコメント

1 件の回答

お客様の回答

Answer 1

こんにちは yi,

先日のシャットダウン前の障害は、再起動の直前に Windows Update サービスや Windows Modules Installer が更新プログラムを適用中であったことが原因である可能性が高いと考えられます。特に、品質更新プログラムやドライバー更新プログラムが同時に適用される場合、サービスの停止待ちに時間がかかり、再起動処理がタイムアウトしたり遅延したりすることがあります。通常、これらの処理は短時間で完了しますが、長期間更新が保留されていた場合や、Broadcom 製などのドライバー更新が含まれる場合は、処理負荷が集中するため、サービスの停止に遅延が生じることがあります。

品質更新プログラムが長期間適用されていないように見受けられる場合は、WindowsUpdate.log（PowerShell コマンド Get-WindowsUpdateLog で生成可能）および C:\Windows\SoftwareDistribution\ReportingEvents.log を確認し、更新が一時停止されているか、あるいは WSUS や Windows Update for Business の延期ポリシーが適用されているかどうかを調査することをお勧めします。 GUI 上の履歴にはすべてのイベントの完全な記録が残らない場合があるため、Microsoft-Windows-WindowsUpdateClient/Operational イベントログも併せて確認することをお勧めします。

プレシャットダウン失敗イベントは「サービスが停止要求に応答できず、再起動処理をブロックした」ということを意味します。むしろ更新や大量の品質更新瞬間再起動を行うと、このような問題が発生しやすいため、更新適用と決定例再起動を時間的に分離することが推奨されます。

再発防止として、提案された運用（アクティブ時間を 00:00〜13:00、更新適用を 10:00、定例再起動を 13:00）もし、更新処理と業務タスクが重ならない安全です。改善点としては、更新適用には必ず 1〜2 時間のバッファを設けてから再起動すること、また更新が含まれる場合は定例再起動とは別途計画的に適用することがございます。

私の回答が役に立った場合は、[回答を受け入れる] をクリックしてサポートしてください。

ありがとう、

ドミック。