WSUS の同期（Synchronization）を実行した瞬間に「Reset Server node」エラーが出て同期が失敗し、WSUS コンソールが落ちる／操作不能になる――この症状は、WSUS 自体の破損というよりも、同期やスキャン負荷で IIS の WsusPool がタイムアウト・リサイクルして接続が切れることで起きやすいトラブルです。再インストールで一時的に改善して見える理由と、再発を止めるための具体策をまとめます。
症状の整理：同期実行で「Reset Server node」→コンソールが落ちる
まずは状況を言語化しておくと、切り分けが一気に楽になります。今回のパターンは次の特徴に当てはまります。
| 観測できる症状 | 起きている可能性が高いこと | 典型的な“効くけど一時しのぎ” |
|---|---|---|
| 同期を実行すると「Reset Server node」エラーになり同期が失敗する | WSUS 管理 API の呼び出し中に接続が切断され、コンソール側がサーバーノードを再初期化している | IIS リセットで一時的に開ける（ただし再度同期操作で再発） |
| WSUS コンソールがクラッシュ／固まって操作不能になる | バックエンド（IIS のワーカープロセス）が落ちる・リサイクルする・応答停止する | WsusPool の再起動、IISRESET |
| アンインストール／再インストール直後は同期が通るが、手動同期は毎回失敗 | 初期状態はメタデータが少なく負荷が軽いが、運用が進むほど同期/キャッシュ構築の負荷が増える | 「セットアップ直後だけ成功する」を“直った”と誤認しやすい |
| プロキシなしで Microsoft Update 直結、Queue Length/Private Memory は調整済み | ネットワーク経路より、IIS/WsusPool のタイムアウト・監視（Ping）・定期リサイクルが焦点 | Queue Length を増やし続けて根本原因が残る |
ポイントは、「Reset Server node」が“原因そのもの”というより、コンソールがサーバーとのセッションを維持できずに切断された結果として出る表示になりやすい点です。つまり、真犯人は WSUS の同期処理そのものではなく、その処理を受ける IIS（WsusPool）が不安定化しているケースが多い、という見立てから入ります。
なぜ起きる？「Reset Server node」エラーの正体（WSUS と IIS の関係）
WSUS コンソールは、WSUS の管理 API（Web サービス）を通してサーバーとやり取りします。同期や承認、検索、更新情報の読み込みなど、見た目は GUI 操作でも、裏側では IIS 上で動く WSUS の Web サービスに対してリクエストを投げています。
ここで IIS のアプリケーションプール（WsusPool）が次のような状態になると、コンソール側は突然接続を失います。
- Idle Time-out によりワーカープロセスが停止し、次の要求で再起動が走る
- Ping（生存監視）が一時的な高負荷を“異常”と誤判定し、ワーカープロセスを落とす
- 定期リサイクル（Regular Time Interval / Specific Times）で処理の途中にプロセスが入れ替わる
- メモリ制限（Private Memory Limit）やサーバー側のメモリ逼迫でワーカープロセスが不安定になる
同期直後にコンソールが落ちる、IIS リセットで一時的に復帰する、という挙動は「同期負荷 → WsusPool が落ちる／リサイクル → コンソールが切断」の流れと整合します。Microsoft Learn の Q&A や WSUS ベストプラクティスでも、WsusPool の Idle Time-out / Ping / リサイクルを無効化する方向での案内が定番になっています。
最優先の切り分け：本当に WsusPool が落ちているか確認する
対策を入れる前に、「同期操作のタイミングで WsusPool がリサイクル／停止しているか」を確認すると、遠回りが減ります。確認先は大きく 3 つです。
| 確認するもの | 場所 | 見るべきサイン | 判断 |
|---|---|---|---|
| アプリケーションプールのイベント | イベント ビューアー（Windows ログ / システム、アプリケーション） | WsusPool の停止/開始、WAS/IIS-W3SVC-WP などの警告/エラー、ワーカープロセスのクラッシュ | 同期の実行時刻と一致していれば、IIS 側が原因の可能性が高い |
| WSUS 関連のサービス/応答 | IIS マネージャー（Application Pools / WsusPool の状態） | Stopped になっていないか、起動直後にすぐ落ちていないか | Stopped ならコンソールは当然不安定になる |
| 負荷状況 | タスク マネージャー / リソース モニター / パフォーマンス モニター | w3wp.exe のメモリ増大、CPU 張り付き、ディスク待ち（特に WSUSContent や DB） | 同期・スキャン負荷でリサイクル条件を踏みやすい |
確認は「1 回だけ」ではなく、手動同期を実行して落ちた直後にログの時刻を突き合わせるのがコツです。同期が始まる前後数分に、アプリケーションプール関連のログが出ていないかを見てください。
解決の中心：WsusPool の Idle Time-out / Ping / 定期リサイクルを無効化する
今回の条件（再インストール直後は通るが、運用が進むと手動同期が毎回落ちる／IIS リセットで復帰）に最も効きやすいのが、WsusPool の “落ちる条件” を消すことです。WSUS はキャッシュ構築やメタデータ処理が重く、途中でワーカープロセスが切り替わると管理操作が不安定になりやすいため、Microsoft のベストプラクティスでも WsusPool の監視やリサイクル無効化が推奨されています。
推奨設定（WsusPool > Advanced Settings）
| 項目 | 推奨値（例） | なぜ効くのか | 注意点 |
|---|---|---|---|
| Idle Time-out (minutes) | 0（無効） | “しばらく操作がない”だけでプロセスが止まり、次の同期操作で再起動が走る状態を防ぐ | 常時メモリを保持するため、サーバーの RAM には余裕が必要 |
| Ping Enabled | False | 高負荷で応答が遅い瞬間を“異常”と誤判定してワーカープロセスを落とすのを防ぐ | 真のハング検知は弱くなるため、別途監視（リソース/イベントログ）を推奨 |
| Private Memory Limit (KB) | 0（無制限） | 同期やキャッシュ構築でメモリ使用量が増えても、上限で強制リサイクルされないようにする | メモリ不足のサーバーでは OS 全体が不安定になる可能性があるので監視必須 |
| Regular Time Interval (minutes) | 0（定期リサイクル無効） | 処理の途中でワーカープロセスが入れ替わり、同期やコンソールが切断される事故を防ぐ | 長期稼働での断片化が気になる場合は、計画メンテ（停止時間）で再起動する |
| Queue Length | 環境に合わせて増やす（例：2000） | 瞬間的な要求増加で 503 になりやすい状況を緩和する | 増やしすぎても根本解決にはならない。まずはタイムアウト/リサイクル対策が優先 |
質問の条件では「Queue Length は 25000、Private Memory は 0」をすでに設定済みとのことなので、次の 2 点が未対応ならそこが最短の当たりになりやすいです。
- Idle Time-out (minutes) が 0 になっていない
- Regular Time Interval (minutes)（定期リサイクル）が 0 になっていない、または Specific Times（特定時刻リサイクル）が残っている
IIS マネージャーでの設定手順（手順を間違えにくい順）
- IIS マネージャーを開く
- 左ツリーでサーバー名を選択 → 「Application Pools」
- 一覧から WsusPool を選択
- 右側の「Advanced Settings…」を開く
- 以下を設定
- Idle Time-out (minutes) = 0
- Ping Enabled = False
- Private Memory Limit (KB) = 0
- Regular Time Interval (minutes) = 0
- （必要に応じて）Queue Length を調整
- WsusPool を右クリック → 「Recycle」または「Stop/Start」（環境の影響が少ない方で）
- WSUS コンソールを開き直して、手動同期を再試行
設定変更後に「最初の同期だけ時間がかかる」「コンソールの表示が重い」ことがあります。これはキャッシュ再構築が走るタイミングで起きやすい挙動です。落ちない状態を先に作ってから、次の負荷対策（製品・分類の絞り込み等）に進むのが安定します。
同期負荷を下げて再発を防ぐ：Products and Classifications を絞る
WsusPool を安定化しても、同期対象が過剰に広いと、メタデータの増加によって同期・検索・承認画面の表示が重くなり、別の形で不安定化することがあります。Microsoft Learn の Q&A でも「製品・分類の内容共有（＝範囲が広すぎないか確認）」が求められているのは、ここが根本要因になりやすいからです。
WSUS は「製品（Products）」と「分類（Classifications）」の掛け算で対象が決まります。つまり、選択が少し増えるだけで、同期するメタデータが一気に増える構造です。
絞り込みの考え方（“必要十分”に落とす）
| 観点 | 絞り込みの方針 | 理由 | よくある落とし穴 |
|---|---|---|---|
| 製品（OS/アプリ） | 実際に社内に存在するバージョンだけに限定 | 存在しない OS の更新メタデータは完全に無駄 | 「念のため」で旧 OS を残し続ける |
| 分類 | まずは Security Updates / Critical Updates / Updates など運用に必要なものだけ | 分類の増加はメタデータ増加に直結 | Drivers を有効にして肥大化（運用設計なしで入れると管理が破綻しやすい） |
| 言語 | 必要な言語だけ | 多言語はコンテンツ・メタデータともに増えやすい | 既定のまま全言語を保持してしまう |
| 運用上の責任範囲 | WSUS で配るもの／別経路で配るものを明確化 | 「WSUS で全部」は管理負荷が跳ね上がる | M365/Store/各種エージェント更新まで一括でやろうとして重くなる |
絞り込みの手順としては、いきなり大胆に削るのではなく、次の順序が安全です。
- 現状の Products / Classifications をエクスポート（スクリーンショットでも可）
- 明らかに使っていない OS/製品を外す（例：社内に存在しない世代）
- 運用ポリシーがない分類（特に Drivers）を一旦外す
- 同期が安定したら、必要性があるものだけ段階的に追加
「手動同期は毎回失敗」になりやすい条件と、対策の優先順位
再インストール直後の同期が成功し、しばらくしてから落ちる場合、次のような条件が重なると再発しやすくなります。
| 条件 | 何が起きるか | 優先して打つ手 |
|---|---|---|
| 製品・分類が広い | 同期メタデータが肥大化し、同期/検索/承認操作が重くなる | Products / Classifications を必要最小限に |
| WsusPool の Idle/Recycle が有効 | 重い操作の途中でワーカープロセスが切り替わり、コンソールが切断 | Idle Time-out / Ping / 定期リサイクルを無効化 |
| メモリが少ない/逼迫している | キャッシュ構築でメモリを使い、OS 全体が苦しくなる → プロセスが不安定 | RAM 余裕の確保、同居サービスの見直し、監視 |
| 同期とクライアントスキャンが同時多発 | WSUS が同時に重い処理を抱え、応答遅延やタイムアウトを誘発 | 同期スケジュールを夜間に、スキャンのピークとずらす |
今回のケースに合わせるなら、優先順位はシンプルです。
- WsusPool の Idle Time-out / Ping / 定期リサイクル無効化（コンソール落ちを止める）
- Products / Classifications の絞り込み（同期負荷の発生源を小さくする）
- サーバー資源（メモリ/ディスク/CPU）と同時負荷の見直し（“落ちにくい土台”を作る）
補足：メモリ不足・ディスク不足が疑わしいときの現実的チェック
ベストプラクティスでも触れられる通り、WSUS はキャッシュ構築やメタデータ処理でメモリを大きく使うことがあります。IIS 側の Private Memory Limit を 0 にしても、サーバー全体のメモリが足りなければ別の形で不安定になります。
最低限の監視ポイント
- 同期実行中に、w3wp.exe（WsusPool） のメモリが右肩上がりになっていないか
- ディスクが逼迫していないか（WSUSContent、DB、ログ）
- ディスクの待ち時間が長くないか（更新ファイルの保存先が遅いストレージだと影響が出やすい）
ここで重要なのは、単純に「メモリを増やす」よりも、まずWsusPool をリサイクルさせない設定と、同期対象を絞ってメタデータの増加速度を落とすことです。これで“必要なメモリ量そのもの”が減り、結果的に安定するケースが多いです。
再発防止の運用：同期とメンテナンスの“やり方”を整える
設定で落ちなくした後、運用面でさらに安定させるためのコツをまとめます。どれも派手ではありませんが、長期安定に効きます。
手動同期を多用しない（スケジュール同期を基本にする）
手動同期は「今すぐ結果を出したい」場面で便利ですが、管理者が作業時間帯に同期を叩くと、クライアントスキャンや承認作業と負荷が重なりやすくなります。可能なら同期は夜間・早朝に固定し、日中は承認や状況確認に集中するのが安定しやすいです。
不要な対象を増やさない（“後で使うかも”を残さない）
Products / Classifications は一度広げるとメタデータの増え方が加速します。特に「古い OS を念のため」「ドライバーも念のため」は、将来のトラブルの種になりがちです。必要性が明確なものだけを対象にする運用が、結局いちばん手間が減ります。
定期メンテナンスの考え方（IIS を回すなら“計画停止”で）
WsusPool の定期リサイクルを無効にした場合、長期稼働での状態を気にする方もいます。その場合は、業務影響が少ない時間に「サーバー再起動」「WSUS/IIS の計画的な再起動」を行い、同期や承認の途中で突然切れる事故を避けるのが合理的です。
よくある質問：Queue Length を極端に上げれば解決する？
Queue Length は「要求が多いときに IIS が抱えられる待ち行列」の上限です。確かに不足すると 503 系の問題が出ることがありますが、今回のような「同期の途中でコンソールが落ちる」問題は、待ち行列よりもワーカープロセスが落ちる/切り替わることが本質になりやすいです。
そのため、Queue Length を大きくしても、タイムアウト・Ping・定期リサイクルが残っていると再発します。すでに 25000 に設定済みなら、むしろ「待たせるだけ待たせて最後に切れる」形になり、体感が悪くなることもあります。まずは Idle/Recycle を止め、次に対象範囲を絞るのが王道です。
チェックリスト：この順で見れば迷いにくい
| チェック項目 | OK の目安 | NG のときの対応 |
|---|---|---|
| WsusPool の Idle Time-out | 0（無効） | 0 に変更して適用 |
| WsusPool の Ping | False | False に変更して適用 |
| WsusPool の定期リサイクル | Regular Time Interval = 0、Specific Times なし | 両方とも無効化（残っていると途中で切れやすい） |
| Products / Classifications | 実環境に必要な範囲のみ | 不要な製品・分類（特に使っていない OS/Drivers 等）を削る |
| イベントログ | 同期時刻に WsusPool 停止/クラッシュが出ない | 出るなら IIS/資源不足の線が濃厚。設定見直しと資源確認 |
| サーバー資源 | 同期中でもメモリ・ディスクが枯渇しない | メモリ増強、同居サービス見直し、ストレージ改善、同期時間の変更 |
参考情報（公式）
- WSUS Synchronizations fail with Error ‘reset Server node’. – Microsoft Q&A
- Windows Server Update Services (WSUS) best practices – Microsoft Learn
まとめ：まずは「落ちる条件」を消し、次に「重くなる原因」を削る
WSUS の同期で「Reset Server node」エラーが出て WSUS コンソールが落ちる問題は、WSUS の再インストールでは根治しないことが多く、IIS の WsusPool がタイムアウト/リサイクルで切断される構造を理解すると最短で直せます。
最初にやるべきは、Idle Time-out（0）/ Ping（False）/ 定期リサイクル（0）で「同期中にワーカープロセスが切り替わらない状態」を作ること。その上で、Products and Classifications を必要最小限に絞ることで、同期・スキャンの負荷を根本から下げ、再発しにくい WSUS にできます。
コメント