ConfigMgrのSoftware Centerに更新が出ない場合は、同期・スキャン・展開・表示のどこで止まっているかを確認します。82492（0x1423C）という数値だけで、WSUSの通信障害と決めつけることはできません。どの画面・ログ・コンポーネントがそのコードを出したかと、前後のエラーメッセージを残してください。
まず整理する：全端末か、一部の更新か
| 起きていること | 先に確認する段階 |
|---|---|
| 管理コンソールにも対象更新がない | SUPの同期、製品・分類、同期結果 |
| 複数端末でスキャンが失敗する | 割り当てSUP、通信、証明書、WSUS/IIS |
| スキャンは成功するが更新が見えない | 適用対象、展開コレクション、利用可能日時、表示設定 |
| 特定端末だけ見えない | クライアントポリシーとスキャン結果 |
| 表示されるがダウンロードできない | コンテンツ配布とクライアントの取得経路 |
同じ更新KB、OSビルド、クライアント版、対象コレクションで、正常端末と失敗端末を比較します。すべての端末へ修復スクリプトを配る前に、代表1台の発生時刻を記録してログをそろえる方が調査しやすくなります。
82492（0x1423C）だけで原因を決めない
82492と0x1423Cは同じ数値の10進/16進表記ですが、そのことだけでWindows Updateの特定HRESULTを意味するわけではありません。ConfigMgrの状態メッセージ、上位のエラー、下位のWindows Updateエラーを混同しないでください。ログに別の0x800…等のコードがあれば、発生箇所と文脈を含めて調べます。
画面のスクリーンショットだけでなく、メッセージ本文、コンポーネント名、タイムスタンプ、対象更新、直前の処理を控えます。内部サーバー名やアカウント情報を外部公開する場合は除いてください。
クライアントが実際に参照するSUPを確認する
管理コンソールの想定だけでなく、クライアントのLocationServices.logやWUAHandler.logで参照先を確認します。GPOや共同管理で更新の設定元が競合していないか、現在のポリシー結果とも照合します。レジストリ値を手で書き換えて試す前に、設定を配っている管理元を特定してください。
WSUSのHTTP/HTTPSとポートは環境の設定に従います。8530/8531は一般的な構成例で、HTTPS運用をHTTPへ戻すことが復旧手順ではありません。サーバーのFQDN、証明書名、有効期限、信頼チェーン、クライアント時刻を確認します。
TCP疎通とHTTP応答の確認で分かること
PowerShellでの例です。ホストとポートは実際に設定された値へ置き換えます。これは読み取りの到達確認です。
Test-NetConnection -ComputerName sup01.example.com -Port 8531TcpTestSucceeded : True はTCP接続ができたことを示します。証明書検証、WSUS APIの動作、Windows Updateのスキャン成功までは証明しません。ブラウザーでSimpleAuthWebService等がHTTP 200になることも、クライアント全体の更新処理成功とは別です。
ブラウザーは利用者の認証・プロキシで動き、更新エージェントは別の実行条件になる場合があります。ブラウザーだけ成功する場合は、端末とサービスが実際に使うプロキシ・証明書・名前解決を確認してください。TLS検証やファイアウォールを全面無効化して差を埋めないでください。
スキャンを実行し、同じ時刻のログを読む
管理者の手順に従ってソフトウェア更新プログラムのスキャンサイクルを開始し、その時刻を控えます。連打せず、開始から完了/失敗までの1回分を追います。クライアントログの既定位置は通常 C:\Windows\CCM\Logs ですが、実際の環境を確認してください。
| ログ | 主に確認すること |
|---|---|
| ScanAgent.log | スキャンの要求・開始・完了 |
| WUAHandler.log | Windows Update Agentのスキャン処理と返ったエラー |
| UpdatesDeployment.log | 展開評価と実行条件 |
| UpdatesHandler.log | 更新のインストール処理 |
| LocationServices.log | 利用するサービス位置等の情報 |
端末のログが示す失敗時刻を基に、サーバー側のIISログでクライアントIP、URI、HTTPステータス、サブステータス、Win32ステータスを突き合わせます。UTCとローカル時刻の差にも注意してください。
SUP・サイトサーバー側の正しいログ名
| ログ | 用途 |
|---|---|
| WCM.log | SUPの構成や接続 |
| WSUSCtrl.log | WSUSの健全性・構成状態 |
| wsyncmgr.log | 更新メタデータの同期 |
SMS_WSUS_SYNC_MANAGERはコンポーネント名で、通常確認する同期ログはwsyncmgr.logです。旧記事のSMS_WSUS_SYNC_MANAGER.logという案内を訂正しました。ログの設置先はサイトのインストール場所と役割によるため、公式ログ一覧で確認してください。
IIS・WsusPoolを変更する前の確認
HTTP 503やアプリケーションプール停止があれば、イベントと資源使用量、停止理由を確認します。メモリー上限、キュー長、リサイクル設定等を、根拠なく一括変更しないでください。WSUSデータベースの規模、メンテナンス状態、サーバー資源を含めて判断し、変更前の値と戻し方を残します。
401/403は認証・アクセス、404は要求先や構成、500系はサーバー側処理などを調べる手掛かりですが、数字だけで単一原因を確定しません。サブステータスと対応するIISイベント、ConfigMgrログを併せて読みます。
スキャン成功後もSoftware Centerに出ない場合
- 対象更新が端末に必要と判定されるか、すでに適用済み/該当なしではないか。
- 正しいコレクションに展開され、端末が含まれるか。
- 利用可能日時、配布ポリシー、Software Centerの表示条件を満たすか。
- クライアントが新しいポリシーを受信しているか。
- 表示後のダウンロード失敗なら、別途コンテンツ配布と取得ログへ進む。
復旧判定は「WSUSのURLが開く」で終わらせず、スキャン成功、適用対象判定、展開評価、Software Center表示まで対象の更新と端末を固定して確認します。インストールまで行う場合は業務の変更手順に従います。
公式資料と問い合わせ用の記録
Microsoftのソフトウェア更新管理トラブルシューティングは、同期・スキャン・検出を分けて調べる資料です。相談時は、ConfigMgr/OSの版、影響範囲、SUPのFQDN/方式、対象KB、再現時刻、該当ログと実施済み変更をそろえると、調査の重複を減らせます。
コメント