在宅勤務が増え、VPN 帯域が逼迫すると「VPN 接続中は SCCM（ConfigMgr）の DP/WSUS 経由で更新を当てたい。でも VPN なしのときは自宅回線で Windows Update から落としてほしい」という要望が出ます。本記事では、その自動切り替えが成立する条件と、CMG や WUfB を使った現実的な設計を具体的に解説します。
要件を「通信経路」と「更新ソース」に分解して考える
まず混乱しやすいのが、SCCM（Microsoft Endpoint Configuration Manager / ConfigMgr）のソフトウェア更新は、単に「どこからダウンロードするか」だけでなく、誰が更新の要否を判断し、どのポリシーで実行させるかまで含めて設計する必要がある点です。更新を当てるまでの道のりを、次の 2 つに分けて整理すると見通しが良くなります。
- 判断（スキャン）と指示：管理ポイント（MP）やソフトウェア更新ポイント（SUP/WSUS）と通信して、どの更新をいつ適用するかを確定する
- コンテンツ取得：更新ファイル（CAB/MSU/ESD など）を DP か Microsoft Update（Windows Update）からダウンロードする
「VPN 接続時は DP、VPN なし／DP 不達時は Windows Update」という要望は、このうちコンテンツ取得の経路を状況に応じて変えたい、という話です。しかし判断フェーズが成立しないと、コンテンツ取得の切り替え以前に更新が動きません。
| 利用シーン | 狙い | 必要になる前提 |
|---|---|---|
| VPN 接続中（社内ネットワーク到達） | 社内 DP（境界グループ）から高速に配布 | 端末が VPN の IP 範囲で境界に一致し、MP/SUP/DP に到達できる |
| VPN なし（自宅回線） | Microsoft Update から直接ダウンロードして VPN 帯域を消費しない | 端末がインターネット経由で MP/SUP 相当の経路（例：CMG）に到達できる、または管理主体を WUfB に切り替える |
| VPN はあるが DP 不達（境界ミス・閉塞・障害） | 更新だけは止めずに Microsoft Update へフォールバック | 少なくとも MP には到達し、かつ展開側で「DP に無ければ Microsoft Update」設定が有効 |
仕組みを理解する：MP / SUP / DP と境界グループの役割
「WSUS（SUP）が更新を配る」「DP が更新を配る」とひとまとめに言われがちですが、実際は役割が分かれています。SCCM の更新設計で詰まりやすいポイントなので、最初に整理します。
| コンポーネント | 主な役割 | VPN 外で到達できないと起きること |
|---|---|---|
| 管理ポイント（MP） | クライアントへ展開ポリシーを配布し、コンテンツの場所（どの DP を使うか）も案内する | 更新の指示そのものを受け取れず、SCCM 管理として更新が進まない |
| ソフトウェア更新ポイント（SUP / WSUS） | 更新メタデータの同期・クライアントのスキャン（要否判定）先になる | スキャンが失敗し、SCCM の「必要/不要」評価ができない |
| 配布ポイント（DP） | 更新ファイルを保管し、境界グループに応じてクライアントがダウンロードする | コンテンツを取りに行けず、展開設定次第で失敗または別ソースへフォールバック |
| 境界/境界グループ | 「この IP の端末はどのサイト/DP/SUP を使うか」を決めるルール | 誤判定により想定外の DP/SUP を参照したり、フォールバック待ちが長引く |
| Microsoft Update（Windows Update） | Microsoft が提供する更新コンテンツ配信元。ConfigMgr 管理でも“コンテンツ取得先”として利用可能 | MP/SUP が届かない場合は、そもそも ConfigMgr の更新フローが始まらない |
特に重要なのが、更新の「要否判定（スキャン）」と「配布（コンテンツ取得）」は別経路という点です。展開（ADR でも手動でも）を作成すると、クライアントはまずポリシーを受け取り、その後に更新コンテンツを DP などから取得してインストールします。
結論：追加の仕組みなしに「VPN 時は SCCM、VPN 外は Windows Update へ自動フォールバック」は成立しない
「VPN 外では MP/SUP に届かない」状態だと、SCCM が更新対象を決められず、“DP が無いから Windows Update に行く”という分岐まで辿り着きません。フォールバック設定はあくまでコンテンツ取得の逃げ道で、判断フェーズ（MP/SUP）を省略する仕組みではないためです。
一方で、CMG（Cloud Management Gateway）などを追加して VPN 外でも MP/SUP に到達できる状態を作れるなら、同じ展開のままでも「VPN（社内）では DP」「VPN 外（インターネット）では Microsoft Update」という挙動に寄せられます。ソフトウェア更新ポイントは CMG 経由の通信を受け付ける設定が可能です。
よくある誤解：クライアント設定「クライアントでソフトウェア更新を有効にする」を No にすべき？
結論から言うと、この設定を No（無効）にすると目的と逆です。名前の通り、ConfigMgr クライアントのソフトウェア更新機能を止めます。無効化すると、クライアントは既存の展開ポリシーを取り除き、ソフトウェア更新に依存するコンプライアンスも機能しなくなります。
では、なぜ「No にすると Windows Update に切り替わる」という話が出回るのでしょうか。実務では次のような“見かけ上の現象”が起きるためです。
- ConfigMgr が WSUS 指定（ローカルポリシー）を外すことで、端末が別途設定されている Windows Update の方針（自動更新、WUfB ポリシーなど）に従い始める
- 結果として「SCCM が届かないときは Windows Update が動いた」ように見えるが、実際はSCCM 管理を捨てて OS 標準の更新に戻しただけ
要件が「SCCM 管理を維持しつつ、コンテンツだけインターネットに逃がす」なのであれば、この設定は Yes のままで設計するのが基本です。
ADR の「DP（境界グループ）に更新がない場合は Microsoft Update からダウンロード」は効く？
この設定は有効です。ただし効くのは“更新コンテンツをどこから取るか”の段階であり、クライアントが MP からコンテンツ場所の案内を受けられること、そしてSUP/WSUS でスキャンできることが前提です。
Microsoft Learn の展開手順でも、更新展開の「ダウンロード設定」で「DP に無い場合は Microsoft Update からダウンロード」を選べること、またインターネット（Internet-based）クライアントはソフトウェア更新コンテンツを Microsoft Update から取得する旨が説明されています。
つまり、VPN 外の端末に対してこの設定を“効かせる”には、VPN 外でも以下が成立している必要があります。
- クライアントが CMG など経由で MP に到達し、展開ポリシーを受け取れる
- クライアントが SUP（WSUS）に到達し、更新の要否判定（スキャン）ができる
- その上で、DP が使えない状況なら Microsoft Update からコンテンツを取得する
逆に言うと、VPN 外で MP/SUP に一切届かない環境では、ADR 側の「Microsoft Update からダウンロード」は“設定してあっても動きようがない”というのが実態です。
更新が「どこで止まるか」を可視化する：クライアント側の処理フロー
SCCM の更新が想定どおりにフォールバックしないとき、原因は「DP が無い」のではなく、その前段のポリシー取得やスキャンが止まっていることがよくあります。更新展開の基本フローは次のとおりです。
| ステップ | クライアントの動き | 主な通信先 | よく見るログ |
|---|---|---|---|
| ポリシー受信 | どの更新をいつ適用するかの展開ポリシーを受け取る | MP | PolicyAgent.log / PolicyEvaluator.log |
| スキャン（要否判定） | 対象更新が必要かどうかを評価する | SUP（WSUS） | WUAHandler.log / UpdatesHandler.log |
| コンテンツ場所の解決 | どの DP/ソースから落とすかを決める | MP（場所情報） | LocationServices.log / CAS.log |
| ダウンロード | DP から、または設定に従い Microsoft Update から取得する | DP / Microsoft Update | ContentTransferManager.log / DataTransferService.log |
| インストール | 更新を適用し再起動を制御する | ローカル | UpdatesDeployment.log / RebootCoordinator.log |
| 状態送信 | 成功/失敗などの状態メッセージを送る | MP | StateMessage.log |
Microsoft のトラブルシューティング資料でも、更新がダウンロードできないときは CAS.log / ContentTransferManager.log / DataTransferService.log などを確認すること、境界グループやコンテンツ配置が影響することが示されています。
この流れを踏まえると、あなたの要件は次のように読み替えられます。
- VPN 接続中：「スキャンやポリシーは社内で成立」＋「コンテンツは VPN 内の DP から」
- VPN なし：「スキャンやポリシーがインターネット経由で成立」＋「コンテンツは Microsoft Update から」
したがって「VPN なしでもスキャン/ポリシーが成立する仕組み」を用意することが、設計上の最優先事項になります。
実現パターン：CMG を追加して「管理は SCCM、コンテンツは状況で切り替え」を成立させる
「追加の仕組みなしでは難しい」という結論の“追加の仕組み”として、現場で最も採用されやすいのが CMG（Cloud Management Gateway） です。CMG を使うと、VPN 外のクライアントでもインターネット経由で ConfigMgr に接続でき、管理ポイント（MP）やソフトウェア更新ポイント（SUP）への通信を成立させられます。
設計の考え方
- VPN 接続時：境界グループで社内 DP を案内し、更新コンテンツは DP から取得
- VPN なし：クライアントはインターネット側として CMG に接続し、更新コンテンツは Microsoft Update へ（Internet-based クライアントは Microsoft Update から取得する挙動に沿わせる）
- DP 不達時：展開のダウンロード設定で「DP に無ければ Microsoft Update」を有効化し、更新を止めない
押さえるべき設定ポイント
| 観点 | 設定ポイント | ねらい | 注意点 |
|---|---|---|---|
| CMG 経由の通信 | MP と SUP を「CMG トラフィックを許可」にする | VPN 外でもポリシー配布とスキャンを成立させる | 役割側の設定が不足すると「VPN 外は何も起きない」状態になる |
| コンテンツ取得 | 更新展開（ADR/手動）のダウンロード設定で「DP に無い場合は Microsoft Update」 | DP 不達時にフォールバックさせる | 前提として MP から場所情報を受け取れる必要がある |
| 境界設計 | VPN の IP 範囲を境界に登録し、VPN 時に社内 DP が選ばれるようにする | VPN 接続時は DP に寄せる | 境界漏れがあると「VPN なのに Internet 扱い」など想定外が起きる |
| 通信の最適化 | 必要に応じてメータード接続の扱い、DO（Delivery Optimization）等を併用 | 家庭回線でも更新が詰まらないようにする | ユーザー体験（業務時間帯・再起動）とのトレードオフがある |
CMG セットアップ手順では、クライアント向けロールとして管理ポイントとソフトウェア更新ポイントを CMG トラフィックに対応させることが明示されています。また、ソフトウェア更新ポイント側にも「CMG を経由したクライアント通信を許可する」設定が用意されています。
手順イメージ（運用に落とし込むための実務ステップ）
- 現状把握：VPN 接続時に参照すべき DP/SUP を棚卸しし、VPN の IP 範囲（境界）を確定する
- CMG 導入：CMG を構築し、VPN 外クライアントが MP に到達できる状態を作る（クライアント設定で CMG 利用を許可する）
- SUP の CMG 対応：SUP のプロパティで CMG トラフィックを許可し、VPN 外でもスキャンできるようにする
- 更新展開の整理：在宅端末でも適用すべき ADR/展開について、ダウンロード設定で「DP に無ければ Microsoft Update」を有効化する
- 検証：VPN 接続/未接続で、同一端末が「VPN 時は DP」「VPN 外は Microsoft Update」になっているか、ログと実測で確認する
ポイントは「CMG で管理経路を担保し、コンテンツだけを Microsoft Update に逃がす」ことです。この設計なら、SCCM のコンプライアンス可視化や展開制御を維持しつつ、在宅時の VPN 帯域を抑えられます。
もう一つの現実解：Windows Update for Business（WUfB）/ Intune に更新を寄せる
VPN 外で MP/SUP に到達させる設計が難しい、または将来的にモバイルワークが中心になる場合は、Windows Update for Business（WUfB）を主軸にするのも現実的です。ConfigMgr と Intune の共同管理（コー・マネージメント）を使えば、端末グループごとに「Windows 更新は Intune/WUfB」「アプリ配布は SCCM」など役割分担もしやすくなります。
| 比較観点 | CMG + ConfigMgr 更新 | WUfB/Intune 主軸 |
|---|---|---|
| 更新コンテンツの取得先 | VPN 内は DP、VPN 外は Microsoft Update に寄せられる | 基本的に常に Microsoft Update（CDN） |
| 制御粒度 | 更新グループ/展開で細かく制御しやすい | リング（延期/期限）中心。細かい KB 単位の制御は思想が違う |
| インフラ要件 | CMG、証明書、運用監視が必要 | Intune/Entra ID 側の運用が中心 |
| VPN 依存 | 低い（ただし MP/SUP の到達性は確保する） | ほぼ不要 |
| 向いている組織 | SCCM を中心に管理し続けたい、既存運用を活かしたい | クラウド前提で運用を寄せたい、端末が社外に常駐する |
どちらが正解かは「現状の運用成熟度」「Azure/Intune の採用方針」「在宅比率」「セキュリティ要件」で変わります。重要なのは、VPN 外の端末に“誰が更新の指示を出すのか”を先に決めることです。
「外部公開 WSUS を立てれば解決？」がハマりやすい理由
「VPN 外で WSUS が見えないなら、WSUS をインターネット公開すればよいのでは？」という発想はよく出ます。しかし ConfigMgr のソフトウェア更新は、WSUS を単体で使う運用と完全には同一ではありません。
- ConfigMgr 統合の WSUS（SUP）は、更新カタログの同期・スキャン先としての役割が中心で、展開ポリシーの配布やコンテンツ場所の案内は MP/境界グループの世界観に依存します。
- WSUS/IIS を外部公開すること自体がセキュリティ/運用負荷（証明書、WAF、脆弱性対応、公開範囲の最小化）を伴い、CMG という選択肢がある現在では慎重に比較すべきです。
結果として「外部公開 WSUS だけ建てても、MP や境界周りが未整理で詰まる」ケースが多く、短期的に見えて長期的には負債になりがちです。
設定の指針：この要件で触るべき場所・触らない方がよい場所
| カテゴリ | 項目 | 推奨 | 理由 |
|---|---|---|---|
| クライアント設定 | クライアントでソフトウェア更新を有効にする | Yes | 無効化すると更新機能自体が止まり、展開ポリシーも外れるため |
| 更新展開（ADR/手動） | DP に無い場合は Microsoft Update からダウンロード | 要件に応じて Yes | DP 不達時のフォールバックとして機能（ただし MP/SUP 到達が前提） |
| 境界グループ | VPN の境界（IP 範囲）と DP の関連付け | 必須 | VPN 時に社内 DP を選ばせるため |
| 境界グループ | クラウド優先（Prefer cloud-based sources） | 慎重に | VPN 接続中でも Microsoft Update を優先させたい場合は有効だが、要件と逆になることがある |
| サーバー側 | SUP を CMG トラフィック許可 | CMG 採用時は必須 | VPN 外クライアントのスキャン経路を確保するため |
運用での落とし穴
- 機能更新（Feature Update）が混ざる：「Microsoft Update からダウンロード」を有効にすると、対象に入っている更新はインターネットから取得できます。ADR のフィルタや製品分類が甘いと、想定外に機能更新が落ちてくる事故が起きやすいので、品質更新（Quality Update）と機能更新はリング/コレクションを分けて管理します。
- 第三者（サードパーティ）更新は別物：第三者更新は WSUS へ公開したコンテンツを展開パッケージ化して配布する流れが基本で、Microsoft Update から直接取れるとは限りません。第三者更新を在宅でも適用したいなら、クラウド DP など“配布できる場所”を別途用意する設計が必要になります。
- VPN 装置の「強制トンネル」設定：VPN がフルトンネルだと、たとえ Microsoft Update からのダウンロードでも VPN を通ってしまい帯域節約になりません。ネットワーク側（スプリットトンネルやプロキシ）との整合を確認します。
- 境界の取りこぼし：VPN の IP プール変更、拠点追加、IPv6 などで境界が合わなくなると、DP 選定や SUP 選定が崩れて挙動が不安定になります。
切り分けチェックリスト（まずここを見る）
| 確認項目 | 見るべきポイント | 典型的な対処 |
|---|---|---|
| VPN 外で Software Center に更新が出ない | ポリシー受信ができているか（MP 到達） | CMG/IBCM の導入、証明書/名前解決/ファイアウォールの見直し |
| VPN 外でスキャンが失敗する | SUP への到達と設定（CMG トラフィック許可） | SUP の「CMG を許可」を有効化し、関連ロールを CMG 対応させる |
| VPN 中なのに Microsoft Update から落ちる | 端末が intranet 扱いになっているか、境界が一致しているか | VPN の IP 範囲を境界に登録し、DP/SUP の関連付けを再確認 |
| DP があるのに「コンテンツが見つからない」 | 更新パッケージが DP に配布済みか、境界グループの関連付け | 配布状態と境界グループ、フォールバック設定を確認 |
| ダウンロードが遅い/止まる | CAS.log / ContentTransferManager.log / DataTransferService.log | ネットワーク（プロキシ、TLS、メータード）と BITS/DO 設定を見直す |
更新は「誰が判断し、どこから落とすか」を分解して設計すると、要件に対して過不足のない打ち手が選べます。VPN 時の DP 配布と、VPN 外の Windows Update（Microsoft Update）活用は両立できますが、そのためには CMG などで MP/SUP 到達性を確保する、もしくは WUfB/Intune に管理を寄せるという“仕組みの追加”が必要です。
コメント