SCCM（Configuration Manager／ConfigMgr）でソフトウェア更新を展開しているのに、Windows 10 クライアントの Software Center に更新が出てこない場合、原因は「展開設定」だけでなく、クライアント⇔WSUS（SUP）の通信やIIS の受け口が壊れているケースが非常に多いです。エラー 82492（0x1423C）に遭遇したときの切り分け手順を、実務で再現性の高い順に整理します。
まず押さえるべき結論：見るべきは「疎通」と「HTTP の結果」です
Software Center に更新が出てこないとき、最短で原因に近づける考え方は次のとおりです。
- クライアントが SUP（＝WSUS）へ正しく到達できているか（DNS/ポート/証明書/認証/Firewall）
- 到達した結果、WSUS/IIS が何を返しているか（IIS ログの HTTP ステータス）
- ConfigMgr のポリシーとスキャンが走り、ログに痕跡が残っているか（クライアントログ・SUPログ）
WSUS のアプリケーションプール（WsusPool）のメモリ上限を 0（無制限）にする設定は、あくまで性能・安定性対策の一部であり、通信できない／IIS が誤応答している状況は改善しません。まずは「通信できているか」「何の HTTP エラーで落ちているか」を可視化します。
症状を整理：Software Center に更新が出ないときに起きていること
ConfigMgr のソフトウェア更新は、ざっくり以下の流れで成立します。
| 段階 | 何が起きる | ここが壊れると |
|---|---|---|
| ポリシー受信 | クライアントが「この更新を評価してね」という情報を受け取る | 更新が表示されない／評価自体が走らない |
| SUP（WSUS）へスキャン | Windows Update Agent が WSUS Web サービスへ問い合わせ、必要な更新を判定 | Software Center が空のまま／スキャン失敗がログに残る |
| コンテンツ取得 | 必要な更新のコンテンツを DP から取得 | ダウンロードで止まる（表示は出るが進まない） |
| インストール | インストール・再起動制御 | 適用段階で失敗（エラーは Software Center に出やすい） |
今回の「Software Center に更新が出てこない」は、特にポリシー受信かSUP（WSUS）スキャンで止まっている可能性が高いです。ここを分解して切り分けます。
切り分けの全体像（迷ったらこの順で確認）
| 優先度 | 確認 | 目的 | 所要感 |
|---|---|---|---|
| 高 | クライアント→WSUS Web サービスへ FQDN でアクセス | ネットワーク/IIS/証明書の入口を一発で検証 | 数分 |
| 高 | クライアントでスキャンを手動実行し、同時にログ確認 | 「動いていない」のか「動いて落ちている」のかを確定 | 10〜20分 |
| 高 | WSUS 側 IIS ログで HTTP ステータス確認 | 401/403/404/500/503 などで原因を絞る | 10〜30分 |
| 中 | SUP/WSUS 側 ConfigMgr ログ確認 | SUP の構成不整合、同期、接続の問題を確認 | 30〜60分 |
| 中 | WSUS Best Practices（IIS/プール）再適用 | 性能劣化・不安定要因を除去 | 30〜90分 |
| 低 | WSUS メンテ（クリーンアップ/DB最適化/コンテンツ整合） | 重い環境のタイムアウトや異常を改善 | 環境次第 |
クライアントが参照している WSUS（SUP）が正しいか確認する
最初に「そもそもクライアントが、意図した SUP/WSUS を参照しているか」を確認します。ここがズレていると、いくら WSUS を直しても当たりません。
確認ポイント
- ConfigMgr クライアントが有効で、ソフトウェア更新が有効になっている（クライアント設定で Software Updates を無効化していない）
- 境界グループ（Boundary Group）により SUP が割り当てられている（別の SUP を引いていない）
- GPO で Windows Update のサーバー指定（WUServer）が上書きされていない（これが最頻出の地雷）
GPO 上書きチェック（必ず見る）
ドメイン GPO で「社内 WSUS」を指定している組織では、ConfigMgr が設定する WSUS/SUP の情報がポリシー競合で上書きされ、クライアントが別 WSUS を見に行っていることがあります。次を確認してください。
gpresult /h C:\temp\gp.htmlを実行し、Windows Update 系ポリシーが適用されていないか- レジストリ
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdateにWUServerやWUStatusServerが固定で入っていないか
ポイント：ConfigMgr で管理する場合、Windows Update の「更新元サーバー」は SUP を指す必要があります。GPO が別サーバーを指していると、Software Center の更新評価が崩れます。
WSUS Web サービスへ FQDN でアクセスして疎通確認する
ここが今回の本丸です。「クライアントから WSUS の Web サービスに到達できるか」を、最短で確認します。
まず試すべき URL（HTTP/8530 の例）
クライアント端末から、以下の URL を開きます（ブラウザでも PowerShell でも可）。
http://<SUPまたはWSUSのFQDN>:8530/SimpleAuthWebService/SimpleAuth.asmx
環境によっては HTTPS/8531 を使います。
https://<SUPまたはWSUSのFQDN>:8531/SimpleAuthWebService/SimpleAuth.asmx
PowerShell での確認例（ブラウザが使いづらい場合）
nslookup <SUPのFQDN>
Test-NetConnection -ComputerName <SUPのFQDN> -Port 8530
Invoke-WebRequest "http://<SUPのFQDN>:8530/SimpleAuthWebService/SimpleAuth.asmx" -UseBasicParsing期待する状態：到達できれば、.asmx のサービス説明ページ（XML/ASP.NET Web Service の画面）が返るか、少なくとも HTTP 応答として 200 系が返ります。
到達できない／エラーになる場合に疑うもの
| 症状 | 疑うポイント | 具体的な確認・対処 |
|---|---|---|
| 名前解決できない | DNS | FQDN の A レコード、クライアントの DNS サフィックス、別名（CNAME）運用の整合 |
| ポートに繋がらない | Firewall/ネットワーク | クライアント→SUP の 8530/8531 を許可、途中FWで遮断されていないか |
| HTTPS で証明書エラー | 証明書/信頼 | クライアントが証明書を信頼しているか、CN/SAN が FQDN と一致するか、失効確認（CRL）到達性 |
| 403/401 が返る | IIS 認証/SSL 強制 | WSUS の仮想ディレクトリで不要な認証変更をしていないか、SSL 必須の設定が入っていないか |
| 404 が返る | WSUS Web サービス欠損 | WSUS 役割の破損、仮想ディレクトリ消失、サイトバインドのズレ、パスの不整合 |
| 500/503 が返る | アプリプール停止/WSUS 破損 | WsusPool が停止していないか、Rapid-Fail Protection、イベントログ（Application/System） |
この疎通確認は、「Software Center に更新が出てこない」問題の半分以上をここで炙り出せるくらい強力です。特に 401/403/404/503 が出たら、次の IIS ログ確認へ進みます。
クライアントでスキャンを手動実行し、ログで“今の失敗”を捕まえる
疎通が OK でも更新が出ないなら、次はスキャンを強制して、ログに「何が起きたか」を残させます。
実行方法（GUI）
- コントロール パネル → Configuration Manager → Actions
- Software Updates Scan Cycle を選択して Run Now
このタイミングで同時に見るべきログ（クライアント）
クライアント側は、まず以下を優先して確認します。
| ログ | 主に分かること | 見るべき観点 |
|---|---|---|
| WUAHandler.log | Windows Update Agent（WUA）連携の成否 | スキャン開始/完了、エラーコード、WSUS URL へのアクセス失敗 |
| ScanAgent.log | スキャンジョブの進行状況 | スキャン要求が走っているか、失敗理由の手がかり |
| UpdatesDeployment.log | 展開（デプロイメント）評価 | 「そもそも必要な更新がある」と判断しているか |
| LocationServices.log | クライアントが参照する SUP/MP/DP の決定 | どの SUP を使うことになっているか、境界のズレ |
更新が出てこない場合、ログ上は大きく次のどちらかになります。
- スキャンが始まっていない（ポリシー未受信、Software Updates が無効、クライアント健全性など）
- スキャンは始まるが失敗する（WSUS 到達不可、IIS エラー、証明書、認証、タイムアウト、WSUS 過負荷など）
WindowsUpdate.log も合わせて取る（Windows 10 では生成が必要）
Windows 10/11 では従来の WindowsUpdate.log は ETW から生成する方式です。エラーの根が WUA 側にある場合、こちらが決定打になることがあります。
Get-WindowsUpdateLog -LogPath C:\temp\WindowsUpdate.logWSUS サーバー側：IIS ログで“HTTP の答え”を確認する
次に、WSUS 側でクライアントのアクセスが実際に来ているか、来ているなら何を返しているかを確認します。ここで「ネットワークは通るのに更新が出ない」問題の原因がかなり具体化します。
IIS ログの場所
C:\inetpub\logs\LogFiles\W3SVC<番号>\
該当日時のログを開き、クライアントの IP や FQDN、SimpleAuthWebService や ClientWebService などのパスで絞り込みます。
よく見る URL パス（例）
| パス例 | 意味 | このパスが出ないとき |
|---|---|---|
/SimpleAuthWebService/SimpleAuth.asmx | クライアントが WSUS とやり取りできるかの入口 | そもそも SUP/WSUS に到達できていない可能性 |
/ClientWebService/client.asmx | クライアント向け WSUS Web サービス | 仮想ディレクトリ欠損や認証変更の疑い |
/Content/ | WSUS のコンテンツ配布（環境による） | 今回の「表示されない」段階より後工程の可能性 |
HTTP ステータス別：原因と対処の当たりを付ける
| ステータス | 意味（ざっくり） | 原因の典型 | 対処の方向性 |
|---|---|---|---|
| 200 | 成功 | HTTP 上は正常 | 次は WSUS/SUP ログやクライアント側の評価・展開条件を疑う |
| 401 | 認証が必要 | IIS 認証を変更した、匿名アクセス無効化、プロキシ/中間装置の影響 | WSUS 仮想ディレクトリの認証設定を既定に戻す（不用意な変更は戻す） |
| 403 | 禁止 | SSL 必須、IP 制限、要求フィルタ、証明書関連 | SSL の必須設定や IP 制限を確認、HTTPS 運用なら証明書の整合性を再点検 |
| 404 | 見つからない | 仮想ディレクトリ消失、WSUS/IIS 構成崩れ、別サイトに飛んでいる | WSUS 役割の修復/再構成、サイトバインド確認、WSUS の再構成検討 |
| 500 | サーバー内部エラー | WSUS アプリ側例外、web.config 破損、DB 接続問題 | イベントログ確認、WSUS ログ確認、WSUS サービス健全性確認 |
| 503 | サービス利用不可 | WsusPool 停止、Rapid-Fail、過負荷、メモリ枯渇 | アプリプール状態確認、イベントログ、WsusPool 設定見直し、性能対策 |
「IIS ログで 401/403/404/503 が出ている」のに WSUS のメモリ上限だけ変えても、根本は変わりません。HTTP エラーに沿って、IIS 構成・証明書・仮想ディレクトリを直すのが近道です。
WSUS の Best Practices：IIS 設定が崩れていないか再確認する
疎通はできるがスキャンが不安定、あるいは 500/503 が出る場合、WSUS の推奨設定（いわゆる Best Practices）を再点検します。環境によって細部は異なりますが、よく効く“崩れポイント”は共通しています。
WsusPool でよく見直す項目
| 項目 | 意図 | 崩れると起きやすいこと |
|---|---|---|
| プライベート メモリ制限（Private Memory Limit） | 大規模メタデータでも落ちにくくする | 503、スキャン途中で応答不能、アプリプール再起動 |
| キュー長（Queue Length） | 同時接続を捌けるようにする | アクセス集中時に取りこぼし、タイムアウト |
| アイドル タイムアウト | 必要なときに即応答できるようにする | しばらく放置後に最初のスキャンが失敗しやすい |
| リサイクル設定 | 不要な頻繁な再起動を避ける | スキャン時間帯に落ちる／503 が出る |
重要：推奨値は OS/WSUS 版、接続台数、メタデータ量で変わります。すでに「メモリ上限 0」まで試している場合でも、アプリプールが停止していないか、Rapid-Fail Protection で落ちていないか、IIS 側で別の制限（SSL 必須、認証変更、IP 制限など）が入っていないかを合わせて見直してください。
WSUS 運用で“気づかないうちに効いてくる”性能問題
WSUS はメタデータが肥大化すると、スキャン応答が遅くなり、結果的にクライアント側でタイムアウトや失敗が増えます。Software Center に更新が出ない＝同期が壊れているとは限らず、WSUS が重すぎて実用上スキャンできていないケースがあります。
- WSUS クリーンアップ（期限切れ・不要更新の削除）
- DB メンテナンス（インデックス再構築など）
- コンテンツ整合性（欠損が多いと処理が重くなる）
ただし、これらは環境負荷がかかる場合があるため、まずはIIS ログとエラー傾向を掴んでから実施するのがおすすめです。
SUP/WSUS 側：ConfigMgr のログで「SUP が正常か」を確認する
WSUS 自体の HTTP 応答が問題なさそうなら、SUP としての ConfigMgr 側連携（構成・同期）が崩れていないかを確認します。サーバー側の代表的なログは次のとおりです。
| ログ | 場所（代表例） | 分かること | 見るべきポイント |
|---|---|---|---|
| WCM.log | サイトサーバー | SUP の構成適用 | SUP 設定適用エラー、SSL 設定不整合、WSUS 接続失敗 |
| WSUSCtrl.log | サイトサーバー | WSUS 健全性チェック | WSUS API エラー、Web サービス到達性、同期前提の異常 |
| SMS_WSUS_SYNC_MANAGER.log | サイトサーバー | 同期処理 | 同期が成功しているか、失敗の理由（カテゴリ/製品/分類など） |
| SUPSetup.log | SUP サーバー | SUP 役割のインストール/更新 | SUP 追加時の失敗、WSUS コンポーネント呼び出しエラー |
これらのログで「WSUS への接続に失敗」「Web サービス呼び出し失敗」「構成適用失敗」が出る場合、クライアントではなくSUP の土台（WSUS/IIS/証明書/ポート）が原因である可能性が高まります。
クライアント側：Software Center に出ないときの“実務的な見方”
「展開しているのに出ない」現象は、実務上は次の 3 パターンに分かれます。
| パターン | 状況 | まず見るログ | 当たりやすい原因 |
|---|---|---|---|
| A | スキャンが走っていない | PolicyAgent.log / UpdatesDeployment.log | ポリシー未受信、クライアント設定で更新無効、クライアント不調 |
| B | スキャンが走るが失敗する | WUAHandler.log / ScanAgent.log / WindowsUpdate.log | WSUS 到達不可、IIS 401/403/404/503、証明書、TLS/暗号スイート、WSUS 過負荷 |
| C | スキャンは成功するが出ない | UpdatesDeployment.log / UpdatesHandler.log | 展開条件（期限/ユーザー体験/可用性）、対象コレクション誤り、更新が不要（既に適用済み/置き換え） |
エラー 82492（0x1423C）が出ている場合は、多くの現場でB（スキャンは動くが WSUS とのやり取りで失敗）側に寄ります。だからこそ、WSUS Web サービス疎通 → IIS ログの HTTP エラー確認 → クライアントログの順が効率的です。
「WSUS にはアクセスできるのに改善しない」場合の追加チェック
SimpleAuth.asmx へ到達でき、IIS も 200 を返しているのに改善しない場合、次の“盲点”が効きます。
HTTPS 運用の盲点（証明書は“表示できる”だけでは足りない）
- 証明書の CN/SAN が アクセスしている FQDN と一致しているか
- クライアントが ルート/中間証明書 を信頼しているか
- 失効確認（CRL）にアクセスできず、TLS ハンドシェイクが遅延/失敗していないか
- 社内セキュリティ製品や SSL インスペクションが WSUS 通信を壊していないか
IIS 側の“余計な硬化”
- WSUS 配下の仮想ディレクトリに対して、管理者が独自にWindows 認証必須や匿名無効などを入れてしまう
- SSL 必須を特定のパスに入れてしまい、HTTP/HTTPS の不整合が起きる
- URL リライト、要求フィルタ、IP 制限など、別用途の設定が WSUS にも効いてしまう
セキュリティ硬化は重要ですが、WSUS は“既定の前提”で動く構成が多く、変更が小さくても影響が大きいです。IIS ログで 401/403 が出るなら、ここが本命になります。
展開側の見落とし（「通信の問題」だと思い込みがち）
- 更新が対象コレクションに正しく展開されているか（別コレクションに投げていた）
- デプロイが Available（任意）なのか Required（必須）なのか
- メンテナンスウィンドウ、ユーザー体験設定、期限、再起動制御で“見え方”が変わっていないか
- 更新がSuperseded（置き換え）やExpiredで、実質的に配布対象になっていないか
ログを揃えて原因を“一発で特定”するためのセット
最終的に「どこで止まっているか」を確定するには、ログが最短ルートです。問い合わせやエスカレーションでも通用する“最低限のセット”を挙げます。
クライアント側（該当端末から）
- WUAHandler.log
- ScanAgent.log
- UpdatesDeployment.log
- LocationServices.log
- 必要に応じて WindowsUpdate.log（Get-WindowsUpdateLog で生成）
SUP/サイトサーバー側
- WSUSCtrl.log
- WCM.log
- SMS_WSUS_SYNC_MANAGER.log
- 必要に応じて SUPSetup.log
WSUS（IIS）側
- IIS ログ（該当時間帯）：
C:\inetpub\logs\LogFiles\W3SVC<番号>\ - イベントログ（Application/System）：WsusPool 停止や.NET例外が出ていないか
時短のコツ：クライアントでスキャンを「今」実行し、その時刻（分単位）で IIS ログと突き合わせると、原因が HTTP レベルで切れ味良く出ます。Software Center が空でも、IIS ログに 401/403/404/503 が残れば、次の打ち手はほぼ決まります。
最短で解決するチェックリスト
| チェック | OK の基準 | NG のときの次アクション |
|---|---|---|
クライアント→SimpleAuth.asmx 到達 | 200 系で応答が返る | DNS/ポート/Firewall/証明書/SSL/認証を疑う |
| スキャンを手動実行してログが動く | WUAHandler/ScanAgent に開始・結果が残る | クライアント設定/ポリシー受信/クライアント健全性を疑う |
| IIS ログにクライアントアクセスがある | 該当端末 IP が出る | ネットワーク経路、名前解決、実際の参照 SUP のズレを疑う |
| IIS ログのステータスが 200 | 401/403/404/500/503 が出ない | SUP 側ログ、展開条件、WSUS 性能（タイムアウト）へ進む |
| SUP 側ログで構成・同期が正常 | 致命的エラーなし | WSUS/IIS/証明書の深掘り、またはクライアント側の評価条件を再確認 |
まとめ：82492（0x1423C）は“通信・IIS の結果”から潰すのが最短
Software Center に更新が出てこない問題は、WSUS のチューニングより先に「WSUS Web サービスへ FQDN で到達できるか」と「IIS が何を返しているか」を押さえると、無駄打ちが激減します。疎通 → スキャン強制 → IIS ログ → クライアント/ SUP ログの順で切り分ければ、SUP/WSUS 側なのか、クライアント側なのか、展開条件なのかを論理的に特定できます。ログが揃えば、原因は必ず“どこで止まっているか”として見えるようになります。
コメント