Windows 11でConfiguration Manager（ConfigMgr／旧称SCCM）クライアントが壊れたときは、最初からフォルダーやWMIを削除しないでください。まず管理ポイント到達性、サイト割り当て、クライアント正常性を確認し、改善しない場合にMicrosoft公式のCCMSetup.exe /uninstallで削除してから、組織が指定するクライアントソースで再導入します。手動の「残骸削除」は一般的な標準手順ではなく、ログで残留物が原因と確認でき、かつConfigMgr管理者またはMicrosoftサポートの指示がある場合だけに限定するのが安全です。
この作業はローカル管理者権限を必要とし、アンインストール中はポリシー受信、アプリ配布、ソフトウェア更新、インベントリ、コンプライアンス評価が止まります。業務端末では利用者に停止時間を知らせ、BitLocker回復情報や業務データのバックアップを確認し、メンテナンス時間内に1台ずつ実施してください。端末レコードをコンソールから削除する操作は、クライアントのアンインストールとは別物です。
最短で判断するための症状表
| 見えている症状 | 最初に確認する場所 | 次の判断 |
|---|---|---|
| コントロールパネルにConfiguration Managerがあり、SMS Agent Hostも動く | CcmExec.log、ClientLocation.log、管理ポイント通信 | 通信や割り当ての修正を先に行い、再インストールは後回し |
| Configuration Manager項目はあるが操作が失敗する | クライアント正常性チェック、CcmEval.log、CcmRepair.log | 正常性修復で戻らないときに再導入を検討 |
| SMS Agent Hostが存在しない、または起動不能 | %windir%\ccmsetup\Logs\ccmsetup.logとclient.msi.log | 過去の導入・削除が完了したか確認して公式アンインストール |
| コンソールでClient=Noのまま | 端末側の実体、探索レコード、サイト境界、承認状態 | 端末側だけでなくサイト側の条件も確認 |
| 再導入が同じ箇所で失敗する | 戻り値、失敗直前のログ、証明書・プロキシ・CMG構成 | 同じ削除を繰り返さず管理者へエスカレーション |
作業前に記録しておく情報
再インストールで問題が消えると原因も消えてしまいます。開始前に、端末名、Windowsのエディションとビルド、現在のConfigMgrクライアントバージョン、想定サイトコード、利用すべき管理ポイント、イントラネット／インターネット／CMGのどの経路にいるか、発生時刻、直前のOS展開や更新を記録します。コンソール側では同じ端末に重複レコードや競合レコードがないか、Client列だけで判断せず最終オンライン時刻とサイト割り当ても確認します。
最低限退避したいのは%windir%\ccmsetup\Logsと%windir%\CCM\Logsにある関連ログです。再導入後に上書き・ローテーションされる可能性があるため、障害時刻を含むファイルを読み取り専用の調査場所へコピーします。ログにはサーバー名、ユーザー名、証明書情報などが含まれ得るので、外部の公開サービスへそのままアップロードしないでください。
再インストール前に行う低リスク確認
管理ポイントと配布元への到達性
名前解決、VPN接続、プロキシ、時刻同期、端末証明書、HTTPS検査の影響を確認します。/mp:はCCMSetupがクライアントファイルを得るための管理ポイントを示すパラメーターで、インストール後のサイト割り当てを単独で保証するものではありません。境界グループに端末の現在地が含まれない、配布ポイントにクライアントソースがない、CMG認証が成立しないといった問題は、再インストールしても同じ結果になります。
クライアント正常性とサービス
サービス一覧でSMS Agent Host（CcmExec）の有無と状態を見ます。存在している場合は、むやみにサービスやWMIリポジトリを削除せず、ConfigMgrのクライアント正常性チェックが何を検出・修復したかをCcmEval.logで確認します。修復処理の記録はCcmRepair.logです。ここで回復してポリシー取得が再開するなら、アンインストールによる管理空白を作る必要はありません。
サイト割り当てとコンソール表示
クライアントが入っていてもサイトへ正常に割り当てられるまではコンソールに期待どおり表示されないことがあります。逆に探索だけで端末レコードが存在しても、クライアント導入済みとは限りません。コントロールパネルのConfiguration Manager、ClientLocation.log、LocationServices.log、コンソールのClient列を組み合わせ、端末実体と管理DBの表示を分けて判断します。
公式手順でクライアントをアンインストールする
利用者の作業を終了させ、管理者としてコマンドプロンプトまたはPowerShellを開きます。CCMSetup.exeがある通常の場所へ移動し、Microsoft Learnに記載されたアンインストールを実行します。画面には進捗が出ないため、コマンドが返っただけで完了と見なさず、プロセスとログを確認します。
cd /d %windir%\ccmsetup
CCMSetup.exe /uninstallPowerShellの自動化で後続処理を待たせる場合、MicrosoftはWait-Process CCMSetupを案内しています。ただし既にプロセスが終了している場合の扱いをスクリプト側で考慮し、タイムアウトなしで無期限に待つ運用は避けます。多数端末への一括配布はサイト負荷、ネットワーク、同時管理空白を評価して段階展開してください。
Wait-Process CCMSetupアンインストール完了をログで確認する
確認先は%windir%\ccmsetup\Logs\CCMSetup.logです。Microsoftの管理ドキュメントでも、アンインストールは画面出力ではなくこのログで検証するよう案内されています。終了コードだけでなく、最後にどのフェーズまで進んだか、client.msi.logにMSI失敗がないかを見ます。ログが更新されていないときは、別のCCMSetup.exeを実行していないか、権限昇格できているかを確認します。
アンインストール後もコンソールの端末レコードがすぐ消えるとは限りません。それは管理データであり、端末上のエージェント実体とは別です。逆に、コンソールからレコードを削除しても端末のクライアントは消えず、Heartbeat Discoveryなどで再作成され得ます。履歴や関連付けを失うため、コンソール削除を「再インストールの準備」として安易に行わないでください。
残骸削除を標準手順にしない理由
インターネット上にはC:\Windows\CCM、C:\Windows\ccmsetup、SMSCFG.ini、証明書、タスク、サービス、WMI名前空間をまとめて削除する例があります。しかし、Microsoftの一般向け公式アンインストール手順はCCMSetup.exe /uninstallであり、これらを一律に手動削除する手順ではありません。証明書やWMIを誤って消すと、ConfigMgr以外の管理・監視、端末識別、再登録の根拠まで壊す可能性があります。
残留物を疑う条件は、公式アンインストールが成功した記録があるのに再導入が同じ既存状態を検出する、あるいはMicrosoftサポートが特定ファイルを原因と判断した場合です。その場合でも、削除対象、根拠となるログ行、バックアップ、戻し方を作業票に残し、1項目ずつ扱います。フォルダー全体やWMIリポジトリを再帰削除する汎用コマンドは本記事では勧めません。まずサイト担当者がSupport Centerや公式ログで状態を採取してください。
どうしても手動処置が必要なときの停止条件
- 対象端末が共同管理、BitLocker管理、Endpoint Protection、証明書認証をConfigMgrに依存しているなら、担当者の承認が出るまで止める
- アンインストールログに失敗が残るなら、その失敗を解決せず次の削除へ進まない
- 削除対象がConfigMgr専用か説明できない場合は触らない。特にWMI全体のリセットは行わない
- 再導入ソース、サイトコード、管理ポイント、必要な証明書が準備できていなければ管理空白を作らない
- 複数端末で同時発生しているなら端末固有の残骸より、配布ポイント、境界、証明書、サイト障害を先に疑う
ConfigMgrクライアントを再インストールする
組織の配布方法を優先する
もっとも再現性が高いのは、ConfigMgr管理者が現在のサイト向けに承認したコマンドを使うことです。サイトサーバーのクライアント共有は通常\\<site-server>\SMS_<site-code>\Clientです。Microsoftはclient.msiの直接実行をサポートしておらず、前提コンポーネントや更新を処理するCCMSetup.exeを使うよう明記しています。古い別サイトのClientフォルダーをローカルに保存して再利用しないでください。
\\<site-server>\SMS_<site-code>\Client\CCMSetup.exeActive Directoryにクライアントプロパティが正しく公開され、端末が適切な境界グループにいる環境なら、追加パラメーターなしで自動構成される場合があります。明示が必要な環境では、管理者が指定した/mp:やSMSSITECODE=などを使用します。パラメーターはCCMSetup用のスラッシュ形式を先に、Client.msiプロパティを後に置きます。値を推測せず、既存の標準展開コマンドと照合してください。
CCMSetup.exe /mp:<management-point-fqdn> SMSSITECODE=<site-code>Client Pushを使う場合
コンソールのInstall Clientは選択した端末へクライアントプッシュを行い、再インストールにも使えます。ただし管理共有、ファイアウォール、名前解決、クライアントプッシュ用アカウント、境界など複数の前提があります。手動導入が成功しClient Pushだけ失敗するなら、端末の残骸を再び削除するのではなく、サイトサーバー側のccm.logとプッシュ前提を確認します。
再インストール中に見るログ
| ログ | 示す内容 | 判断例 |
|---|---|---|
ccmsetup.log | ダウンロード、前提条件、セットアップ、削除 | 終了コードと失敗直前のURL／証明書／ソースを確認 |
client.msi.log | Windows Installerによるクライアント本体の処理 | MSIの戻り値とロールバック位置を確認 |
ClientIDManagerStartup.log | クライアントID作成・維持と登録 | GUID作成、登録、証明書選択の異常を確認 |
ClientLocation.log | サイト割り当て関連 | 想定サイトと現在のネットワーク位置を確認 |
LocationServices.log | 管理ポイントや配布ポイントの探索 | 境界と到達先が期待どおりか確認 |
CcmMessaging.log | 管理ポイントとのメッセージ通信 | 認証、HTTP/HTTPS、送受信失敗を確認 |
ログの一行だけを検索して成功・失敗を決めないことが重要です。タイムスタンプを合わせ、同じ実行の開始から終了まで追います。戻り値0でセットアップが終わっても、サイト割り当て、登録、ポリシー受信まで完了したとは限りません。逆にダウンロードの再試行があるだけで即座に破損とは言えません。ネットワーク復旧後に進むか、一定時間同じエラーを繰り返すかを見ます。
導入後の健全性を確認する
- サービスのSMS Agent Hostが存在し、異常終了を繰り返していない
- コントロールパネルのConfiguration Managerで想定サイトコードとクライアント情報が確認できる
- Machine Policy Retrieval & Evaluation Cycleを実行でき、PolicyAgent／PolicyEvaluatorのログが進む
- ClientIDManagerStartup、ClientLocation、CcmMessagingの各ログに継続的な登録・通信エラーがない
- コンソールでClient=Yes、承認、サイト、オンライン状態が時間を置いて更新される
- アプリ配布、インベントリ、更新スキャンなど、その組織が必要とする機能を小さなテストで確認する
再導入直後はコンソール反映やコレクション評価に時間差があります。表示だけを急いで端末レコードを消したり、CCMSetupを連続実行したりしないでください。端末ログで登録とポリシー受信が進んでいるなら、サイトの通常サイクルを待ちます。業務確認では、いきなり大規模アプリを配布せず、小さなポリシー取得や既知のテスト展開から始めます。
失敗時のロールバックとエスカレーション
アンインストール後に再導入できない場合、元の壊れたクライアントへ完全に戻す単純なロールバックはありません。したがって、作業前に正しいインストールソースとネットワーク経路を用意することが実質的な戻し策です。再導入中に変更したプロキシや証明書、ファイアウォール例外は、原因でないと分かった時点で元の管理値へ戻し、恒久的な緩和を残さないでください。
次の場合は端末作業を止めてConfigMgr管理者へ渡します。同一境界の複数端末で同時に失敗する、管理ポイントまたは配布ポイントへ到達できない、PKI／CMG認証で失敗する、MSIが繰り返しロールバックする、WMIや証明書の手動削除が必要に見える、共同管理やセキュリティ機能が停止した、コンソールに競合レコードがある場合です。端末名、実行コマンド、発生時刻、ログ一式、期待サイトを添えると調査が進みます。
よくある質問
ccmsetup /uninstallを実行したのに画面に何も出ません
仕様上、アンインストールの進行状況は画面に表示されません。%windir%\ccmsetup\Logs\CCMSetup.logを確認し、必要ならPowerShellのWait-Process CCMSetupでプロセス終了を待ちます。サービスが消えたことだけではなく、ログ上の完了を確認してください。
C:\Windows\CCMを削除すれば直りますか
一律削除は勧められません。公式アンインストールを完了させ、失敗ログから残留物が原因だと特定してから、管理者やMicrosoftサポートが指定した対象だけを扱います。フォルダー、証明書、WMIをまとめて消すと別の管理機能まで壊す恐れがあります。
再インストールしたのにコンソールでClient=Noです
端末側で登録・割り当て・ポリシー通信が完了しているかを先に見ます。探索レコードだけが残っている、反映待ち、境界グループ不一致、承認や証明書の問題など、コンソール表示以外の原因があります。ClientIDManagerStartup、ClientLocation、CcmMessagingの時系列とサイト側ログを合わせてください。
Windows 11特有の再インストールコマンドがありますか
基本はConfiguration Manager current branchのCCMSetup手順で、Windows 11専用の別アンインストーラーではありません。ただしWindows 11のセキュリティ設定、証明書、ファイアウォール、共同管理、組織のアクセス制御により導入経路は変わります。サイトが承認したコマンドを使うことが重要です。
まとめ
ConfigMgrクライアント再導入は、通信・境界・割り当てを直す、正常性修復を確認する、公式アンインストールをログで完了確認する、承認済みCCMSetupで再導入する、登録とポリシー受信まで検証する、という順序で行います。手動の残骸削除は最初の一手ではありません。削除の根拠と戻し方を説明できない場合は止まり、サイト管理者へログとともにエスカレーションしてください。
コメント