SCCM（ConfigMgr）のSUP同期が「Successful」なのに新しい更新プログラムが入ってこない…WSUSコンソールでは同期がCanceled。こうした食い違いはCAS環境で特に厄介です。本記事では、実際に解決したSite Reset手順と、切り分けに効く確認ポイントをまとめます。
症状の整理：SCCM（ConfigMgr）SUPの同期は成功でも、更新が増えない
Software Update Point（SUP）を構成しているのに、月次（9月・10月など）の更新プログラムがSCCMコンソールに出てこないケースがあります。同期を手動で実行しても結果は「Successful」。しかし更新数が増えず、WSUSコンソール側では同期結果が「Canceled」扱いになっている――この状態は「SCCM側は正常に見えるのに、実体はWSUS側で同期が完了していない」パターンの典型です。
| 見えている現象 | どこで確認できるか | 読み替え・注意点 |
|---|---|---|
| 同期結果がSuccessful | SCCMコンソール（ソフトウェア更新の同期ステータス） | 「同期処理が最後まで走った」ことを示す場合があり、WSUS側で実データが増えていないことがあります |
| 新しい更新が0件のまま | All Software Updates（リリース日でフィルタ） | 製品/分類のズレ、WSUS同期の中断、メタデータ破損などで起きます |
| WSUS側がCanceled | WSUSコンソールのSynchronization結果 | 手動キャンセルしていなくても、タイムアウトやサービス再起動等で「結果だけCanceled」になることがあります |
最初の確認：SCCMコンソールで「更新が入っていない」を正確に判定する
同期障害は、まず“どこまで正常か”をはっきりさせると一気に早くなります。特に「同期は成功」と「更新が増えた」は別物なので、コンソール上で次の2点をセットで確認します。
| 確認したいこと | コンソール上の場所（例） | 見るポイント |
|---|---|---|
| 同期がいつ走ったか | Monitoring → Software Updates → Synchronization Status | 最終同期時刻が更新されているか、失敗/警告が出ていないか |
| 更新が実際に増えたか | Software Library → Software Updates → All Software Updates | 「Date Released（リリース日）」で絞り込み、該当月の更新が追加されたか |
| コンポーネント状態 | Monitoring → System Status → Component Status | SMS_WSUS_SYNC_MANAGER / SMS_WSUS_CONFIGURATION_MANAGER の警告やエラー |
All Software Updatesでは、検索キーワード（例：KB番号、製品名、”Cumulative Update”）よりも、まずリリース日で期間を区切る方が確実です。月次更新がごっそり抜けている場合、製品/分類の漏れよりも、WSUS側で同期が止まっている可能性が高くなります。
まず押さえる：CAS＋SUPにおける同期の流れと「Successful」の落とし穴
CAS（Central Administration Site）を持つ階層では、基本的にトップであるCASがWSUS（SUP）と同期し、取り込んだ更新メタデータが下位サイトへ展開されます。つまりCASで更新が増えないと、下位のプライマリサイト側でも更新が見えません。
同期処理は大まかに次の流れです。
- WSUSが上流（Microsoft Update または上流WSUS）と同期し、更新メタデータをWSUSのSUSDBへ取り込みます
- ConfigMgrの同期コンポーネント（SMS_WSUS_SYNC_MANAGERなど）がWSUS API経由でメタデータを読み取り、ConfigMgrデータベースへインポートします
- CASの場合は、そのメタデータがレプリケーションで下位サイトへ伝播します
ここで厄介なのが、WSUS側の同期が「Canceled」や途中停止でも、ConfigMgr側の同期処理自体は“前回までのメタデータ”を前提に最後まで走り切り、結果表示だけSuccessfulになるケースがある点です。見た目だけで判断せず、「更新件数が増えたか」「該当月の更新が入ってきたか」を必ず併せて確認します。
WSUS側でSynchronizationがCanceledになる代表例
「キャンセルした覚えがないのにCanceled」は珍しくありません。特にConfigMgr配下のWSUSは、同期中のIIS/サービス挙動やDB状態の影響を受けやすく、結果だけCanceledとして残ることがあります。
| 原因候補 | よくある兆候 | 確認ポイント |
|---|---|---|
| IISアプリプール（WsusPool）のリサイクル/停止 | 同期が途中で止まり、WSUS側がCanceledになる | IISログ、イベントログ、WsusPoolのPrivate Memory Limitや定期リサイクル設定 |
| WSUSサービスの再起動・サーバー再起動 | 同期時間が不自然に短い/直後にCanceled | Windowsイベントログ（System）、WSUS関連イベント |
| WSUS DB（SUSDB）の断片化/肥大化/タイムアウト | 同期が長時間化→失敗、または途中で中断 | WSUSイベント、SQL/WIDの負荷、メンテナンス有無 |
| プロキシやTLS、ネットワーク制限 | 特定タイミングから急に新規更新が入らない | Proxy設定、TLS 1.2、上流への疎通、ファイアウォール |
| WSUSコンソールからの操作で状態が不整合 | 承認/拒否、同期ボタン、設定変更後から挙動が崩れる | ConfigMgr側のSUP設定と競合していないか（基本は操作を避ける） |
最終的に解決した対処：CASに対してSite Reset（サイトのリセット/修復）を実行
この症状で有効だったのが、CASでのSite Reset（サイトのリセット/修復）です。ConfigMgrのセットアップウィザードから「サイトのメンテナンスまたはリセット」を実行することで、サイトコンポーネントや役割の登録/設定が再構成され、以後の同期で新しい更新プログラムが取り込まれるようになりました。
なぜSite Resetが効くことがあるのか
SUP同期は、WSUSだけでなくConfigMgr側の複数コンポーネント（WSUS構成、同期マネージャー、SQL接続、証明書/ポート設定など）が連鎖して成り立っています。どこかが“壊れてはいないが整合しない”状態になると、エラーが目立たないまま同期が空振りすることがあります。Site Resetは、こうしたサイト側コンポーネントの登録・構成・サービスの状態をまとめて修復するため、結果としてWSUSとの連携が復活するケースがあります。
実施前に押さえるポイント
- Site Resetは“再インストール”ではありませんが、サイトコンポーネントの修復やサービス再起動を伴うため、業務影響が出ない時間帯で実施します
- CASがトップのため、実施中は階層全体の管理機能に影響する可能性があります
- 同時に大きな変更（SUP設定変更、WSUS側設定変更、IISチューニング等）を入れると原因切り分けが難しくなるため、まずは単独で実施するのが安全です
| チェック項目 | 目的 | 目安 |
|---|---|---|
| ConfigMgr/WSUSのログ保存 | 事前・事後で差分比較できるようにする | 最低でも wsyncmgr.log / WSUSCtrl.log / WCM.log |
| 同期スケジュールの把握 | 自動同期とぶつからないようにする | Site Reset中は手動同期は避ける |
| 空き容量・DB状態 | 修復中の失敗/遅延を避ける | SUSDB/ConfigMgr DBの空き容量・I/Oを確認 |
| CASサーバーの再起動予定 | 必要時にすぐ切り戻せるようにする | 実施後に再起動が必要になることもあるため、再起動可能な時間帯で行う |
Site Resetの実施手順（概要）
- CASサーバーでConfiguration Manager Setup Wizard（セットアップウィザード）を起動します（管理者権限）
- メニューで「Perform site maintenance or reset this site（サイトのメンテナンスまたはリセット）」を選択します
- 画面の指示に従って最後まで進め、完了させます（基本は既定のまま進めます）
- 完了後、SCCMコンソールでソフトウェア更新の同期を再実行します
- All Software Updatesで該当月（9月・10月など）の更新が追加されることを確認します
Site Reset後に必ずやる確認（“成功したかどうか”を数字で見る）
「同期が成功」と表示されても、更新が増えていないなら問題は解決していません。Site Reset後は、次の観点で“増えたこと”を確認します。
| 確認項目 | 具体的な確認方法 | 期待する結果 |
|---|---|---|
| 更新件数が増えたか | All Software Updatesでリリース日をフィルタ（例：9月/10月の期間） | 新規の更新が追加され、件数が増える |
| 同期ログにエラーがないか | wsyncmgr.log / WSUSCtrl.log / WCM.log を確認 | 致命的エラーがなく、処理が最後まで進む |
| WSUS側の結果がCanceledから変わるか | WSUSコンソールは“参照のみ”で同期結果を確認 | 少なくとも同一タイミングでCanceledが続かない |
| 下位サイトへの反映 | CAS配下のプライマリでも同じ期間で検索 | CASで増えた更新が下位でも見える（反映まで時間がかかることあり） |
切り分けに効く：まず見るべきConfigMgrログ（wsyncmgr / WSUSCtrl / WCM）
同期が増えない問題は、ログを見るだけで原因が一気に絞れることが多いです。ログは基本的にサイトサーバー上の <ConfigMgrインストールフォルダ>\Logs にあります（環境によりパスは異なります）。
| ログ | 役割 | 見るべきポイント | 検索するとよいキーワード例 |
|---|---|---|---|
| wsyncmgr.log | ソフトウェア更新の同期全体（インポート処理） | 同期開始/終了、取り込んだ更新数、例外の有無 | Sync, Import, Error, Exception, Successfully completed |
| WSUSCtrl.log | WSUSの接続性/ヘルスチェック | WSUSへの接続、ポート、API呼び出し失敗、WSUSの状態 | HTTP, SSL, 8530, 8531, Connection, Failed |
| WCM.log | SUP設定の適用/構成管理 | 製品/分類/言語などの設定適用、WSUS側構成の更新 | Setting, Products, Classifications, Proxy, Apply |
wsyncmgr.logの読み方（“Successful”でもここを見る）
wsyncmgr.logは、同期が「成功」と見えても“実際に何を処理したか”が残ります。最低でも次の3つを追うと、空振りかどうかが判定しやすくなります。
- 同期開始〜終了の流れ：開始してすぐ終わっていないか（異常に短い場合は実処理が進んでいない可能性）
- 処理件数：新規/更新のメタデータを何件処理したか。0が続くならWSUS側が増えていない、または読み取れない
- 例外・タイムアウト：通信エラーやAPI例外が出ていないか
ログは環境差がありますが、目視のコツは「成功」の行を探すより、その直前にエラーや警告が出ていないかを追うことです。
WSUSCtrl.log / WCM.logでよく見るパターン
| よくある状況 | ログで起きやすいこと | 次の一手 |
|---|---|---|
| WSUSに接続できない | WSUS API呼び出し失敗、接続エラー | ポート/SSL/名前解決、IIS、WSUSサービスを確認 |
| 設定が適用されていない | 製品/分類の適用が繰り返し失敗 | SUP設定を見直し、適用の完了ログが出るか確認 |
| 同期が進んでいない | 同期開始は出るがインポートが進まない | WSUS側の同期状態（Canceled/失敗）とイベントログを突き合わせる |
SUP設定の再確認：Products/Classificationsのズレは最初に潰す
同期以前に、単純にSUPの対象がズレていると、更新は増えません。特に「最近まで取れていたのに、特定の月から取れない」場合でも、製品追加や運用変更で設定がズレていた、ということがあります。
確認場所の一例（環境により表示が異なる場合があります）。
- SCCMコンソール：Administration → Site Configuration → Sites →（対象サイト）→ Configure Site Components → Software Update Point
| 設定項目 | よくある落とし穴 | 確認のコツ |
|---|---|---|
| Products（製品） | OS/Office/SQL/Defenderなど、必要な製品が外れている | 「最近導入した製品」ほど漏れやすい。変更履歴があれば突き合わせる |
| Classifications（分類） | Security UpdatesやCritical Updatesだけ選び、Update Rollups等が漏れる | 運用方針に合わせつつ、月次パッチで必要な分類が入っているか確認 |
| Languages（言語） | 言語を絞りすぎて必要分が欠ける | 更新が見えない時は一時的に範囲を広げて影響を確認する |
| 同期スケジュール | 自動同期が無効/間隔が長い/時刻が競合 | 手動同期の結果だけでなく、定期実行が継続しているかを見る |
WSUS側の確認ポイント：イベントログで“Canceledの理由”を拾う
ConfigMgr配下のWSUSは、極力ConfigMgr側で管理し、WSUSコンソールからの「承認/拒否」「製品/分類の変更」「手動同期」などの操作は避けるのが基本です。一方で、状態の参照やイベントログの確認は切り分けに有効です。
- Event Viewer（イベントビューアー）で、Application/Systemログに加えて、WSUS関連のログ（例：Windows Server Update Services ソース）を確認します
- 同期がCanceledになる直前の時間帯に、IISやWSUSサービス、DB接続エラー、タイムアウトなどのイベントが出ていないかを追います
- 「Canceled」の直前にサーバー再起動やIISリサイクルが走っている場合、同期が未完了でも結果だけ残ることがあります
CAS階層ならではの注意：CASで直っても下位サイトに反映しないとき
Site Reset後にCAS側へ更新が入っても、下位サイトで見えない場合は、同期そのものではなくレプリケーションの問題が疑われます。今回の症状とは別ですが、確認観点として知っておくと便利です。
| 状況 | 疑うポイント | 確認の方向性 |
|---|---|---|
| CASでは更新が見えるが、プライマリでは見えない | サイト間レプリケーション遅延/エラー | Replication Link Analyzer、該当リンクの状態、関連ログのエラー |
| 一部の更新だけ欠ける | 同期途中で止まった、または分類/言語の差 | CAS/プライマリでSUP設定が一致しているか（通常はCASで統一） |
それでも直らない場合の追加チェック（“Site Reset前”にも使える）
今回のようにSite Resetで改善するケースもありますが、同様の症状で別原因のこともあります。以下は追加で効くことが多い確認観点です。
| 追加チェック | 狙い | 具体例 |
|---|---|---|
| SUPの接続設定（ポート/SSL） | WSUSへの接続不全を除外 | 8530/8531（既定）を利用しているか、SSL構成の整合性 |
| プロキシ設定 | 上流同期が裏で失敗していないか | WCM.logにProxy適用が出ているか、認証が必要な環境か |
| IIS（WsusPool）の健全性 | 同期中断の原因を潰す | アプリプールの停止/リサイクル、メモリ制限、キュー長 |
| WSUS DBメンテナンス | 長時間化/タイムアウトを防ぐ | SUSDBの定期的なインデックスメンテ、不要メタデータの整理 |
| ConfigMgrコンポーネント状態 | サイト側の異常検知 | Monitoring → System Status → Component StatusでSMS_WSUS_*系の状態 |
再発防止：同期が“成功に見える”状態を監視で捕まえる
今回のような「Successfulなのに増えない」は、運用監視がないと気づくのが遅れがちです。おすすめは、成功/失敗だけでなく“増分”を監視することです。
- 月次パッチ日以降に、All Software Updatesの最新リリース日が更新されているかを定期確認する
- wsyncmgr.logで新規更新の処理件数が極端に少ない/0が続く場合に調査する
- Component StatusでSMS_WSUS_SYNC_MANAGER/SMS_WSUS_CONFIGURATION_MANAGERに警告が出ていないかを見る
- WSUS側の同期結果がCanceled/失敗を繰り返す場合は、IIS/DB/通信のどこかに継続的なボトルネックがあると判断して、先に土台を整える
まとめ：最短で復旧するための実践手順
「SCCM（ConfigMgr）のSUP同期はSuccessfulなのに更新が入ってこない」「WSUS側はCanceled」という症状では、次の順で進めると遠回りしにくくなります。
- SUPのProducts/Classifications/言語/スケジュールを再確認し、設定ズレを先に潰す
- wsyncmgr.log / WSUSCtrl.log / WCM.logで、WSUS接続・同期処理のどこで止まっているかを掴む
- WSUSイベントログで、Canceled相当の原因（IIS/サービス/DB/通信）を拾う
- 根本原因が掴めない、または修復が必要な状態が疑われる場合は、CASでSite Reset（サイトのリセット/修復）を実施する
- 最後に「同期成功」ではなく、新規更新が増えたことを確認してクローズする
コメント