SCCM（ConfigMgr）から WSUS 2016（SUP）経由で更新プログラムを配信しているのに、クライアントの WindowsUpdate.log に「WS error」が出てスキャンやインストールが失敗する――この症状は、WSUS 側 IIS のアプリケーションプール（WsusPool）がメモリ制限で不安定化しているケースが非常に多いです。本記事では、最短で原因を切り分ける手順と、効果の高い対策を具体的にまとめます。
まず押さえる：SCCM の「更新配信」と WSUS の役割
「SCCM で配っているのに、なぜ WSUS の設定を触る必要があるのか？」が腑に落ちないと、対処が遠回りになります。SCCM のソフトウェア更新（Software Updates）は内部的に WSUS の仕組みを使っており、特に 適用判定（スキャン） はクライアントが WSUS/SUP の WebService にアクセスして行います。
| 要素 | 主な役割 | ここが壊れると起きやすい症状 |
|---|---|---|
| SCCM サイトサーバー | 更新ポリシー作成、同期管理、配布指示 | 同期失敗、展開状態の不整合 |
| SUP（Software Update Point） | クライアントのスキャン先。実体は WSUS（IIS） | WindowsUpdate.log に「WS error」、スキャン失敗 |
| DP（Distribution Point） | 更新ファイル（バイナリ）配布 | ダウンロード失敗、コンテンツ未検出 |
| クライアント | スキャン→必要判定→ダウンロード→インストール | 「必要な更新が検出されない」「インストールできない」 |
つまり「WS error」が出ている場合は、まず クライアント→SUP（=WSUS/IIS）への WebService 通信 を疑うのが近道です。コンテンツ配布（DP）や Windows Update そのものを疑う前に、SUP 側が安定して応答できているかを確認します。
現象の特徴：WindowsUpdate.log の「WS error」と SCCM 側のよくある見え方
WindowsUpdate.log の「WS error」は、一般的に WS（Web Service）への通信に失敗した ことを示すログとして出現します。環境によっては、以下のような症状が併発します。
- Software Center で更新が「ダウンロード待ち」「インストール待ち」のまま進まない
- 「更新プログラムの確認」に時間がかかりすぎる／途中で失敗する
- SCCM コンソールでは展開済みなのに、対象端末で「必要」と判定されない
- 一部の時間帯（朝一・パッチ適用直後・全社一斉スキャン）だけ失敗が増える
ログの例（表現は環境で異なりますが、雰囲気としては次のような形が多いです）。
WARNING: Send failed with hr=0x80072EE2
WARNING: WS error: ...（WebService への通信エラー）
WARNING: Failed to sync server updates. err=...
重要なのは、クライアントが悪いとは限らない という点です。特に「一定数の端末だけで起きる」「ピーク時だけ起きる」場合、サーバー側の負荷・リサイクル・接続枯渇などの影響を受けやすくなります。
原因の第一候補：WSUS 2016 の IIS（WsusPool）がメモリ制限に到達している
WSUS は IIS 上で複数の WebService を提供しています。SCCM クライアントはそれらにアクセスしてメタデータ（適用判定に必要な情報）を取得しますが、WSUS の環境が大規模化すると WsusPool（アプリケーションプール）に紐づく w3wp.exe がメモリを消費し、IIS の設定（プライベート メモリ制限）に到達 しやすくなります。
プライベート メモリ制限に達すると、IIS はアプリケーションプールをリサイクル（再起動）させたり、状況によっては停止させたりします。これが発生すると、クライアントから見ると WebService が一時的に応答しなくなり、結果として WindowsUpdate.log に「WS error」が出やすくなります。
| WSUS/IIS 側で起きていること | クライアント側の見え方 | よく出る場所 |
|---|---|---|
| WsusPool がリサイクル中（w3wp 再起動） | 一時的に接続失敗、タイムアウト | WindowsUpdate.log / WUAHandler.log |
| WsusPool が停止（Stopped） | 常に失敗。WebService URL へアクセスしても開けない | WindowsUpdate.log、IIS マネージャー |
| 高負荷で応答遅延（キュー詰まり） | 成功/失敗が混在、ピーク時間帯に失敗が増える | IIS ログ、パフォーマンスモニタ |
「WSUS 2012 向けの Hotfix 情報が多い」「WSUS 2016 では何を直すべきか分からない」という状況でも、まずは IIS 側の WsusPool のメモリ制限を見直す と解決につながることが多いです。
サーバー側の証拠を集める：イベントログと IIS ログで原因を裏付ける
「たぶんメモリ制限だと思う」だけで設定を変えるより、落ちている証拠 を押さえると再発防止まで一気に進みます。特に、次のログは短時間で確認でき、判断材料として強力です。
| 見る場所 | 探すキーワード例 | 何が分かるか | 次のアクション |
|---|---|---|---|
| イベント ビューアー（システム） | WsusPool、w3wp、recycle、private memory | メモリ制限到達によるリサイクル、アプリプール停止の有無 | プライベート メモリ制限の増加、停止要因の特定 |
| イベント ビューアー（アプリケーション） | .NET Runtime、Application Error | w3wp の例外や .NET 側の異常終了 | 更新適用・ロール修復、例外内容の調査 |
| IIS ログ | HTTP 503 / 500、応答時間増大 | WebService が落ちた瞬間の HTTP ステータス | ピーク時間帯と照合、負荷分散や分散スキャン |
IIS ログの既定パスは C:\inetpub\logs\LogFiles 配下です（サイト ID ごとにフォルダが分かれます）。WSUS の ASMX に対して 503（Service Unavailable） が増えている場合は、WsusPool が落ちている/詰まっている可能性が高くなります。
また、タスク マネージャーやリソース モニターで w3wp.exe のメモリ使用量 を見るだけでも、ピーク時の傾向がつかめます。「スキャンが集中するタイミングで w3wp のメモリが上がり、直後に失敗が増える」なら、メモリ制限が当たりである確度が上がります。
最短で切り分ける：WebService が安定して返るかを直接確認する
クライアントのログだけでは「サーバーが落ちているのか」「ネットワークなのか」「名前解決なのか」が混ざります。まずは WSUS/SUP の WebService を直接開いて、正常に応答するか・不安定ではないか を確認します。
| 確認URL（例） | 目的 | 期待する状態 |
|---|---|---|
http://<SUPのFQDN>:8530/ClientWebService/client.asmx | クライアント向け WebService | ASMX のサービス一覧が表示される |
http://<SUPのFQDN>:8530/SimpleAuthWebService/SimpleAuth.asmx | 認証系 WebService | ASMX のサービス一覧が表示される |
http://<SUPのFQDN>:8530/ServerSyncWebService/ServerSyncWebService.asmx | 同期系 WebService（SUP 側） | ASMX のサービス一覧が表示される |
ブラウザでの確認が難しい場合は、WSUS サーバー自身やクライアント端末から PowerShell で叩く方法も有効です（社内プロキシ配下でも挙動が見やすいことがあります）。
# 8530（HTTP）の例
Invoke-WebRequest -Uri "http://<SUPのFQDN>:8530/ClientWebService/client.asmx" -UseBasicParsing
# 8531（HTTPS）の例（SSL を使っている場合）
Invoke-WebRequest -Uri "https://<SUPのFQDN>:8531/ClientWebService/client.asmx" -UseBasicParsing
ここで 開けない／表示が極端に遅い／アクセスのたびに成功と失敗が変わる なら、クライアント側の設定変更よりも先に WSUS/SUP サーバー側の IIS/WSUS を安定化 させるのが優先です。
解決策：WsusPool の「プライベート メモリ制限（KB）」を増やす
原因候補として多い「WsusPool のメモリ制限到達」に対しては、プライベート メモリ制限（KB）を増やす のが定番かつ効果が高い対処です。Microsoft の案内でも、まず 4,000,000 KB 程度を目安に増やし、必要に応じてさらに増やす方針が示されています。
手順（IIS マネージャーでの設定変更）
- WSUS/SUP サーバーで IIS マネージャー（inetmgr）を開く
- ［アプリケーション プール］ を開き、一覧から WsusPool を選択
- 右側の ［詳細設定…］ を開く
- ［リサイクル］→［プライベート メモリ制限 (KB)］ を変更する
- 設定後、WsusPool を ［リサイクル］（必要に応じて IIS 再起動）する
設定値の目安
よく使われる値は 4GB 相当（4,194,304 KB） です。環境によっては 8,000,000 KB（約 8GB）以上が必要になることもありますが、闇雲に上げるのではなく、サーバーの物理メモリや同居している役割（SQL、DP など）を踏まえて決めるのが安全です。
| WsusPool のプライベート メモリ制限（KB） | 目安のメモリ量 | 向いている状況 | 注意点 |
|---|---|---|---|
| 4,000,000 ～ 4,194,304 | 約 4GB | まず試す基準値。中規模～大規模の第一手 | サーバー総メモリが 8GB 未満だと逼迫しやすい |
| 8,000,000 | 約 8GB | 端末台数が多い／スキャン集中が激しい／再発する | WSUS 専用機でメモリに余裕がある前提 |
| 0（無制限） | 上限なし | 「メモリ上限到達で落ちる」状況を強制的に回避したい | メモリ枯渇のリスク。監視・容量設計が必須 |
ポイント：「WsusPool を落とさない」ことが目的ではなく、クライアント向け WebService がピーク時でも安定して応答できる状態 を作ることが目的です。設定変更後は、必ず次の「確認」をセットで実施してください。
コマンドで確認・リサイクルする方法（GUI が使いづらい場合）
# 管理者権限のコマンドプロンプトで実行
%windir%\System32\inetsrv\appcmd list apppool "WsusPool" /text:state
%windir%\System32\inetsrv\appcmd recycle apppool "WsusPool"
変更後の確認：再発を防ぐためのチェックポイント
設定を変えて終わりにすると、別原因だった場合に時間を浪費します。次の観点で「改善したか」「まだ不安定か」を判断すると、切り分けが速くなります。
| 確認観点 | 具体的な確認方法 | 改善している状態 |
|---|---|---|
| WebService 応答 | client.asmx を複数回開く／Invoke-WebRequest で連続実行 | 毎回安定して表示され、極端な遅延がない |
| WsusPool の状態 | IIS マネージャーで Started を維持しているか | Stopped にならない／短時間での連続リサイクルがない |
| イベントログ | アプリケーションログ／システムログに IIS/WSUS 関連のエラーがないか | アプリプール停止や w3wp 異常終了が減る |
| クライアントのスキャン | WUAHandler.log や WindowsUpdate.log、Software Center の更新評価 | スキャンが成功し「必要」判定が正常に出る |
特に SCCM 環境では、クライアント側ログ（WindowsUpdate.log）に加えて次も見ると早いです。
- WUAHandler.log：Windows Update Agent の処理結果（スキャン失敗の詳細が出やすい）
- ScanAgent.log：スキャン開始～終了の流れ
- LocationServices.log：参照する SUP を選定できているか（境界グループや管理ポイントの影響）
- UpdatesDeployment.log：展開の評価と状態遷移
再発しやすい環境の特徴と、運用で効く「現実的な」対策
WsusPool のメモリ制限を上げても、環境条件によっては再発します。ここでは、一般論だけではなく「現場で効きやすい打ち手」を、優先度が高い順に整理します。
スキャンの集中を避ける（ピーク時に落ちるなら最優先）
WSUS/SUP はスキャン要求が同時に集中すると一気に重くなります。たとえば「全社が出社して PC を起動する時間帯」「更新展開直後に一斉評価が走るタイミング」では、WebService が瞬間的に詰まり、結果として「WS error」が出やすくなります。
- 展開スケジュールを段階化して、評価・インストール開始のタイミングを分散する
- 境界グループの設計を見直し、特定 SUP へアクセスが集中しないようにする
- 端末台数が多い場合は、SUP を追加して負荷を分散する（役割分割も検討）
WSUS のメンテナンス不足を解消する（DB 肥大化はメモリ食いの温床）
WSUS はメタデータが増え続ける仕組みです。未承認・期限切れ・置き換え済み（superseded）更新が大量に残っていると、スキャン処理が重くなり、結果として WsusPool のメモリ使用量も増えやすくなります。
| 施策 | 期待できる効果 | 注意点 |
|---|---|---|
| WSUS クリーンアップ（不要更新の削除） | メタデータ削減、スキャン負荷低減 | 初回は時間がかかる。業務時間外推奨 |
| 置き換え済み更新の整理 | スキャン対象が減り、応答が安定しやすい | SCCM 側の運用（承認/展開）と整合させる |
| DB のインデックス最適化（WID/SQL） | 検索が速くなり、ピーク時の詰まりが減る | 手順を誤ると停止時間が伸びるため計画的に |
「メモリを増やしたのに遅い／再発する」場合は、WSUS を軽くする 方向（不要データの削減や DB 最適化）もセットで効きます。特に長期運用の WSUS では、こちらが本命になることもあります。
同居役割が多いなら、WSUS/SUP を分離する
SUP と DP、SQL、管理ポイントなどを同居させていると、ある役割の負荷が別の役割を巻き込みやすくなります。WsusPool の上限を上げても、サーバー全体の物理メモリが足りなければ別の形で不安定化します。
- WSUS/SUP サーバーの物理メモリに余裕があるか（ピーク時も含めて）
- SQL 同居の場合、SQL のメモリ消費が WSUS の余力を奪っていないか
- DP 同居の場合、配布やダウンロード集中でディスク/ネットワークが飽和していないか
それでも「WS error」が消えない場合に疑うポイント
WsusPool のメモリ制限は「当たりやすい原因」ですが、万能ではありません。次の項目に該当する場合は、別の要因で WebService 通信が失敗している可能性があります。
ポート（8530/8531）と名前解決の問題
- クライアントから SUP の FQDN が正しく引けているか（DNS）
- ファイアウォールやセキュリティ製品で 8530/8531 が遮断されていないか
- プロキシ配下の場合、WSUS/SUP がプロキシを経由していないか（または逆に必要なのに設定がないか）
# クライアントから SUP への疎通確認
Test-NetConnection -ComputerName <SUPのFQDN> -Port 8530
Test-NetConnection -ComputerName <SUPのFQDN> -Port 8531
# WinHTTP プロキシ設定の確認（クライアント/サーバー）
netsh winhttp show proxy
SSL（8531）構成の不整合
HTTPS（8531）を使っている場合、証明書の不整合や IIS バインディングの問題で「開ける端末と開けない端末」が出ることがあります。次を重点的に確認してください。
- クライアントが証明書チェーンを信頼しているか（中間証明書含む）
- IIS のバインディングが正しいホスト名・ポート・証明書になっているか
- SCCM 側 SUP の設定（SSL 有無、ポート）が実際の IIS/WSUS と一致しているか
SCCM の SUP 選定（境界グループ）の問題
「同じ拠点の端末だけ失敗する」「一部の端末だけ別 SUP を見ている」場合、境界グループやフォールバック設定により、意図しない SUP を参照していることがあります。LocationServices.log で 参照している SUP の FQDN を確認すると、すぐに当たりが付きます。
クライアント側の破損（最後の手段として）
サーバー側 WebService が安定しているのに特定端末だけ失敗する場合は、クライアント側のキャッシュや Windows Update コンポーネントの破損も疑います。ただし、これは「サーバー側の安定化」をやり切ってからで十分です。
- サービスの状態（wuauserv、BITS、CryptSvc）
- SoftwareDistribution フォルダのリセット（影響を理解した上で）
- SCCM クライアントの修復（ccmrepair）
よくある質問（FAQ）
4GB に上げても再発します。次は 8GB にすべきですか？
再発の頻度とサーバーの物理メモリ次第です。ピーク時に w3wp のメモリが 4GB に張り付いているなら、8,000,000 KB へ増やす価値があります。一方で、サーバー全体のメモリが逼迫している場合は、上限を上げるよりも WSUS のメンテナンス や スキャン分散、SUP の追加 の方が効果的なことがあります。
プライベート メモリ制限を 0（無制限）にすると確実に直りますか？
「上限到達で落ちる」という症状には効きやすいですが、メモリ枯渇という別障害 を呼ぶ可能性があります。WSUS 専用機で十分なメモリがあり、かつ監視ができる運用であれば選択肢になります。迷う場合は、まず 4,000,000～4,194,304 KB から始め、必要に応じて段階的に増やすのが安全です。
WsusPool が勝手に Stopped になります。メモリ制限以外の原因ですか？
Rapid-Fail Protection（短時間に複数回落ちたら停止）の影響や、w3wp の異常終了が原因のことがあります。イベントログ（Application/System）と IIS ログを突き合わせて、停止前後にエラーが出ていないかを確認してください。根本原因が解消されないまま保護機能だけを無効化すると、障害の発見が遅れます。
クライアントで WindowsUpdate.log が見当たりません（Windows 10/11）。
Windows 10/11 では Windows Update のログは ETL 形式で保持され、必要に応じて変換して WindowsUpdate.log を生成します。管理者 PowerShell で次を実行し、生成されたログで「WS error」周辺を確認してください。
Get-WindowsUpdateLogまとめ：WSUS 2016 の WS error は「IIS の WsusPool を安定化」から始める
SCCM（ConfigMgr）環境でクライアントの WindowsUpdate.log に「WS error」が出る場合、まず疑うべきは WSUS 2016 側 IIS（WsusPool）の不安定化 です。特に大規模環境やスキャン集中がある環境では、プライベート メモリ制限に到達して WebService 応答が途切れることが珍しくありません。
- WebService（
client.asmxなど）が安定して開けるかをまず確認 - WsusPool の プライベート メモリ制限（KB） を 4GB 目安で増やし、必要なら段階的に拡張
- 変更後は IIS/イベントログ/クライアントログで「安定したか」を必ず確認
- 再発する場合は、スキャン分散・WSUS メンテナンス・SUP 追加など運用面の打ち手も併用
「WS error」はクライアント側に出るため端末トラブルに見えがちですが、根が サーバー側の WebService 応答不良 にあることが多い症状です。サーバー側の安定化から着手すると、解決までの距離が一気に短くなります。
コメント