WSUSをServer 2012 R2からServer 2016へ移行した直後、クライアントが0x80244010で更新プログラムの検索に失敗することがあります。少数では問題ないのに台数を増やすと急に詰まる…そんなケースで効く「検出頻度の調整」を中心に、原因の考え方と現場での収束手順、安定運用のポイントをまとめます。
発生する症状：新WSUSへ移行した途端に80244010で更新検索できない
壊れた旧WSUS（Windows Server 2012 R2）を捨てて、新しくWSUS（Windows Server 2016）を構築した。最初は少数クライアントで問題なく更新が降りていたのに、全台を新WSUSへ切り替えた瞬間、更新プログラムの検索（検出）で80244010（0x80244010）が出て失敗する――移行直後によくある「詰まり方」です。
特に、後から追加したクライアントや、久しぶりに電源が入った端末、初回スキャンになる端末ほどエラーが目立つのは典型的です。これはクライアント側が悪いというより、「WSUSへ問い合わせる初回スキャンが重い」＋「移行直後は同時スキャンが集中しやすい」という条件が重なり、WSUS側（IIS/DB/ネットワーク）がさばき切れずに起きやすい現象です。
結論：80244010は「WSUSとの往復回数が上限を超えた」系の失敗になりやすい
80244010は、Windows Updateエージェントが更新サーバー（この場合WSUS）とやり取りする中で、規定の“往復回数（server trips）”を超えてしまい、処理を完了できずに失敗したときに出やすいエラーです。今回の相談内容からも、WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS系の状態を疑うのが筋になります。
言い換えると、WSUSが完全に死んでいるわけではなく、問い合わせ自体は通るが、クライアントが必要な情報を取り切る前に“回数制限”で打ち切られる状況です。台数を増やした途端に目立つのは、WSUSの応答が遅くなったり、途中で接続が切れたりして、クライアント側が何度も取り直し→回数超過、という流れに入りやすいためです。
まず押さえる：移行直後に起きやすい「スキャンストーム」という現実
WSUS移行直後は、次のような要因で負荷が一気に跳ねがちです。
- 全端末がほぼ同じタイミングで「新WSUSに初回スキャン」を開始する
- 初回スキャンは、端末の状態・製品/分類・承認状況によってメタデータ問い合わせが多くなりやすい
- WSUSサーバー側のIISアプリプール（WsusPool）やSUSDBが温まっておらず、キャッシュが効かない
- 置換済み/不要更新の整理、DBインデックス、再編成など、メンテナンスが未実施だと初回の応答がさらに重い
この“スキャンストーム”が起きると、WSUS側は「受け付けるが遅い」状態になり、結果として80244010が出やすくなります。ここがポイントで、時間が経てば自然に収束するケースもあります。ただし放置すると、端末群が同じ周期で同時スキャンを繰り返し、収束までが長引くこともあります。
今回の主対処：グループポリシーで「自動更新の検出頻度」を短くして早期収束させる
本件で効果が出た対処は、クライアント側の更新検出（スキャン）間隔をGPOで調整し、失敗した端末がより早くリトライできる状態を作ることです。特に移行直後は、WSUS側の負荷が時間帯で波打ちます。検出頻度を短くしておくと、「たまたま重い瞬間に当たって失敗した端末」が、軽い瞬間に当たり直す機会が増え、初期の収束が早まります。
設定場所（GPOパス）
グループポリシー管理エディターで、以下を設定します。
- コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → Windows Update → 自動更新の検出頻度
推奨値の考え方（1時間にするべき？3時間で十分？）
今回の事例では、次のような結果になりました。
- 検出頻度を1時間にした端末群は早期に改善
- 既定のままの端末も数時間後には結果的に更新を取得できた
- 恒久的に1時間へ固定する必要は薄く、3時間程度で十分そうという着地
現場目線では、「一時的に短くして収束させ、落ち着いたら戻す」のが最も安全です。頻度を短くし過ぎると、環境によっては逆にWSUSへ問い合わせが増え、別の詰まり方（IISの同時接続やCPUスパイク）を誘発する可能性があるためです。
| 検出頻度の目安 | 向いている状況 | メリット | 注意点 |
|---|---|---|---|
| 1時間 | 移行直後に大量端末が80244010で詰まり、早く収束させたい | 失敗端末のリトライが早く、初期収束が速い | 問い合わせ総数が増えやすい。全台一律で長期運用は避け、段階的に戻す |
| 3時間 | 移行直後の安定化、または中規模環境の常用 | リトライ機会を確保しつつ、過剰負荷になりにくい | ピーク時間帯に集中する場合は、OU分割や展開順の工夫も併用 |
| 既定（未構成） | すでに安定稼働しており、WSUS側に余裕がある | 無駄なスキャンを増やさない | 移行直後の“初回詰まり”が長引くことがある |
現実的な運用：一時GPOで「新規/追加端末」だけ頻度を短くする
おすすめは、全台一律で頻度を変えるのではなく、OUやセキュリティグループで対象を切り、移行直後に詰まりやすい端末だけを短い頻度で回す方法です。
- 例：新規導入/追加端末OUにだけ「検出頻度=1時間」のGPOをリンク
- WSUSが落ち着いたら「3時間」へ緩め、最終的に未構成へ戻す
- サーバー負荷（CPU・メモリ・IIS応答・SUSDB）を見ながら、対象OUを段階的に増やす
設定を反映させる手順と、効いているかの確認ポイント
クライアント側：GPO反映とスキャン実行
まずはポリシーを適用し、端末が新しい設定を受け取っていることを確認します。
gpupdate /forceWindows 10/11系では、更新スキャンは「UsoClient」や「Windows Update」タスクで動作します。手動でトリガーするなら次のような方法があります（環境により挙動が異なるため、過信は禁物です）。
UsoClient StartScan古い手順として知られる次のコマンドも、OSバージョンによってはログ上の挙動が限定的です。
wuauclt /detectnow
wuauclt /reportnowレジストリで「検出頻度」が入ったか確認する
GPOで設定すると、一般に次のキー配下に値が入ります（存在しない場合は未構成、またはポリシー未反映の可能性があります）。
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
DetectionFrequencyEnabled
DetectionFrequency現場では「ポリシーを変えたつもりが、別GPOで上書きされていた」という事故も多いので、gpresultで適用GPOを確認するのが確実です。
gpresult /h C:\Temp\gp.htmlWindowsUpdateログで80244010の出方を観察する
クライアントで80244010が出ている場合、Windows Update関連ログに「サーバーとのやり取りが途中で打ち切られた」文脈が出ます。Windows 10/11では統合ログ化されているため、取得は次のように行います。
PowerShell（管理者）
Get-WindowsUpdateLog「台数が多すぎるだけ？時間が経てば直る？」への答え
移行直後に80244010が多発しても、WSUS側のキャッシュが効き始めたり、端末側のスキャンタイミングがばらけたりして、数時間〜半日程度で自然に落ち着くことがあります。実際、今回の事例でも「既定のままでも数時間後には結果的に更新を取得できた」端末がありました。
ただし、次の条件があると“自然収束”が遅れやすくなります。
- 一斉切替で、同時スキャンが毎回同じ時間帯に集中している
- WSUSに承認済み更新が膨大で、初回スキャンが長い
- WSUSのメンテナンス未実施で、SUSDBが重い
- IIS（WsusPool）の再起動・リサイクルが頻繁に発生している
この場合は「検出頻度の一時短縮」だけでも収束が早まることが多く、さらにサーバー側の整備を並行することで再発率を下げられます。
サーバー側も整える：80244010を出しにくくするWSUS安定化の実務ポイント
クライアント側の検出頻度調整は、いわば“渋滞を抜けるための迂回路”です。再発を減らすには、WSUS側で「渋滞が起きにくい道路」に整備しておくのが重要です。
最優先：WSUSの定期メンテナンスを仕組み化する
WSUSは放置すると、不要な更新メタデータや置換済み更新、不要PC情報が積み上がり、コンソール操作もクライアント応答も重くなります。移行直後こそ、次のメンテナンスを早めに入れておくと効果が出やすいです。
| 項目 | 推奨頻度 | 狙い | 補足 |
|---|---|---|---|
| サーバークリーンアップ（不要更新/不要PC/期限切れ等） | 月1回（移行直後は週1でも可） | メタデータ肥大化を抑え、初回スキャンの負担を軽くする | 実行時間が長いことがあるため、業務時間外推奨 |
| 置換済み更新の整理（承認取り消し・期限切れ・拒否） | 月1回 | クライアントが評価すべき更新数を減らす | 運用ポリシーと衝突しないよう、承認ルールを先に決める |
| SUSDBのインデックス再構成/統計更新 | 月1回 | 検索・レポート・クライアント応答の改善 | WID/SQLのどちらでも効果あり。バックアップとセットで |
| 不要な製品/分類/言語の削減 | 構築時＋見直しは随時 | 同期データとメタデータの総量を減らす | 必要な製品だけに絞るほど、WSUSは安定しやすい |
IIS（WsusPool）とサーバーリソースの見直し
台数増加時に詰まりが出るときは、WSUSサーバーのCPU・メモリ・ディスクI/Oに加え、IISアプリケーションプール（WsusPool）の設定が効いていることが多いです。特に「プライベートメモリ制限で頻繁にリサイクル→途中接続が切れてクライアントが取り直し→往復回数超過」というパターンはよく見ます。
| 観点 | 見るポイント | 詰まりやすい兆候 | 改善の方向性 |
|---|---|---|---|
| CPU/メモリ | WSUSサービス、w3wp.exe、SQL/WID | スキャン開始時間帯にCPU100%が続く | リソース増強、同期/承認の見直し、クライアント切替を段階化 |
| ディスクI/O | SUSDBやContentの配置ディスク | ディスク待ちで応答が遅延 | 高速ストレージ、SUSDBとContentの分離、不要更新削減 |
| IIS WsusPool | リサイクル、キュー長、メモリ制限 | IISログに503/500が増える、接続が途中で切れる | リサイクル条件の見直し、キュー長調整、メモリ制限の再検討 |
ここは環境差が大きいので「これが正解」と断言しませんが、移行後に急増したときは、少なくともWsusPoolが頻繁に落ちていないかを確認してください。イベントログ（アプリケーション/システム）とIISログを併せて追うと、クライアント側の80244010と時刻が一致していることがあります。
切り分け：80244010が出るときに“先に潰す”べき基本チェック
本題の対処（検出頻度調整）を入れても改善が遅い場合は、そもそも「新WSUSに正しく到達できているか」「IIS/SSL/名前解決で詰まっていないか」を短時間で切り分けると手戻りが減ります。
| チェック項目 | 確認方法 | OKの目安 | NGのときの対処例 |
|---|---|---|---|
| WSUSのURL/ポート（8530/8531など） | GPOの「イントラネットMicrosoft更新サービスの場所を指定する」 | 全端末が新WSUSを参照 | 旧WSUSの設定が残っていればGPO整理、OUリンクの見直し |
| 疎通（名前解決・FW・プロキシ） | ブラウザ/PowerShellでselfupdate配下へアクセス | HTTP 200でファイル取得できる | FW開放、DNS修正、WinHTTPプロキシ設定確認 |
| WSUS同期が完了しているか | WSUSコンソールで同期状態を確認 | 最新同期が成功し、エラーがない | 上位ソース（Microsoft Update/上位WSUS）との通信を修正 |
| WSUSコンソール操作が重すぎないか | 「すべての更新」表示や承認操作の反応 | 実用範囲の応答速度 | 不要更新整理、DBメンテ、製品/分類/言語の絞り込み |
selfupdateへの簡易テスト（例）
クライアントから、WSUSのselfupdate配下にアクセスできるかを確認します。HTTP/HTTPSやポートは環境に合わせて読み替えてください。
PowerShell（例）
Invoke-WebRequest -UseBasicParsing http://WSUS-SERVER:8530/selfupdate/wuident.cab移行を“作業”で終わらせない：再発させないための段階移行プラン
今回のように「少数はOK、全台で詰まる」問題は、技術というより展開手順（ロールアウト設計）で防げる部分が大きいです。次回以降の移行・更改で同じ痛みを減らすために、段階移行の型を用意しておくと強いです。
段階移行の例
- 新WSUSを構築し、同期・初期承認・不要分類の除外まで完了させる
- パイロットOU（数台〜数十台）だけ新WSUSへ向け、1〜2日観測する
- 追加OU（部署単位など）を段階的に切り替える
- 移行直後のOUには一時的に「検出頻度=1〜3時間」のGPOを適用し、収束を早める
- 安定後、検出頻度GPOは3時間→未構成へ戻す（または社内標準値へ）
- 月次メンテナンス（クリーンアップ/DB/置換済み整理）をスケジュール化する
このやり方だと、もし詰まっても影響範囲が限定され、WSUS側のボトルネック（CPU/メモリ/IIS/DB/ネットワーク）も観測しやすくなります。
よくある質問
検出頻度を短くすると、サーバー負荷が増えて逆効果になりませんか？
増える可能性はあります。だからこそ、「移行直後だけ」「対象を絞って」使うのがコツです。80244010で失敗している状態は、そもそも“成功するまでに何度もやり直している”ことが多く、失敗のリトライを上手く分散させることで結果的に収束が早まるケースがあります。全台一律で長期運用するより、OU単位で段階的に適用・解除する方が安全です。
結局、何をすれば最短で直りますか？
実務的には次の順が最短です。
- WSUS URL/ポート、疎通、同期状態の基本を短時間で確認
- 詰まりが「台数増加で顕在化」しているなら、検出頻度を一時的に1〜3時間へ
- WSUSクリーンアップと置換済み更新整理、SUSDBメンテを実施
- WsusPoolのリサイクルやIISログのエラーを確認し、必要なら設定・リソースを見直す
まとめ：80244010は“移行直後の混雑”で起きやすい。検出頻度の一時調整で収束を早める
WSUS（Server 2016）へ移行した直後に、クライアントが80244010（0x80244010）で更新検索できない問題は、WSUSへの問い合わせが多段になり、許容される往復回数を超えて失敗する状態で起きやすいです。放置しても時間経過で収束することはありますが、移行直後の混雑を早く抜けるには、GPOで「自動更新の検出頻度」を一時的に短くするのが効果的でした。
また、上記ポリシー変更は「初期収束を早めるための一時対応」と割り切り、落ち着いたら頻度を戻す運用も現実的です。併せて、WSUSの定期メンテナンス（サーバークリーンアップ、不要/置換済み更新の整理、DBインデックス等）や、VM/サーバーリソース（CPU・メモリ、IISのWsusPool）も見直しておくと、台数増加時の詰まりが起きにくくなります。
コメント