SCCM（ConfigMgr）でWSUS（Software Update Point / SUP）を統合運用しているのに、Microsoft Update Catalogにはある「Office 365 Apps Update」系の更新プログラムだけがSCCM／WSUSに表示されない――そんなときに効く、原因の整理と具体的な復旧手順をまとめます。
この問題でよく見える症状
「更新がない」のではなく、同期のどこかで情報が欠けてしまい、結果としてコンソールに出てこないケースが多いです。まずは自分の状況が今回のパターンに当てはまるか確認しましょう。
| 症状 | 起きていること（見え方） | ポイント |
|---|---|---|
| Microsoft Update Catalogでは見つかる | KBやタイトル検索で更新が存在する | 「Microsoft側にない」ではなく、同期・取り込み側の問題の可能性が高い |
| 「Office 365」を含む更新は同期される | 一部のOffice 365関連更新はSCCM/WSUSに出る | 製品カテゴリ全体が死んでいるというより、特定タイプの更新だけ落ちている |
| 「Office 365 Apps Update～」で始まる更新が出ない | 狙ったビルド/チャネルの更新が見当たらない | Office CDN由来のメタデータ取得やカテゴリ登録の不整合を疑う |
| 手動インポート（手動取り込み）がエラーで失敗 | WSUSコンソールの「更新のインポート」で取り込めない | 根本は同期経路の問題で、手動インポートでの回避が難しい場合がある |
まず押さえる：SCCM＋WSUS（SUP）の同期は「2段階」
SCCM（ConfigMgr）でWSUSをSUPとして使う場合、更新がSCCMコンソールに出るまでには大きく2段階あります。どちらか一方が欠けると、CatalogにはあるのにSCCM/WSUSに見えない、という現象が起きます。
| 段階 | 担当 | 何をしているか | ここが壊れると起きること |
|---|---|---|---|
| ① WSUS同期（上流→WSUS） | WSUS | Microsoft Update から更新メタデータを取得し、WSUSのカタログに反映 | WSUSコンソールでも更新が見えない／インポートが失敗する |
| ② SUP同期（WSUS→SCCM） | SCCM | WSUSに取り込まれた更新メタデータをSCCMデータベースへ取り込み、検索・ADR・展開の対象にする | WSUSにはあるのにSCCMに出ない／ADRで検出されない |
今回の「Office 365 Apps Update～」だけ欠けるケースは、O365関連のカテゴリ登録やメタデータ取得が中途半端になり、WSUS側に必要情報が入っていないか、入っているのにSCCMが正しく参照できていない、のどちらかであることが多いです。
「Office 365」と「Office 365 Apps Update」で挙動が分かれる理由
見た目としてはどちらも「Office 365 Client」系に見えても、更新の作られ方や配布経路が違うことがあります。特に「Office 365 Apps Update～」は、いわゆるMicrosoft 365 Apps（旧Office 365 ProPlus）クライアントのビルド/チャネル更新に紐づくことが多く、同期処理の中で追加のカタログ（.cab）参照が発生しやすいのが特徴です。
- カテゴリ登録の不整合：SUPの製品選択（Office 365 Client）を過去に変更した、SCCMのO365関連機能を有効/無効に切り替えた等のタイミングで、カテゴリ購読情報が不整合になり「特定タイプだけ」抜けることがある
- プロキシ/Firewallの影響：Microsoft Updateには到達できても、Office CDN（officecdn.microsoft.com）に到達できず、O365 Apps更新のカタログ取得が失敗して欠ける
- WSUSのメタデータ劣化：WSUSの同期が長期運用で不安定になり、エラー復旧後に一部カテゴリだけ取り込みが欠けた状態で止まる
そのため、まずは「O365関連の設定をいったん無効化→再有効化して、カテゴリ購読をリフレッシュする」のが短距離で効くことがあります。実際に解消した手順を、再現しやすい形で整理します。
解決手順：O365関連設定をOFF→ONしてからWSUSコンソールで同期する
ポイントは、「SCCM側のO365関連設定をトグルして、WSUS側のカタログ購読を正常化したうえで、WSUSコンソールから同期を回す」ことです。SCCM＋SUP統合環境では、製品/分類の変更はWSUSではなくSCCMで行うのが原則なので、設定変更はSCCM側に寄せます（WSUSコンソールは同期実行・状態確認に使うイメージです）。
事前に確認しておくこと（安全策）
| 項目 | 確認内容 | 理由 |
|---|---|---|
| 実施タイミング | 同期やメタデータ再取得で負荷が上がるため、業務影響の少ない時間帯に実施 | 同期が長引くとADRやパッチ作業に影響する |
| バックアップ/スナップショット | SUSDB、SCCMサイトDB（バックアップ方針に沿って） | 最悪のケースでWSUS/SUPの再構築判断がしやすくなる |
| 変更点の記録 | SUPの「製品」「分類」「言語」「上流」設定をスクショ/メモ | 切り戻しや比較が容易になる |
SCCM側：O365関連の設定をいったん無効化→再有効化する
「O365関連設定」と一口に言っても環境で差が出ます。まずはSUPが参照する範囲に直結する製品（Products）設定のトグルから行うのが安全です。
| やること | 操作例（コンソール上の場所） | 狙い | 注意点 |
|---|---|---|---|
| SUPの製品で「Office 365 Client」系をOFF→ON | SCCMコンソール → 管理 → サイト構成 → サーバーとサイト システムの役割 対象のSUPサーバー → Software Update Point → プロパティ → 製品 | カテゴリ購読情報を再登録し、欠けている更新メタデータを再取得しやすくする | OFFにした瞬間、一時的に該当更新がSCCM側で非表示/期限切れ扱いになることがある（再同期で戻る） |
| （該当環境のみ）O365関連の機能/コンポーネントをOFF→ON | SCCMコンソール → 管理 → 更新とサービス → 機能（名称はバージョンで差あり） | O365関連の内部状態（購読/設定/同期対象）をリフレッシュする | 機能のON/OFFに時間がかかることがあるため、ログで反映を確認しながら進める |
OFF→ONのコツは、ただチェックを戻すだけでなく、一度OK/適用して変更を確定させたうえで、再度ONにしてOKすることです。反映まで数分かかることがあるため、すぐに画面上の件数が変わらなくても慌てないでください。
WSUS側：WSUSコンソールから「今すぐ同期」を実行する（完全同期として扱う）
SCCMの「ソフトウェア更新の同期」だけを回しても、WSUS側で欠けているメタデータが補完されない限り、状況が変わらないことがあります。そこで、WSUSコンソールから同期を明示的に実行します。
- SUP/WSUSサーバーで WSUS管理コンソール を開く
- 「同期」関連の画面から 今すぐ同期（手動同期）を実行する
- 同期が完了するまで待つ（エラーが出る場合は後述のログ確認へ）
運用上「完全同期（フル同期）」と呼ぶ手順の実体は環境で少し差が出ますが、少なくとも設定変更直後にWSUS側の同期を1回完走させることが重要です。
SCCM側：ソフトウェア更新同期を実行して取り込みを完了させる
WSUS側の同期が終わったら、SCCM側でもSUP同期を走らせて、更新メタデータをSCCMに取り込みます。
- SCCMコンソール → 監視 → ソフトウェア更新ポイントの同期状態 から同期状況を確認
- 必要に応じて ソフトウェア更新の同期 を手動実行
- 完了後、ソフトウェア ライブラリ → ソフトウェア更新 → 「すべてのソフトウェア更新」で「Office 365 Apps Update」等のキーワード検索
| チェックポイント | 期待する状態 | 補足 |
|---|---|---|
| WSUSコンソール | 対象の更新が検索/表示できる | WSUSに出ない場合は、まずWSUS同期段階の問題として切り分け |
| SCCMコンソール | All Software Updates に「Office 365 Apps Update～」が出る | 表示までにタイムラグがあることがある（同期完了直後は少し待つ） |
| ADR/展開 | Office 365系のルールに引っかかる（必要なら） | ルール条件（製品/分類/タイトル/アーキテクチャ）も合わせて見直す |
手動インポートが失敗する場合の考え方
WSUSの「更新のインポート」は、従来からある回避策に見えても、SCCM＋SUP統合環境ではうまくいかないことがあります。今回のようにインポート自体がエラーで落ちる場合は、次の観点で整理すると無駄打ちを減らせます。
| 状況 | 起きがちな理由 | 現実的な対処 |
|---|---|---|
| WSUSコンソールからCatalogが開けない/取り込めない | ブラウザ要件、拡張機能、IEモード、制限された環境、プロキシ認証など | まずはWSUS同期を正常化し、インポートに頼らない |
| 取り込めたはずなのにSCCMに出ない | SCCM側の同期・取り込み（SUP同期）が完了していない、またはフィルタ条件に合っていない | SCCM同期ログを確認し、製品/分類/言語を見直す |
| 特定のOffice 365 Apps更新だけ失敗する | Office CDNへの到達性、SSLインスペクション、メタデータCAB取得失敗 | ネットワーク経路確認（officecdn.microsoft.com）を最優先で行う |
結論として、「手動インポートで何とかする」より「カテゴリ購読と同期経路を直す」ほうが再発率が低いです。運用が回り始めた後にまた同じ欠け方をしないよう、根本を潰しておくのがおすすめです。
まだ表示されないときの切り分け（優先度順）
OFF→ON＋再同期でも改善しない場合は、「WSUSが正しく取得できていない」のか「取得できているがSCCMが取り込めていない」のかを、短時間で切り分けます。
Office CDN（officecdn.microsoft.com）へ到達できるか確認する
Office 365 Apps系の更新は、同期中にOffice CDN配下のカタログ（.cab）を参照することがあります。WSUS/SUPサーバーから officecdn.microsoft.com:443 へ到達できないと、特定更新だけ欠ける原因になります。
| 確認方法 | コマンド例 | 見たいポイント |
|---|---|---|
| 名前解決 | nslookup officecdn.microsoft.com | DNSが引ける（社内DNS/プロキシ経由環境でも解決できる） |
| 疎通（443） | Test-NetConnection officecdn.microsoft.com -Port 443 | TcpTestSucceeded が True になる |
| HTTPS応答 | Invoke-WebRequest -Uri "https://officecdn.microsoft.com/" -Method Head | 200/301/302 など「応答が返る」ことが重要（認証要求や遮断は要注意） |
もし具体的な .cab のURLで落ちている疑いがある場合は、後述のログに出てくるURLをそのまま使って取得可否を確認すると、最短で原因にたどり着けます。
プロキシ/Firewall/SSLインスペクションの影響を疑う
「Microsoft Updateは通るのにOffice CDNだけ落ちる」構成は珍しくありません。特にSSLインスペクションがある環境では、証明書差し替えでCAB取得が失敗するケースもあります。
| チェック項目 | よくある落とし穴 | 対策の方向性 |
|---|---|---|
| プロキシ設定 | WSUSサービスと対話ログオンでプロキシ経路が違う | WSUSの「更新ソースとプロキシ」設定、サービスアカウントの経路を揃える |
| Firewall | 443は開いているが、特定ドメインだけ遮断 | officecdn.microsoft.com を明示的に許可（必要ならログから実URLで確認） |
| SSLインスペクション | 大容量/特殊ヘッダのダウンロードで途中切断、証明書検証失敗 | 更新取得系通信はインスペクション除外にする、または中間証明書を適切に配布 |
SUP/WSUSの設定を最低限に絞って見直す
Office 365系更新は数が多く、設定が過剰だと同期やクリーンアップが破綻しやすくなります。まずは「必要なものだけ」に絞れているかを見直します。
| 設定箇所 | 見るポイント | ありがちなミス |
|---|---|---|
| 製品（Products） | Office 365 Client（またはMicrosoft 365 Apps相当）が選択されている | 名称が似た別製品だけを選んでいる／過去に外して戻していない |
| 分類（Classifications） | Updates（更新プログラム）が含まれている | Security Updatesだけ選択していて、機能/ビルド更新が入らない |
| 言語 | クライアントの実運用言語に絞れている | 全言語を選んで同期が肥大化→処理失敗が起きやすい |
ログで「どこで欠けたか」を特定する
切り分けを早くするならログが一番確実です。SCCMとWSUSそれぞれで、見るべきログと観点をまとめます。
| ログ | 標準パス例 | 見どころ |
|---|---|---|
| wcm.log | C:\Program Files\Microsoft Configuration Manager\Logs | SUP設定変更（製品/分類/接続）の反映状況、WSUSへの接続成功/失敗 |
| wsyncmgr.log | C:\Program Files\Microsoft Configuration Manager\Logs | 同期の開始/完了、カテゴリ購読、エラーコード、同期対象の取得状況 |
| wsusctrl.log | C:\Program Files\Microsoft Configuration Manager\Logs | WSUSコンポーネントの状態監視、WSUS API呼び出しのエラー |
| SoftwareDistribution.log | C:\Program Files\Update Services\LogFiles | WSUS自身の同期エラー、上流への接続、メタデータ取得の失敗 |
ログ上で「officecdn.microsoft.com への接続失敗」や「CABダウンロード失敗」が見える場合は、ネットワーク側の問題に寄せて対応するのが近道です。逆にWSUS同期は成功しているのにSCCMに反映されない場合は、SUP同期（SCCM側）に原因が残っていることが多いです。
WSUSのメンテナンス（同期の土台を整える）
同期が不安定なWSUSは、直してもまた欠けやすいです。すぐに再構築できない場合は、最低限のメンテナンスを入れておくと安定します。
| 作業 | 目的 | 補足 |
|---|---|---|
| サーバー クリーンアップ | 不要な更新/ファイルを減らし、同期と検索の負荷を下げる | WSUSコンソールのクリーンアップウィザードで実施（時間がかかる場合あり） |
| DBメンテ（インデックス整備など） | SUSDBの性能低下を抑え、同期処理のタイムアウトを防ぐ | 実施可否は運用/ポリシーに合わせて判断 |
| 健全性チェック | WSUSの自己診断ログを出して異常を見つける | wsusutil.exe checkhealth 実行後、イベントログを確認 |
再発防止：Office 365 Apps更新を安定して同期する運用のコツ
直った後にまた欠けるのが一番つらいので、運用で効くポイントをまとめます。
- 製品/分類を必要最小限に：選びすぎはWSUSの肥大化と同期失敗の温床になります
- 同期の監視を仕組みに入れる：同期失敗を「気付いたとき」ではなく「失敗した時点」で検知できるようにする
- Office CDNの疎通は定期点検：プロキシ/FWポリシー変更で突然落ちることがある
- WSUSメンテナンスを定期化：クリーンアップやDBメンテを回し、同期が重くなりすぎない状態を保つ
| 運用項目 | おすすめ | 理由 |
|---|---|---|
| 言語 | 利用言語だけ（例：日本語＋英語など必要最小限） | メタデータ/コンテンツ量を抑え、同期失敗やクリーンアップ不全を防ぐ |
| 同期頻度 | 毎日1回＋必要時の手動同期 | Office系更新は公開サイクルが速く、週次だと見落としが起きやすい |
| ネットワーク | 更新取得系ドメインは許可/例外ルールを明確化 | セキュリティ機器のポリシー変更で突然欠ける事態を減らす |
| ADR条件 | タイトル条件だけに頼らず、製品/分類/アーキテクチャも併用 | 表記ゆれ（Office 365 / Microsoft 365 Apps）でも拾いやすくなる |
まとめ：ポイントは「O365設定のリフレッシュ」と「WSUS側の同期完走」
Microsoft Update Catalogにはあるのに、SCCM/WSUSに「Office 365 Apps Update～」だけ出ない場合、まずはSCCM側でO365関連設定をOFF→ONして状態をリフレッシュし、続いてWSUSコンソールから同期を完走させることで改善することがあります。
- OFF→ONは「製品（Office 365 Client）」「O365関連機能（該当環境のみ）」の順に試す
- WSUS/SUPサーバーから officecdn.microsoft.com へ到達できるかは重要な切り分けポイント
- 再発防止は「絞った設定」「同期監視」「WSUSメンテ」で効きます
コメント