Configuration Managerで機能更新プログラムを展開する方法
はじめに
Configuration Manager（ConfigMgr / MECM）を使えば、社内のWindows端末を「24H2→25H2」のような新しいバージョンへまとめて上げられます。この記事では、その仕組みと手順を初めての人向けに整理します。
Windowsの更新には大きく2種類あります。
| 種類 | 中身 | 頻度 | ConfigMgrでの分類 |
|---|---|---|---|
| 品質更新プログラム | セキュリティ修正・不具合修正（月例パッチ） | 毎月 | Security Updates など |
| 機能更新プログラム | Windowsのバージョン自体を上げる（例：24H2→25H2） | 年1回 | Upgrades |
月例パッチは「部品の交換」、機能更新は「車のモデルチェンジ」くらいの違いがあります。所要時間も失敗したときの影響も大きいので、展開には少し準備が必要です。
前提条件
機能更新をコンソールに出すには、まず「ソフトウェアの更新ポイント」で Upgrades 分類を同期しておく必要があります。これを忘れると、そもそも一覧に何も表示されません。
- ソフトウェアの更新ポイント（WSUS連携）が構成済み
- SUPのプロパティで分類「Upgrades」にチェックを入れて同期済み
- 製品で対象OS（例：「Windows 11」）にチェック済み
- ハートビート探索が有効（Windowsサービスダッシュボードの表示に必要）
- クライアントがWindows Update for Businessではなく、ConfigMgrのソフトウェア更新で管理されている
- クライアント設定の「機能更新プログラムの動的更新」などを環境に合わせて確認
確認場所：管理 ワークスペース → サイトの構成 → サイト → 対象サイトを右クリック → サイト コンポーネントの構成 → ソフトウェアの更新ポイント
展開方法は3種類
迷ったら、まずは「機能更新プログラムを直接展開」から始めるのがおすすめです。月例パッチの展開とほぼ同じ操作でできます。
| 方法 | 向いているケース | 手間 | カスタマイズ性 |
|---|---|---|---|
| 機能更新プログラムを直接展開 | 対象と時期を自分で決めて一度に上げたい | 少ない | 低い |
| Windowsサービスプラン | リリース後○日経ったら自動で展開したい（自動展開規則の機能更新版） | 最初の設定のみ | 低い |
| タスクシーケンス（OSアップグレード） | 更新の前後にアプリ削除や設定変更などの処理を挟みたい | 多い（バージョンごとにOSアップグレードパッケージを取り込む） | 高い |
サービスプランは、自動展開規則（ADR）の機能更新版だと考えると分かりやすいです。ただし評価対象は Upgrades 分類のみで、月例パッチは引き続き通常のソフトウェア更新の流れで展開します。
手順：機能更新プログラムを直接展開する
いきなり全台に配るのではなく、まず数台のパイロット用コレクションで試してから本番に広げます。
- 対象コレクションを用意する
- パイロット用（数台）と本番用に分けて作成しておく
- 「すべてのシステム」などの組み込みコレクションには展開できない（高リスク展開の制限）
- 機能更新プログラムを探す
- ソフトウェア ライブラリ → Windows サービス → すべての Windows 機能更新プログラム
- 対象バージョン・言語・アーキテクチャを確認し、「必須」の数が1以上のものを選ぶ
- 展開ウィザードを開く
- 対象の更新を右クリック → 展開
- 全般・展開の設定
- 展開先コレクションを指定し、種類を「必須」か「利用可能」から選ぶ
- スケジュール
- 利用可能時刻とインストールの期限を設定する（期限には最大2時間のランダムな遅延が入る）
- ユーザー エクスペリエンス
- ソフトウェアセンターでの通知、期限後の動作、再起動の扱いを決める
- 展開パッケージと配布ポイント
- 新規パッケージを作る場合は、事前に共有フォルダーを作っておく
- 配布先の配布ポイント（またはグループ）を指定する
- 完了して監視する
- 監視 → 展開 で進捗を確認
- 失敗した端末は Windows サービス ダッシュボードの「コレクションのエラー」でエラーコードを確認できる
パイロットで問題なければ、同じ手順で本番用コレクションに展開します。
つまずきやすいポイント
| 症状 | よくある原因 | 対処 |
|---|---|---|
| 機能更新が一覧に出てこない | SUPで「Upgrades」分類や対象OSの製品が未選択 | 分類・製品にチェックを入れて再同期する |
| 端末で「必須」にカウントされない | 端末がWindows Update for Business管理になっている | ConfigMgrのソフトウェア更新で管理されているか確認する |
| 展開先にコレクションが表示されない | 高リスク展開の設定で、大きいコレクションが隠されている | カスタムコレクションを使う、サイトの設定を確認する |
| 期限が来てもインストールされない | メンテナンス期間外になっている | メンテナンス期間か、期限後の動作設定を見直す |
| ダウンロードに失敗する | 「Microsoft Updateからダウンロード」に頼っている | 機能更新では使わず、配布ポイントにコンテンツを配置する |
| アップグレードが途中で失敗する | 空き容量不足、ドライバーやアプリの互換性 | ダッシュボードのSetupDiagのエラーコードから原因を調べる |
特に最後のケースは、パイロットで見つけておくのが一番の対策です。
現場で感じたこと
実際に案件で機能更新を展開してみて、一番大変だったのは検証の範囲です。機能更新プログラムを入れると、OSのバージョンアップだけでなく、その月に配信予定だった品質更新（累積更新）までセットで適用されていました。
そのため「新バージョンの検証」と「今月のパッチの検証」を同時に行うことになります。何か不具合が出ても、どちらが原因なのか切り分けにくいのが悩みどころでした。
なぜセットで入るのか
- 配信される機能更新プログラム自体が、最新の累積更新を含んだものに差し替えられることがある
- Windowsセットアップの「動的更新」が有効だと、インストール中にインターネットから最新の累積更新を取得する
対策として考えられること
- セットで検証すると割り切る：月例パッチの公開（日本時間で第2火曜の翌日）に合わせて検証を始め、同じ月のうちに本番展開まで終える
- 検証と本番で同じ月の更新を使う：月をまたぐと中身が変わるため。展開後はビルド番号で、検証時と同じか確認する
- 動的更新を無効にする：クライアント設定「機能更新プログラムの動的更新を有効にする」を「いいえ」にする。ただし、UUPベースの機能更新ではドライバー以外は制御できない点に注意
- 中身を完全に固定したいならタスクシーケンス：特定の月のメディアを取り込んでOSアップグレードすれば、入る内容を自分で決められる
まとめ
- 機能更新は「Upgrades」分類。まずSUPで同期しないと何も始まらない
- 基本は「直接展開」、自動化したければサービスプラン、前後処理が必要ならタスクシーケンス
- パイロット→本番の順で広げ、失敗はSetupDiagのエラーコードから追う
