SCCM（MECM / ConfigMgr）の「Updates and Servicing」で更新を開始したのに、状態が“開始したまま”で2日以上変わらない――。この症状は、止まっている段階とログが分からないと切り分け不能です。質問先の選び方と、最短で原因に近づく確認ポイントをまとめます。
現象の整理：更新が「開始したまま進まない」とは何が起きているのか
ConfigMgr の更新（いわゆるインプレース更新）は、コンソール上ではシンプルに見えても、裏側では複数の処理が段階的に走ります。たとえば、更新パッケージのダウンロード、展開、前提条件チェック、サイトコンポーネントの更新、コンソール更新、ポストインストール（後処理）などです。
そのため、画面上の表示が数時間変わらないこと自体は珍しくありません。ただし「2日間まったく動かない」場合は、どこかで待ち状態・リトライ・エラー停止が起きている可能性が高く、まずは“どの段階で止まっているか”を特定する必要があります。
まず押さえるべき前提
- 「止まっているように見える」だけで、バックグラウンドで処理やリトライが進行していることがある
- 一方で、ログに失敗理由が出ているのに気づかず放置して“2日経過”になるケースも多い
- よって、コンソール表示だけで判断せず、サイトサーバー側ログで現状を把握する
受理回答の要点：質問先が違うと解決が遅れる
今回の受理回答（解決として採用された回答）のポイントは、技術的な手順ではなく「質問先が不適切なので、SCCM/MECM Updates の専用フォーラム（Microsoft Q&A の該当カテゴリ）に投稿し直す」という案内でした。
一見回り道に見えますが、ConfigMgr の更新は、Windows Server 一般の話題（役割/機能、WSUS、IIS、AD など）とは切り分け観点が異なります。更新ログ（cmupdate.log ほか）や、階層（CAS/Primary/Secondary）、Service Connection Point の構成など、ConfigMgr 固有の情報が前提になります。適切なカテゴリに投げるだけで、回答者側が“確認すべきログ/設定”を前提に会話できるため、解決までの往復が大きく減ります。
| 投稿先 | 向いている相談 | 今回の症状との相性 |
|---|---|---|
| Windows Server 一般フォーラム | OS の機能/役割、パッチ、IIS、AD、一般的なサーバー運用 | ConfigMgr 更新は固有要素が多く、ログ前提の議論がしづらい |
| Microsoft Q&A の SCCM/MECM（Updates and Servicing）カテゴリ | ConfigMgr の更新、サイトサーバー、コンソール、階層、SCP、配布/レプリケーション | 症状・ログ・構成に沿って具体的に切り分けやすい |
専用フォーラムへ投稿する前に揃えるべき情報
専用フォーラムに投稿し直すとき、次の情報が最初から揃っていると、回答の質とスピードが一気に上がります。特にログ（cmupdate.log）は必須です。
| 情報 | 例 | なぜ必要か |
|---|---|---|
| 現行バージョン/更新対象バージョン | Current Branch のビルド番号、更新名（例：xxxx） | 既知問題や前提条件がバージョンで変わるため |
| 階層構成 | CAS + Primary / Primary 単体 / Secondary 有無 | “Replicating” で止まる場合など、階層依存の切り分けが必要 |
| 更新の状態（コンソール表示） | Downloading / Replicating / Installing / Post Installation | 止まっている段階で見るべきログや疑うポイントが変わる |
| Prerequisite check の実施有無と結果 | チェック済み/未実施、エラー/警告内容 | 更新失敗の原因がそのまま出ることが多い |
| サイトサーバーの OS/SQL 情報 | Windows Server 版、SQL Server 版 | サポート範囲や更新時の制約に直結 |
| ネットワーク条件 | SCP のオンライン/オフライン、プロキシ有無、FW/証明書 | “ダウンロードで止まる”系の最頻出原因 |
| cmupdate.log の該当範囲 | 開始時刻〜現在まで、エラー周辺 | 更新の進捗/待ち/失敗理由が最も出やすい |
最優先で見るログ：cmupdate.log で「今どこで止まっているか」を掴む
更新が進まないとき、真っ先に確認すべきログがcmupdate.logです。コンソールの表示は“結果”でしかなく、実際の進捗や失敗理由はログに出ます。
cmupdate.log の場所（代表例）
- サイトサーバーのログフォルダ配下（例：
C:\Program Files\Microsoft Configuration Manager\Logs\cmupdate.log） - 拡張子
.logを CMTrace で開くと読みやすい（時刻、スレッド、強調表示）
見るべきポイント
- 更新開始のタイムスタンプ以降で、最後に進捗が動いた行を探す
- ERROR / Failed / WARNING の直前直後だけでなく、その前後の“処理の流れ”も見る
- 同じメッセージが一定間隔で繰り返されているなら、待ち/リトライ/外部依存（通信・証明書など）の可能性が高い
| ログでよく探すキーワード | 意味合い | 次に見る場所 |
|---|---|---|
Downloading / dmpdownloader | 更新パッケージ取得フェーズ | dmpdownloader.log、SCP/プロキシ設定、FW |
Prereq / Prerequisite check | 前提条件チェック | Prereq の結果画面、関連ログ、ディスク/SQL/権限 |
Replicating | 階層間の複製 | replication 関連状態、SQL、リンク帯域 |
Installing / Setup | サイト更新（コンポーネント更新） | hman.log、sitecomp.log、コンポーネント状態 |
Post Installation | 後処理 | コンソール更新状況、追加コンポーネント、再起動要否の表示 |
ログの貼り方のコツ
フォーラムでは、ログを“全部”貼る必要はありません。次のように切り出すと、回答者が読みやすくなります。
- 更新を開始した時刻が分かる行を含める
- 最後に進捗が動いた行の周辺（前後数十行〜数百行）を含める
- エラーが出ている場合は、その直前直後を広めに含める
- ホスト名、ドメイン名、ユーザー名などは、必要に応じてマスクする
合わせて確認したい代表ログ
cmupdate.log だけで十分なケースもありますが、止まっている段階によっては周辺ログが決定打になります。最低限、次のログは名前だけでも押さえておくと便利です。
| ログ | 主に分かること | よく出番が来る状態 |
|---|---|---|
dmpdownloader.log | 更新パッケージのダウンロード詳細、HTTP/プロキシ/証明書関連の失敗 | Downloading で停滞、ダウンロード完了しない |
hman.log | 階層管理（Hierarchy Manager）周りの処理、構成の反映 | Installing 中の構成反映、階層関連の問題 |
sitecomp.log | サイトコンポーネントのインストール/更新 | Installing で停滞、コンポーネント更新が進まない |
smsdbmon.log | DB 監視、SQL への接続や処理の兆候 | SQL が絡む遅延・ロックが疑わしい |
distmgr.log | 配布マネージャー。更新に伴うコンテンツ処理の影響が見える場合がある | 更新後の配布やコンテンツ処理が詰まる |
コンソールで「どの段階で止まっているか」を言語化する
コンソールの「Administration > Updates and Servicing」では、更新ごとに状態が表示されます。投稿するときは、単に「進みません」ではなく、どの状態で何時間/何日止まっているかを書きます。これだけで、回答者の初手が変わります。
| 状態 | 起きがちな原因 | まず見る/確認する |
|---|---|---|
| Downloading | Service Connection Point からの取得ができない、プロキシ/証明書/TLS、FW、名前解決 | cmupdate.log、dmpdownloader.log、SCP 設定、プロキシ設定、インターネット到達性 |
| Replicating | 階層間の複製遅延、SQL の負荷、リンク帯域、レプリケーション状態異常 | レプリケーションの健全性、SQL の状態、ネットワーク |
| Installing | 前提条件未達、コンポーネント更新失敗、権限、ディスク不足、サービス停止 | cmupdate.log、Prereq 結果、sitecomp.log、hman.log、空き容量/権限 |
| Post Installation | 後処理が待ち、コンソール更新待ち、追加コンポーネントの反映、再起動待ち | cmupdate.log の後処理行、コンソール側の更新要否、再起動要否の表示 |
Prerequisite check を軽視しない：結果が“次の一手”を決める
更新が止まっているとき、Prerequisite check の結果がそのまま原因になっているケースは少なくありません。更新を進める前にチェックを走らせていない場合でも、まずチェックを実施し、その結果（エラー/警告）を添えて投稿すると話が早いです。
| よくある指摘 | 影響 | 現場での対処の考え方 |
|---|---|---|
| ディスク空き容量不足 | 展開/更新ファイルの配置で停止しやすい | サイトサーバー/SQL サーバー双方の空きを確認し、更新作業中は余裕を持たせる |
| サポート外の SQL/OS 条件 | 更新がブロックされる、または不安定化 | サポート範囲を満たす構成に揃えてから更新する |
| 権限・アカウント要件 | コンポーネント更新や DB 操作で失敗 | サービスアカウント/セットアップアカウントの権限を再確認する |
| コンポーネントの異常 | 更新処理が先に進めない | Monitoring のコンポーネント状態を事前に健全化してから更新する |
通信要件：Service Connection Point（SCP）周りが怪しいときの見方
“Downloading で止まる”“同じエラーが一定間隔で繰り返される”場合、SCP から更新メタデータ/パッケージを取りに行けていないことがよくあります。特に企業ネットワークでは、プロキシ、SSL インスペクション、FW、証明書ポリシーなどが絡み、SCCM 側は「待ってリトライ」を続けます。その結果、見た目は“2日進まない”になります。
最低限のチェックリスト
| チェック項目 | 確認観点 | 関連しやすい状態 |
|---|---|---|
| SCP の役割とモード | オンライン接続が必要な構成か、オフライン運用か | Downloading |
| プロキシ設定 | ConfigMgr 側にプロキシを設定しているか、認証要否、例外設定 | Downloading |
| FW/宛先制御 | 外向き通信の許可、URL/ドメイン制限、443 の通過 | Downloading |
| 証明書/TLS | TLS バージョン制限、SSL 検査、ルート証明書、時刻ずれ | Downloading |
| 名前解決 | プロキシ環境での名前解決経路、DNS | Downloading |
“2日進まない”ときにやりがちな NG 行動
焦って手当たり次第に触ると、原因の特定がさらに難しくなります。特に更新作業は、途中状態のまま手を入れると復旧に時間がかかることがあります。
| やりがちな行動 | なぜ危険/非効率か | 代わりにやること |
|---|---|---|
| 根拠なくサイトサーバーを再起動する | 処理中断やログ断絶で切り分けが遠のく | cmupdate.log で待ち/停止点を確認し、再起動が必要と判断できる根拠を作る |
| サービスを片っ端から停止/起動する | 症状が変化して“何が原因だったか”が不明になる | 止まっている段階に対応するサービス/コンポーネントだけを、ログ根拠とセットで扱う |
| 更新パッケージやフォルダを削除する | 復旧が複雑化し、サポート対象外の操作になる場合がある | フォーラム/サポートの指示に従い、必要なら正式手順でリセットや再ダウンロードを行う |
| 「画面が止まった」だけで故障と断定する | 長時間かかるフェーズもあり、誤った対処につながる | コンソール状態とログで“進捗があるか/同じ所を周回しているか”を見て判断する |
専用フォーラムに投稿するときのテンプレ（そのまま貼れる形）
以下は、SCCM/MECM Updates のカテゴリに投稿するときに、最初の1回で必要情報を渡すためのテンプレです。社内情報に触れる箇所はマスクして使ってください。
【症状】
Updates and Servicing で更新を開始したが、状態が（Downloading / Replicating / Installing / Post Installation）のまま約2日変化しない。
【環境】
・ConfigMgr（Current Branch）バージョン：XXXX
・適用しようとしている更新：XXXX
・階層：CAS（あり/なし）、Primary（台数）、Secondary（あり/なし）
・サイトサーバーOS：Windows Server XXXX
・SQL Server：XXXX
・Service Connection Point：オンライン/オフライン、配置サーバー：XXXX
・プロキシ：あり/なし（認証あり/なし）
【実施したこと】
・Prerequisite check：実施（エラー/警告：XXXX） / 未実施
・サイトサーバーのログ確認：cmupdate.log を確認済み
【ログ（抜粋）】
・cmupdate.log（開始時刻〜現在までの該当範囲）
・必要に応じて dmpdownloader.log / hman.log / sitecomp.log も添付
【補足】
・更新開始時刻：YYYY/MM/DD HH:MM
・最後に進捗が動いたログ行の時刻：YYYY/MM/DD HH:MM
・同じエラー/メッセージが繰り返されているか：はい/いいえ追加の切り分けヒント：フォーラム回答が来るまでに自力で進められること
受理回答の結論は「専用フォーラムへ投稿し直す」ですが、投稿までに最低限の観点を押さえておくと、回答が来た瞬間に次の作業へ移れます。
監視画面で“更新以外の異常”が出ていないか
- Monitoring でサイトコンポーネントの状態がエラー/警告になっていないか
- サイトシステムステータスで、対象サーバーが正常か（役割が落ちていないか）
- SQL のリソース逼迫やメンテナンス（バックアップ、インデックス）で極端に遅くなっていないか
ディスクとセキュリティ製品（AV/EDR）の影響
- 更新展開で一時ファイルが増えるため、システムドライブだけでなく、コンテンツ/インストール先の空きも確認する
- AV/EDR が更新関連のフォルダをスキャンして極端に遅くなることがある（除外設定は製品/ポリシーに従う）
「長時間」の判断基準をログで作る
“2日進まない”という事実だけでは、第三者は状況を判断できません。次のように、ログ上の事実で言語化すると一気に伝わります。
- 最後に進捗が動いたメッセージと時刻
- その後に同じ処理をリトライしているのか、完全停止しているのか
- エラーコードや例外が出ているなら、その全文（マスク可能な範囲で）
まとめ：ログ＋状態＋投稿先で、更新トラブルは解決が早くなる
SCCM（MECM / ConfigMgr）の更新が“開始したまま2日間進まない”とき、最短ルートは「闇雲に触る」ではなく、正しい質問先に、正しい材料（特に cmupdate.log）を添えて投げることです。専用フォーラムでは、状態（Downloading/Replicating/Installing/Post Installation）とログが揃っていれば、原因候補を一気に絞れます。まずは cmupdate.log の該当範囲を確保し、Prerequisite check 結果と合わせて投稿してください。
コメント