WSUSクリーンアップが固まるときは、まず WSUS 自体の故障を疑うより、Unused updates and update revisions の初回負荷、SUSDB の肥大化、IIS の WsusPool が既定メモリ制限で停止している、の3つを疑うのが近道です。Microsoft のメンテナンスガイドでも、長期間メンテナンスしていない WSUS ではクリーンアップがタイムアウトしやすく、再インデックス後に「Unused updates and update revisions」だけを複数回実行する流れが案内されています。 (Microsoft Learn)
この記事では、WSUSクリーンアップが固まる原因、切り分け方、今すぐ試せる対処、復旧後にやるべき再発防止策まで、現場で使える順番で整理します。
WSUSクリーンアップが固まる主な原因
いちばん多いのは「Unused updates and update revisions」の初回負荷
WSUS Server Cleanup Wizard は、未使用の更新と更新リビジョン、長期間接続していないコンピューター、不要な更新ファイル、期限切れ更新、置き換え済み更新を整理できます。このうち、長年放置した環境で特に重くなりやすいのが Unused updates and update revisions です。Microsoft は、初回のクリーンアップではこの項目がタイムアウトすることがあり、複数回に分けて実行するよう案内しています。さらに、完了まで数時間から数日かかる場合もあるとしています。 (Microsoft Learn)
「本当に固まっている」のか「まだ処理中なのか」は見分けが必要です。Microsoft のガイドでは、クリーンアップ完了後は削除件数のサマリーが返るため、その情報が返らず、管理コンソール側で接続断やタイムアウトになるなら、いったんタイムアウト扱いで次の手順に進む判断が妥当です。 (Microsoft Learn)
WsusPool が既定のメモリ制限や自動リサイクルで落ちる
WSUSクリーンアップ中に管理コンソールが切れる、503 Busy が出る、The WSUS administration console was unable to connect to the WSUS Server Database のようなエラーが出る場合は、IIS の WsusPool を先に疑います。Microsoft のトラブルシュートでは、既定の Private Memory Limit が 1,843,200 KB で、これが原因で WsusPool が停止するケースが案内されています。まずは 4 GB〜8 GB に引き上げ、環境によってはさらに増やす対処が示されています。 (Microsoft Learn)
一方で、Microsoft の WSUS ベストプラクティスでは、WsusPool の Queue Length を 2000 に上げ、Idle Time-out を 0、Ping を False、Private / Virtual Memory Limit を 0、Regular Time Interval を 0 にして、不要な自動リサイクルを止める構成が推奨されています。クリーンアップがよく落ちる環境では、単に「4GBへ増やす」だけでなく、アプリプールのリサイクル条件そのものを見直した方が再発を防ぎやすいです。 (Microsoft Learn)
SUSDB が肥大化し、superseded updates が大量に残っている
Microsoft は、WSUS メンテナンスの基本手順として、SUSDB のバックアップ、必要に応じたカスタムインデックス、再インデックス、superseded updates の整理、Server Cleanup Wizard の実行を挙げています。つまり、クリーンアップだけを何度も押しても、SUSDB 側が重いままだと改善しにくい、ということです。 (Microsoft Learn)
特に superseded updates が未整理のまま大量に残っていると、サーバー側・クライアント側の双方で問題が起きやすくなります。Microsoft は、未 decline の superseded updates が 1500 を超えると各種の更新関連トラブルを起こしうると案内しています。置き換え先の更新が展開済みで、置き換えられた側が不要であることを確認したうえで整理するのが安全です。 (Microsoft Learn)
同期範囲が広すぎる設定と、見落としやすい権限不足
WSUS は、言語・製品・分類で同期範囲を絞れます。Microsoft は、使用している言語だけに絞るとディスク容量を節約できると案内しています。また、製品では親カテゴリにチェックすると、その配下の全製品と将来バージョンまで選ばれやすいため、必要以上に広い同期範囲になりがちです。これが長期運用で SUSDB とコンテンツを膨らませる原因になります。 (Microsoft Learn)
ここでよくある勘違いが、「製品と分類」のチェックを外せば既存データも減る、というものです。実際には、チェックを外しても新規同期を止めるだけで、過去に同期済みの更新は残ります。既存データを減らしたいなら、不要な更新を decline し、その後に Server Cleanup Wizard を走らせる必要があります。 (Microsoft Learn)
権限不足も見逃せません。WSUS コンソールを使うには、WSUS サーバー上でローカル Administrators または WSUS Administrators グループのメンバーである必要があります。WID へ SSMS で接続する際にエラーが出る場合も、Microsoft は「管理者として実行」を試すよう案内しています。 (Microsoft Learn)
まず5分で切り分ける
Unused updates and update revisionsを選んだ時だけ極端に長いなら、長期未メンテと SUSDB 側の負荷を優先して疑います。再インデックス後にこの項目だけ複数回回すのが基本です。 (Microsoft Learn)503 Busy、DB 接続エラー、コンソール切断が出るなら、クリーンアップそのものよりWsusPoolの停止やメモリ不足を先に直します。 (Microsoft Learn)- 製品や分類の見直し後なのに容量が減らないなら、設定変更だけで終わっている可能性が高いです。decline と cleanup が必要です。 (Microsoft Learn)
- コンテンツ移設後やストレージ障害後に挙動がおかしいなら、
wsusutil resetの対象です。ただし、これは DB 肥大の解消策ではありません。 (Microsoft Learn)
WSUSクリーンアップが固まったときの対処手順
WsusPool を先に安定させる
最初に IIS マネージャーで Application Pools を開き、WsusPool が停止していないか確認します。停止している、またはクリーンアップ時に落ちるなら、まずは Private Memory Limit を 4,000,000 KB から 8,000,000 KB の範囲で見直し、アプリプールを再起動します。これだけで管理コンソールの切断が止まるケースは少なくありません。 (Microsoft Learn)
4GB にするか、0 にするか
障害対応としての「止血」なら、4GB〜8GB へ引き上げるのが実務的です。継続的に落ちるなら、Microsoft ベストプラクティスに沿って Queue Length 2000、Idle Time-out 0、Ping Enabled False、Regular Time Interval 0、Private / Virtual Memory Limit 0 を検討してください。クリーンアップ中だけ通したいのか、今後も安定させたいのかで考え方を分けると判断しやすいです。 (Microsoft Learn)
クリーンアップは「obsolete updates だけ」から始める
長期間放置した WSUS をいきなりフルチェックで掃除しようとすると、最も重い Unused updates and update revisions がボトルネックになりやすいです。Microsoft も、初回はこの項目だけで何度か回し、完了後にほかの項目を1つずつ実行し、最後にフルパスで回す流れを勧めています。GUI が落ちるなら、PowerShell から同等処理を実行した方が切り分けしやすいです。 (Microsoft Learn)
Get-WsusServer | Invoke-WsusServerCleanup -CleanupObsoleteUpdatesこのコマンドは、WSUS コンソールの Cleanup Wizard と同等の処理を PowerShell から実行するものです。CleanupObsoleteUpdates が、GUI の Unused updates and update revisions に相当します。 (Microsoft Learn)
完了したら、次のように重い処理を分けて流します。
Get-WsusServer | Invoke-WsusServerCleanup -DeclineExpiredUpdates
Get-WsusServer | Invoke-WsusServerCleanup -DeclineSupersededUpdates
Get-WsusServer | Invoke-WsusServerCleanup -CleanupObsoleteComputers
Get-WsusServer | Invoke-WsusServerCleanup -CleanupUnneededContentFiles -CompressUpdatesMicrosoft の古い Server Cleanup Wizard ドキュメントでは、Computers not contacting the server は 30 日以上接続していないクライアントの整理、Unneeded update files は不要な更新ファイルの削除です。なお、Catalog Site から個別に取り込んだ更新ファイルを使っている環境では、Unneeded update files でそれらが消える可能性があるため、このチェックは最後に回すのが安全です。 (Microsoft Learn)
それでも終わらないなら SUSDB を再インデックスする
Microsoft は、WSUS メンテナンスの前提として SUSDB のバックアップを挙げています。再インデックスや SQL ベースの整理に進む前に、まず SUSDB のバックアップを取ってください。 (Microsoft Learn)
SUSDB が SQL Server なのか WID なのかは、HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup の SQLServerName で確認できます。##WID を含むなら WID です。WID なら、Microsoft は \\.\pipe\MICROSOFT##WID\tsql\query で接続し、接続エラー時は SSMS を管理者として実行するよう案内しています。 (Microsoft Learn)
sqlcmd -S \\.\pipe\Microsoft##WID\tsql\query -i C:\WSUS\SUSDBMaint.sql -o C:\WSUS\reindexout.txtこれは Microsoft ガイドにある WID 向けの sqlcmd 実行例です。SUSDBMaint.sql には、Microsoft の WsusDBMaintenance 再インデックス用スクリプトを保存して使います。 (Microsoft Learn)
再インデックス後は、再び CleanupObsoleteUpdates だけを実行してください。Microsoft も、初回クリーンアップが重い環境では、まず再インデックスし、その後に obsolete updates を単独で何度か回す流れを勧めています。 (Microsoft Learn)
superseded updates を整理する
superseded updates が多すぎるかを確認したいなら、Microsoft が案内している次の SQL で件数を見られます。
Select COUNT(UpdateID) from vwMinimalUpdate where IsSuperseded=1 and Declined=0この数が 1500 を超えるなら、各種の更新トラブルの原因になり得ます。置き換え先が展開済みで、置き換えられた更新が不要なことを確認したうえで、decline を進めてください。 (Microsoft Learn)
wsusutil reset は「最後の必殺技」ではなく、用途が違う
wsusutil reset は、WSUS データベース内の更新メタデータと、ローカルに保存されている更新ファイルの対応を検証し、欠損や破損があれば再ダウンロードさせるコマンドです。Microsoft は、データベース復元後や更新ファイルの整合性確認、承認トラブルの初動で有効だと説明しています。逆に言うと、SUSDB 肥大や obsolete updates 過多の解消目的で最初に打つコマンドではありません。 (Microsoft Learn)
cd "C:\Program Files\Update Services\Tools"
wsusutil reset実行すると、WSUS サーバーが最長 5 分ほど応答しなくなることがあるため、業務時間中の実行は避けた方が無難です。 (Microsoft Learn)
ここまでやっても終わらない場合の最終手段
長年未メンテナンスの WSUS でクリーンアップが毎回タイムアウトする場合、Microsoft のガイドは大きく 2 つの道を示しています。1 つは SUSDB をバックアップしたうえで再インデックスと SQL ベースの代替整理に進む方法、もう 1 つは WSUS を新しいデータベースで再構築する方法です。ここまで行く場合は、メンテナンス時間を確保し、事前バックアップを取ってから進めてください。 (Microsoft Learn)
復旧後に見直すべき設定
同期対象を「本当に必要なもの」だけに絞る
使用していない言語を外すだけでも、ディスク使用量を抑えやすくなります。製品も、親カテゴリをまとめて選ぶのではなく、必要な製品だけを選ぶ方が安全です。特に親カテゴリは配下の全製品や将来バージョンまで拾いやすいため、気づかないうちに同期対象が広がります。 (Microsoft Learn)
月次でメンテナンスする
Microsoft は WSUS メンテナンスを月次で行う前提で説明しており、メンテナンスされている WSUS は初回ほど重くなりません。逆に、何か月も放置した WSUS は、次回のクリーンアップが重くなりやすいです。 (Microsoft Learn)
自動化するなら、最初の 2 回は手動実行にして所要時間を把握してからの方が安全です。Microsoft のガイドでも、初回は通常より長く、2 回目は 30 日後に行うことで、通常時の所要時間を見積もりやすいとしています。 (Microsoft Learn)
同期と cleanup / reindex を重ねない
Microsoft は、cleanup や再インデックスの最中に同期を走らせないよう注意しています。特に下流サーバーがある環境では、せっかく消した更新が再同期される原因になります。単体 WSUS でも、業務時間外に cleanup、その後に reindex、最後に同期、という順番に分ける方が安定します。 (Microsoft Learn)
ConfigMgr / MECM 連携なら役割分担を見直す
Configuration Manager 1906 以降では、WSUS Maintenance オプションを有効にすると、同期後の cleanup の多くを自動化できます。ただし、Microsoft もバックアップと再インデックスは別途スケジュールすべきだとしています。MECM 連携環境なのに、WSUS 側で全部を手作業で抱え込んでいるなら、ここも見直しポイントです。 (Microsoft Learn)
まとめ
WSUSクリーンアップが固まるときの対処は、順番を間違えないことが重要です。まず WsusPool を安定させ、次に Unused updates and update revisions だけを単独で回し、それでも厳しければ SUSDB を再インデックスし、superseded updates と同期範囲を整理します。wsusutil reset は整合性確認用であって、SUSDB の重さを解消するコマンドではありません。ここまで整理できれば、あとは月次メンテナンスに乗せるだけです。 (Microsoft Learn)
コメント