Microsoft Endpoint Configuration Manager（SCCM）のSoftware Centerから、Windows更新だけでなく「ドライバー更新」まで社内配布したい。ところがMicrosoft Update由来のDrivers分類は、ConfigMgrのソフトウェア更新として扱えないのが実情です。理由と代替策、社内配布を徹底する設定ポイントをまとめます。
現場で起きやすい悩み：更新はSCCMで閉じたいのに、ドライバーだけが「外」に出てしまう
Software Center（SCCM / Microsoft Endpoint Configuration Manager、以下ConfigMgr）の「ソフトウェア更新」運用が軌道に乗ると、次に出てくる要求が「Windows Updateで出てくるドライバー更新も、同じようにSoftware Centerから社内配布したい」です。
ただしここで重要なのは、同じ“Windows Update画面に出てくる”ものであっても、ConfigMgrが得意な領域（品質更新・セキュリティ更新）と、仕組みとして別物になりがちな領域（ドライバー）が混在している点です。まずは結論を整理します。
| やりたいこと | ConfigMgrの「ソフトウェア更新」で実現できる？ | 現実的な解決ルート |
|---|---|---|
| Windowsの品質更新 / セキュリティ更新を社内配布（端末がMicrosoftへ直接取りに行かない） | 可能 | 配布パッケージ＋DP配布（境界グループ設計含む） |
| Microsoft Update由来の一般的な「Drivers（ドライバー）」分類を、更新としてSoftware Centerに並べて配布 | 基本的に不可 | 第三者更新（メーカーのドライバーカタログ）/ ドライバーパッケージ / アプリ配布 |
| Surfaceのドライバー/ファームウェア更新を更新として配布 | 条件付きで可能 | SUPの「Surface drivers and firmware」同期（Surface端末に限定） |
結論：Microsoft Updateの「Drivers」分類を、そのままConfigMgrの“ソフトウェア更新”として扱うのは難しい
ConfigMgrのソフトウェア更新は、Software Update Point（SUP）がWSUSの仕組みを利用して「更新メタデータを同期し、適用可否を判定し、展開（デプロイ）する」のが基本です。ここで同期できる更新分類は、Critical Updates / Security Updates / Updates / Upgrade などに限定され、一般的な“Drivers”分類は最初から選択肢に出てきません。
そのため、「Windows Updateのドライバー更新を、ConfigMgrの“ソフトウェア更新”にそのまま載せてSoftware Centerで配布する」という発想は、仕組みの段階で詰まります。例外としてSurfaceには専用の同期オプションがありますが、一般PCのドライバー更新を横断的に扱えるわけではありません。
誤解しやすいポイント
- WSUS側には「Drivers」分類が見えることがありますが、ConfigMgr（SUP）側で選べる分類とは一致しません。
- 「Microsoft Update Catalogで落とせる＝SCCMで更新配布できる」とは限りません。カタログから手動入手できても、ConfigMgrの“更新”として同期・検出・展開できるとは別問題です。
- 「端末がMicrosoftへ取りに行かない」を満たすには、ドライバーを“更新”として扱う必要はなく、配布物（アプリ/パッケージ/タスクシーケンス）として社内から配るでも目的達成できます。
まず押さえるべき前提：Software Center配布で「社内から落とす」には2つの流れがある
更新配布で混乱しやすいのが、「どこへスキャンしに行くか（更新の有無を調べる）」と「どこから実体をダウンロードするか」が別々に決まることです。端末がインターネットへ出てしまう場合、後者（ダウンロード元）の設定ミスが多いです。
| フェーズ | 何が起きる？ | 社内に閉じたい場合の狙い |
|---|---|---|
| スキャン（検出） | 端末が「適用が必要な更新」を判定する | SUP/WSUSへ向ける（Co-managementやポリシー競合に注意） |
| コンテンツ取得 | 更新の実体（CAB/MSUなど）を取得する | DP（Distribution Point）から取得させる |
| インストール | 更新を適用し、必要なら再起動 | メンテナンスウィンドウ/ユーザー通知を設計 |
通常のWindows更新（品質更新/セキュリティ更新）を社内配布に寄せる具体策
「端末がMicrosoftのサーバーから直接ダウンロードする」挙動を避けたい場合、まずはここを確実に固めます。ドライバー以前に、品質更新やDefender定義更新が外へ出ている環境だと、運用全体の設計が崩れやすいからです。
社内配布に寄せるためのチェックリスト
- 更新展開で“配布パッケージ（Deployment Package）”を使っている（= DPにコンテンツを置く）
- 境界グループにDPが関連付いている（端末が所属する境界にDPがいないと、取りに行く先が変わる）
- 展開設定で「Microsoft Updateからダウンロード」を許可していない（フォールバック設定を意図しているか）
- インターネットに出る必要があるシナリオ（機能更新のDynamic Update等）を把握し、必要なら無効化する
“外に出ない”ために押さえる設定ポイント（よくあるミス付き）
| 設定箇所 | 推奨イメージ | よくあるミス |
|---|---|---|
| 更新の展開（Deploy） | 配布パッケージを指定し、クライアントはDPから取得する前提 | 「配布パッケージなし」で展開してしまい、端末が外部取得に寄る |
| 境界グループ | 端末が必ず“近いDP”を参照するよう関連付ける | VPN/拠点の境界が曖昧で、遠いDPやフォールバックへ流れる |
| フォールバック設定 | 外部ダウンロードを許可するなら条件・猶予時間を明確化 | 意図せず「MicrosoftからもOK」になっており気づきにくい |
| 機能更新（Feature Update） | Dynamic Updateの扱いを事前に決める（必要なら無効化） | 機能更新だけ端末が外へ出て「SCCMが効いていない」と誤認する |
進め方（運用手順のひな形）
- 同期対象の製品/分類を整理：必要な製品（Windows 10/11、Office等）と、Security Updates / Updates / Upgrade などを最小限で選びます。増やしすぎると同期・メタデータ・WSUSの負荷が上がります。
- Software Updatesの検索と選定：月例の累積更新（LCU）、Servicing Stack Update（SSU）、Defender定義などを対象コレクションに合わせて選びます。
- 更新をダウンロードする配布パッケージを作成：コンテンツの保存先を決め、更新バイナリを取得します。
- DPへ配布（Distribute Content）：DPグループで展開し、各拠点DPの配布状態を「成功」にします。
- 展開（Deploy）でダウンロード元を固定：必要に応じて「ユーザーがSoftware Centerから実行できる（Available）」か「期限で強制（Required）」かを分け、テスト→段階展開（フェーズ展開）→本番の流れにします。
「No deployment package」が危険になりやすい理由
更新展開のウィザードや設定で配布パッケージを使わない構成（いわゆるNo deployment package相当）にすると、クライアントは更新の実体をDPから受け取れません。結果として、クライアント側の条件によってはMicrosoft側から直接取得する挙動になりがちです。
「社内配布にしたい」のであれば、原則として配布パッケージを作り、DPに必ず配布する設計に寄せるのが分かりやすく、事故が少ないです。
“外に出る”を防ぐために境界グループで見直すポイント
- 端末が所属する境界グループにDPがいるか（同一拠点にDPがない場合、隣接拠点DPやクラウド、Microsoftへのフォールバックが起きうる）
- フォールバックの猶予時間（DPが見つからない・遅い場合に、何分で別ソースを許可するか）
- VPN/リモート端末の境界（社外端末に無理に社内DPを引かせると、帯域が破綻する）
社内配布できているか確認する（現場で効く見方）
「Software Centerから更新を押したら、DPから落ちているのか？」を判断するには、クライアントログを見るのが最短です。代表例をまとめます。
| 見るもの | どんなときに使う？ | ポイント |
|---|---|---|
| WUAHandler.log | 更新スキャン/適用判定の確認 | スキャン先やエラー（0x系）を追う |
| UpdatesDeployment.log | 展開の受信/インストール判断 | “Available/Required”や期限の扱いを確認 |
| LocationServices.log | どのDP候補を選んだか確認 | 境界グループ/コンテンツロケーションの決定プロセスが見える |
| ContentTransferManager.log | コンテンツ取得の開始/終了 | どのDP（URL/サーバー）から取っているかが分かる |
| DataTransferService.log | BITS転送の詳細 | 転送失敗の理由（HTTPコードなど）を掘る |
ドライバーをSoftware Center経由で社内配布したい場合の現実解
ここからが本題です。Microsoft Update由来のドライバーを“更新”として扱うのが難しい以上、目的を満たす別ルートを選びます。代表的には次の3つです。
| ルート | Software Centerで配れる？ | 向いているケース | 運用の特徴 |
|---|---|---|---|
| 第三者更新（Third-party software updates）でメーカーのドライバーカタログを使う | 配れる（更新として扱える） | Dell/HP/Lenovo等の端末が多い、定期的にドライバー更新したい | 更新の検出/展開フローに乗せられる。証明書やカタログ運用が必要 |
| ドライバーパッケージ/タスクシーケンスで配布 | 配れる（配布物として） | OSD（展開）や特定モデルだけに当てたい | モデル別に管理しやすいが、保守（更新作業）は手動が多い |
| アプリケーション/スクリプトとして配布（OEMツールやINFの取り込み） | 配れる（アプリとして） | 「このドライバーだけ」「この不具合だけ」などピンポイント配布 | 検出ルール設計が肝。更新の見え方は“アプリ配布”に寄る |
第三者更新でドライバーを扱う：メーカー公式カタログを“更新”として流す
Software Centerの“更新”枠に近い体験を残しつつ、社内配布も実現したいなら、まず検討したいのがThird-party software updates（第三者更新）です。ConfigMgrはサードパーティの更新カタログを購読し、WSUS/SUPへ公開して、通常のソフトウェア更新と同じ流れで展開できます。
進め方の全体像
- 第三者更新の機能を有効化（サイト側とクライアント側の設定を有効にする）
- メーカーのカタログを追加・購読（コンソールの「Third-Party Software Update Catalogs」から）
- カタログ証明書を承認（不明な発行者のままにしない）
- メタデータ同期 → 必要な更新を公開（Publish）
- 配布パッケージでコンテンツをダウンロードしDPへ配布
- コレクションへ展開（Available/Requiredを設計）
コンソール上の導線（迷いどころを減らす）
- カタログ購読：Software Library > Software Updates > Third-Party Software Update Catalogs
- 更新の確認：Software Library > Software Updates > All Software Updates（分類やベンダー名でフィルタ）
- ダウンロード/配布：更新を選択してDownload→配布パッケージへ格納→DPへ配布
メーカー別カタログのイメージ（代表例）
実際に使えるカタログは複数あり、端末メーカーが公式に提供しているものもあります。代表例を挙げると次のような方向性です。
| メーカー/系統 | 主な更新対象 | 注意点 |
|---|---|---|
| Dell | BIOS/ファームウェア/ドライバー/ユーティリティ | モデル/シリーズによって適用判定の前提（インベントリ等）が変わる場合がある |
| HP | BIOS/ドライバー/ソフト | 更新適用には再起動やBitLockerの一時解除が絡むことがあるため、手順を標準化する |
| Lenovo | BIOS/ドライバー | “いつ更新するか”のポリシー（四半期ごと等）を決めてから回すと破綻しにくい |
第三者更新運用で失敗しやすいポイント
- 証明書（署名）の取り扱い：第三者更新は“署名付き更新”として公開されるため、クライアントが信頼できる状態にする必要があります（Trusted Publishers等）。
- BIOS/ファームウェア更新をいきなり全台へ出す：品質更新よりリスクが高いので、必ずパイロット→段階展開にします。
- 更新の“適用判定”が期待通りでない：ベンダー更新は機種依存が強く、前提コンポーネント（例：インベントリ/エージェント）や検出ロジックの癖があります。
特定のドライバーをどうしても配りたい：更新ではなく「配布物」として扱う
「このWi-Fiドライバーのこのバージョンだけ当てたい」「この不具合回避で特定のINFを入れたい」など、対象が明確な場合は、更新の枠に寄せるより配布物として堅実に配るほうが短距離で解決します。
選択肢
- ドライバーパッケージ：複数INFをまとめて保持し、必要なタイミングで適用する
- アプリケーション配布：セットアップ（EXE/MSI）型のドライバーや管理ツールを、検出ルール付きで配布する
- タスクシーケンス：OSD時にモデル判定して適切なドライバーセットを入れる
シンプルに配る例（INFを入れる）
パッケージの中にドライバー一式を入れ、インストールコマンドとしてpnputilを使う方法は分かりやすいです。例：
pnputil /add-driver ".\Drivers\*.inf" /subdirs /installこの方式は“更新”ではないため、どの端末に入っているか（バージョン管理）は検出ルールやレポート設計が重要になります。配布前に「適用対象モデル」「既存バージョン」「ロールバック手順」をセットで用意すると、トラブルが減ります。
OS展開（OSD）中心なら「ドライバーパッケージ＋タスクシーケンス」が最も事故が少ない
社内でPC入れ替えやキッティングを継続的に行っている場合、ドライバー更新を“日常のソフトウェア更新”に寄せるより、OSDの段階で最新ドライバーセットを確実に入れるほうが満足度が高いことが多いです。
運用の型（おすすめ）
- モデルごとにドライバーパッケージを作る（命名規則を固定する）
- タスクシーケンスでモデル判定して、該当パッケージのみ適用する
- 四半期に一度など、更新頻度を決めて“まとめて更新”する（毎月追いかけない）
モデル判定の考え方
WMI（Win32_ComputerSystem / Win32_BaseBoard等）でモデル名を取得し、条件分岐させるのが定番です。モデル名の揺れ（例：末尾に世代表記がつく）を吸収できるよう、正規表現やプレフィックス一致の運用を作ると、現場運用が回ります。
Surfaceは例外：専用オプションでドライバー/ファームウェア更新を同期できる
一般的なPCのドライバー更新は難しい一方で、SurfaceについてはConfigMgrのSUPに「Microsoft Surface drivers and firmware updates」を含めるための専用チェックが用意されています。Surface端末を多く抱えている環境では、有力な選択肢になります。
ただし、ここでできるのはあくまでSurface向けであり、他メーカーPCのドライバー更新を横断的に解決するものではありません。Surfaceとそれ以外が混在する環境は、Surfaceはこの方式、その他は第三者更新やパッケージ配布、と割り切ったほうが設計がすっきりします。
どのルートを選ぶべきか：判断基準の早見表
| 判断軸 | 第三者更新（メーカーカタログ） | ドライバーパッケージ/OSD | アプリ/スクリプト配布 |
|---|---|---|---|
| Software Centerの“更新”体験を保ちたい | ◎ | △（配布物として提供） | △（アプリとして提供） |
| 社内配布（DPから取得）を徹底したい | ◎ | ◎ | ◎ |
| 機種が多い/混在している | ○（ただし判定の癖に注意） | △（モデル別管理が増える） | ○（対象を絞れば強い） |
| 更新頻度を高く保ちたい | ○ | △（更新作業が重い） | ○ |
| 初期構築の手軽さ | △（証明書/同期/公開など） | ○ | ○ |
運用で差が出る“設計のコツ”
ドライバー更新は「毎月やるもの」から外すと回りやすい
品質更新（LCU）は基本的に毎月追従が前提ですが、ドライバー更新は同じペースで回すと破綻しやすいです。おすすめは、ドライバーは四半期に一度の“棚卸し＋まとめ適用”、緊急の不具合対応のみ例外で単発配布、という二段構えです。
BIOS/ファームウェア更新は「別リング」で試す
ドライバー更新の中でもBIOS/ファームウェアは影響範囲が大きく、失敗時の復旧も重い領域です。パイロット（IT部門端末）→少数部門→全社のリングを固定し、リングごとに猶予期間を設けると事故が減ります。
「外に出ない」ことを数値で担保する
- クライアントが参照するDPを可視化する（ログ/レポート/ネットワーク監視）
- 拠点間WANを通していないかを確認する（境界グループの関連付けとフォールバック時間）
- 更新サイズ（LCU/ドライバー/BIOS）を踏まえ、DPのディスク容量を見積もる
よくある質問
Microsoft Update Catalogから落としたドライバーを、WSUS/ConfigMgrの更新として取り込めないの？
ドライバーを“更新”として同期・検出・展開する仕組みは前提条件が厳しく、一般的にはおすすめしません。現実的には、カタログから入手したものをドライバーパッケージやアプリ配布として配るほうが、社内配布という目的に対して確実です。
端末がどうしてもMicrosoftに出ていくケースはある？
機能更新（Feature Update）に絡むDynamic Updateなど、シナリオによってはMicrosoft Updateへアクセスする挙動が混ざることがあります。社内規程上どうしても許可できない場合は、機能更新の進め方（オフラインメディア/制御設定）を別途設計するのが安全です。
まとめ：ドライバーは「更新」ではなく“供給経路”で最適解を選ぶ
- Microsoft Update由来の一般的なDrivers分類を、ConfigMgrのソフトウェア更新としてSoftware Center配布するのは基本的に難しい。
- 一方で、品質更新/セキュリティ更新を社内配布に寄せることは可能。配布パッケージ＋DPを基本形にする。
- ドライバーをSoftware Center経由で配るなら、第三者更新（メーカーのドライバーカタログ）が現実解。
- ピンポイント配布やOSD中心なら、ドライバーパッケージ/アプリ配布/タスクシーケンスで目的を達成する。
「ドライバーも更新で全部まとめたい」という気持ちは自然ですが、更新分類・検出・リスクの観点で無理をすると運用が不安定になります。“端末が外へ取りに行かない”という目的を軸に、最適な配布レーンを選ぶのが、長期的に一番ラクで安全です。
コメント