運用中のSCCM（Microsoft Configuration Manager）2403から2503へ更新する際、「直接上げてよいのか」「2409を挟むべきか」で迷うことが多いです。本記事では、サポートされるアップグレード経路の考え方と、失敗しないための事前チェック・実施手順をまとめます。
SCCM（Configuration Manager）のバージョン表記とアップデート方式を整理
SCCMは現在「Microsoft Configuration Manager（Current Branch）」として提供され、基本はコンソールの「更新とサービス（Updates and Servicing）」からインプレースでアップデートします。バージョン表記は「2403」「2409」のように年+月（YYMM）で、公開後に不具合修正としてホットフィックス（Hotfix Rollup / Update Rollup）が配布されることもあります。
アップグレードを設計する際に重要なのは、単に「最新に上げる」だけでなく、次の3点を最初に押さえることです。
- アップグレード可能な起点バージョン（どこから上げられるか）
- 自組織の運用要件（変更管理、停止許容、監査要件）
- 事前の健全性（前提条件・サイト状態・バックアップ）
SCCM 2403から2503へのアップグレード経路：結論と根拠
今回の論点は「2403→2503に直接アップグレードしてよいか？ それとも2409を挟むべきか？」です。結論から言うと、2403→2503の直接アップグレードで問題ないという整理になります。
| 結論 | 理由（要点） |
|---|---|
| 2403→2503の直接アップグレードはサポート範囲 | 公式ドキュメント上、2503へのアップグレードは「2309以降」から可能とされている 2403は2309より後なので、2403→2503は条件を満たす 実例として2309→2503を直接アップグレードして完了したという報告もある |
つまり、技術的・サポート的にはわざわざ2409を挟む必要はありません。もちろん「段階的に上げる」こと自体は悪ではありませんが、SCCMはアップデート1回ごとに周辺作業が発生しやすいため、むしろ作業回数を増やすことがリスクになる場合もあります。
アップグレードパス早見表（2403環境の判断を素早くする）
| 起点 | 経路 | サポート観点の整理 | 現場でのおすすめ |
|---|---|---|---|
| 2403（ホットフィックス適用済み） | 2403→2503 | 「2309以降」条件を満たすためサポート範囲 | 基本はこのルート |
| 2403（ホットフィックス適用済み） | 2403→2409→2503 | 段階アップでも問題ないが必須ではない | 監査要件・超大規模・慎重運用なら検討 |
| （参考）2309未満 | まず2309以降へ | 2503の提供条件が「2309以降」なら、先に要件を満たす必要がある | 段階計画を立て、検証とメンテ枠を確保 |
2409を挟むべきか？メリット・デメリットを現実的に比較
段階アップが「絶対に安全」というわけではありません。更新回数が増える分、メンテ枠・周知・検証・復旧計画も増えます。判断は次の比較表が現実的です。
| 選択肢 | メリット | デメリット | こういう時に選ぶ |
|---|---|---|---|
| 2403→2503（直接） | メンテナンスが1回で済む 作業工数とリスクイベントが最小 周辺作業（クライアント/DP/OSD等）を1回分に圧縮 | 変更点の取り込みが一気になるため、事前の確認が浅いと運用影響が出る 社内規程が「段階アップ」前提の場合、承認プロセスが通りにくい | 停止許容が限られ、メンテ枠を増やせない 既に検証・チェック手順が整っている 運用コストを最小にしたい |
| 2403→2409→2503（段階） | 変更点レビューを小分けにでき、影響を段階的に確認できる 大規模環境で「段階ロールアウト」と相性が良い 監査要件に合わせて変更単位を小さくできる | 更新作業が2回になり、工数・周知・手戻りポイントが増える 周辺作業（クライアント更新、コンテンツ更新等）が増えやすい | 超大規模・多拠点で、段階的に確認しないと怖い 過去にアップデート障害があり、社内が慎重運用に振れている 監査や規制で、変更を分割する必要がある |
アップグレード前の必須確認：前提条件とサイトの健全性
直接でも段階でも、失敗の多くは「前提不足」か「更新前から壊れていた部分の顕在化」です。アップデート作業そのものより、事前の健全化に時間を使うほうが成功率は上がります。
前提条件（Prerequisites）チェックの観点
| カテゴリ | 確認内容 | 具体的なポイント |
|---|---|---|
| OS / SQLのサポート | サイトサーバーOS、SQL Serverがサポート範囲か | サポートマトリクスに合致しているか。SQLのCU適用状況も棚卸し。 |
| リソース | ディスク空き、CPU、メモリ、DB容量の余裕 | 更新時はログと一時ファイルが増える。特にDBログ（LDF）拡張に注意。 |
| .NET / Windows更新 | 必要な.NETやWindows更新が揃っているか | 不足していると前提条件チェックでエラー。再起動保留も事前解消。 |
| サイトヘルス | Component Status、レプリケーション、キューの滞留 | 赤/黄が残る状態での更新は避ける。まず正常化してから実施。 |
| セキュリティ対策ソフト | リアルタイムスキャン除外（フォルダ/プロセス） | サイトサーバー/SQL/DPは除外が重要。更新ファイルが隔離されると泥沼化。 |
| SUP/WSUS | 同期が安定しているか、DBや証明書が健全か | 更新配布が業務影響になりやすい。同期エラーがあるなら先に解消。 |
| OSD（ADK/WinPE） | ADK/WinPEの整合、ブートイメージの更新計画 | OS展開を使う環境は要注意。更新後にブートイメージの再配布が必要になりやすい。 |
「前提条件チェックのみ」を必ず先に実行する
コンソールの「更新とサービス」から、2503のアップデートに対して「前提条件チェックのみ」を先行実行できます。これは実務上、必須工程にしてよいレベルです。
- OS/SQL/.NET/権限不足など、アップデート前に潰すべき問題を事前に可視化できる
- Warning（警告）とError（エラー）を分けて、優先度を付けて対処できる
- チェック結果がログとステータスで追えるため、変更管理の証跡としても使える
前提条件チェックでよく出る指摘と対処例
| 指摘の例 | ありがちな原因 | 対処の方向性 |
|---|---|---|
| SQLのバージョン/構成が未サポート | SQLが古い、CU未適用、構成が要件外 | サポートされるSQLへ更新し、必要なCUを適用。DBバックアップ後に実施。 |
| ディスク空き不足 | ログ肥大化、Content Library増加、WSUSコンテンツ肥大 | 不要ログの整理、WSUS/DBログのメンテ、必要ならディスク増設。 |
| 再起動保留 | Windows更新適用後の再起動が残っている | メンテ時間を確保して再起動し、保留状態を解消してから更新する。 |
| コンポーネントエラー | レプリケーション不整合、ロール状態不良 | Site Status/Component Statusを健全化してから挑む。エラー放置は避ける。 |
| WSUS/SUP関連の警告 | 同期エラー、証明書、プロキシ設定 | 同期ログを確認し、プロキシ/証明書/接続を修正。必要なら再同期。 |
バックアップ設計：最悪の時に戻せる状態を作る
SCCMのアップデートは「アンインストールして戻す」が難しいため、現実的なバックアウトはバックアップからの復元になります。最低限、次のセットを押さえます。
| 対象 | 推奨バックアップ | 理由 |
|---|---|---|
| サイトDB（SQL） | フルバックアップ（可能なら差分/ログも） | 復旧の要。最短で戻すにはDB復元が必須。 |
| サイトサーバー | OSレベルのバックアップ/スナップショット | コンポーネント、証明書、IIS設定などDB以外の要素もあるため。 |
| 証明書・IIS関連 | 証明書のエクスポート、IIS構成の控え | HTTPS環境はここが壊れると復旧工数が跳ね上がる。 |
| 構成情報 | ロール一覧、境界/境界グループ、サイト設定のエビデンス | 復元後の整合確認・再構築に必要。 |
推奨手順：2403から2503へ直接アップグレードする実施フロー
ここからは「直上げ」前提で、実務での進め方を粒度高めにまとめます。社内手順書へ転記しやすいよう、工程を準備・実施・確認に分けています。
作業フェーズの全体像
| フェーズ | やること | 成果物/判断材料 |
|---|---|---|
| 準備 | 変更点の把握、影響範囲の洗い出し、周知、バックアップ | 変更計画書、周知文、バックアウト方針、バックアップ完了 |
| 健全性確認 | Site Status/Component Status、レプリケーション、キュー滞留の確認 | 「更新前は正常」と言える根拠（ステータス/ログ） |
| 前提条件チェック | 「前提条件チェックのみ」を実行し、エラーを解消 | エラー0、または許容できる警告のみ |
| 更新の適用 | 更新のインストール、ログ監視、必要に応じた対処 | サイトバージョン更新、コンソール更新、ロール正常化 |
| 事後確認 | クライアント/DP/MP/SUP/OSDの代表動作確認、残課題の洗い出し | 検証結果、運用復帰宣言、残タスク一覧 |
アップデート当日の進め方（コンソール操作の流れ）
- 更新の取得
サービス接続ポイントがオンラインの場合はコンソールで更新を同期し、2503が「利用可能」になることを確認します。オフライン運用の場合は、更新パッケージの取り込み手順に沿って準備します。 - 最終の前提条件チェック
直前にWindows更新や構成変更を入れた場合は、もう一度「前提条件チェックのみ」を走らせ、エラーがないことを確認します。 - 更新のインストール開始
「更新のインストール」を実行し、進行状況を確認します。途中で“止まって見える”場面があるため、コンソール表示だけで判断せずログを併用します。 - ログ監視
代表例として CMUpdate.log を中心に追いかけ、必要に応じて関連ログを参照します。 - コンソール更新
サイト更新後、管理コンソール側の更新が促されます。管理端末が複数ある場合は、更新順序と接続互換性を意識します。 - サイトロール確認
管理ポイント（MP）、配布ポイント（DP）、ソフトウェア更新ポイント（SUP）、レポートなど、主要ロールが正常稼働しているかを確認します。
ログの早見表（トラブル時の切り分けを速くする）
| 領域 | 主に見るログ例 | 見るポイント |
|---|---|---|
| 更新の進行 | CMUpdate.log | どのフェーズで止まっているか、エラーコード、再試行状況 |
| ロール/コンポーネント | hman.log / sitecomp.log など | ロールの再構成、インストール失敗、依存関係エラー |
| 配布（DP） | distmgr.log | コンテンツ配布、パッケージ処理の滞留や失敗 |
| 管理ポイント（MP） | mpcontrol.log | MPの自己監視、クライアント接続性、IIS周りの問題 |
| ソフトウェア更新（SUP） | wsyncmgr.log / wcm.log | 同期失敗、WSUS接続、証明書/プロキシ/署名関連 |
更新作業中にやりがちな失敗
- 進捗が動かないからといって、すぐにサービス再起動やサーバー再起動をする（ログで状態を確認してから判断）
- エラーや警告が出ているのに「あとで見る」と放置して更新を走らせる（原因が増えて切り分け不能になりがち）
- 証明書変更、SUP再構築、SQL移行など大きな変更を同日に抱き合わせる（障害時の責任点が不明瞭になる）
アップグレード後に必ずやること：運用影響を最小化する後処理
サイトのバージョンが上がっただけでは完了ではありません。特に「クライアント」「更新配布」「OS展開」は影響が出やすいので、優先的に確認します。
アップグレード後チェックリスト
| 領域 | チェック項目 | 確認の観点 |
|---|---|---|
| サイト全体 | Site Status / Component Status がグリーン | 赤や黄が残っていないか。残っている場合は根本原因を特定。 |
| 管理ポイント（MP） | クライアントがポリシー取得できる | テスト端末でポリシー更新が走るか、エラーがないか。 |
| 配布ポイント（DP） | コンテンツ配布・取得ができる | 代表アプリ/パッケージを配布し、実際に取得できることを確認。 |
| ソフトウェア更新（SUP） | 同期が正常、配布が正常 | 同期ログ、配布ステータス、クライアントのスキャン結果を確認。 |
| クライアント | クライアントアップグレードの進捗 | 自動アップグレード/段階配布の設計通りに進むか。失敗端末の傾向を掴む。 |
| OS展開（OSD） | ブートイメージ/タスクシーケンスの動作 | WinPE/ADKの整合、ドライバ注入、PXE/メディア展開を確認。 |
クライアントアップグレードは段階ロールアウトが現実的
サイトアップグレード直後に全クライアントを一斉更新すると、ネットワーク負荷と問い合わせが跳ね上がります。おすすめは次の流れです。
- まずはIT部門・検証端末などのパイロットコレクションで新クライアントを展開
- 代表的な業務アプリ、VPN、社内プロキシ、証明書など“社内あるあるの地雷”を踏みにいく
- 問題がなければ部門/拠点単位で対象を拡大
- 最後に全体へ展開し、旧クライアントの残数を監視して収束させる
直接アップグレードを成功させる実践Tips
ホットフィックスの考え方
質問では「2403はホットフィックス適用済み」とのことですが、アップグレード後も同じ考え方が重要です。2503適用後にホットフィックスが公開されている場合は、既知の問題・自環境の症状に照らして適用可否を判断します。特にSUP/OSD/クライアント周りは、後追いで修正が入ることがあるため、公開情報の棚卸しを運用に組み込むと安定します。
「更新前の健全化」が一番効く
SCCMアップデートのトラブルは、アップデート自体よりも更新前から潜んでいた不整合が表面化して起きるケースが多いです。よくある例は次の通りです。
- レプリケーションの遅延や不整合がある（普段は気づかない）
- SUP同期がたまに失敗しているが、運用で誤魔化している
- 配布ポイントのコンテンツが壊れているが、利用頻度が低く露見していない
- 証明書やIIS設定が継ぎ足しで、属人的になっている
アップデート前にこれらを潰しておくと、直上げでもかなり安定します。
検証環境があるなら「同じ手順で一回通す」
本番に近い検証環境（Pre-Prod）がある場合は、同じ手順で2403→2503を一度通し、次を確認しておくと安心です。
- アップデート後のコンソール接続性と権限（RBAC）
- アプリ配布、OS展開、ソフトウェア更新配布の代表シナリオ
- エージェント（クライアント）のバージョンアップ挙動と失敗端末の傾向
まとめ：2403→2503は直上げでOK。鍵は事前チェックと健全性
- 2403→2503の直接アップグレードはサポート範囲であり、基本的に問題ない
- 2409を挟むのは必須ではなく、運用ポリシーやリスク許容度で選ぶ
- 成功の鍵は「経路」よりも、前提条件チェック・バックアップ・サイト健全性確認
- アップデート後は、クライアント/DP/SUP/OSDなど業務影響が出やすい機能を優先的に確認する
最短で安全に進めたいなら直上げ、組織要件で慎重に進めたいなら段階アップ。どちらを選ぶにせよ、事前の健全化とチェックを丁寧に積み上げることが、SCCM 2503アップグレード成功の近道です。
コメント