Windows 11 へのアップグレードは避けて通れない一方で、SCCM クライアントや証明書まわりのトラブルは「原因が見えにくい」「再現性が低い」という特徴があります。本記事では、実際の現場で遭遇しやすい 2 つの問題――SCCM クライアント証明書の消失と、Windows 11 23H2/24H2 におけるユーザー証明書自動登録の不具合――をまとめて整理し、再現手順ではなく運用に組み込みやすい対処・検証のポイントを詳しく解説します。
Windows 11 アップグレード後に SCCM クライアント証明書が消失し、SMS サービスが無効になる問題
想定シナリオと前提環境
まずは 1 つ目の事例から整理します。本記事で取り上げるのは、以下のような環境を想定したケースです。
- SCCM（Microsoft Endpoint Configuration Manager）でタスクシーケンスを組み、Windows 10 から Windows 11（23H2）へインプレースアップグレード
- クライアント認証にはコンピュータ証明書を使用（PKI 環境）
- アップグレード後に、一部クライアントでのみ SCCM クライアントが完全に沈黙
アップグレード直後の問題としてよくあるのはポリシー未適用や WMI の不整合ですが、ここで焦点となるのは次の 2 点です。
- SMS Agent Host（
CCMExec）サービスのスタートアップの種類が「無効」になっている certlm.mscで確認できるはずの SCCM クライアント用コンピュータ証明書が消えている
発生している症状の整理
現場での切り分けをしやすくするため、典型的な症状を表にまとめます。
| 項目 | 正常なクライアント | 問題発生クライアント |
|---|---|---|
| SMS Agent Host（CCMExec）サービス | スタートアップの種類: 自動 / 状態: 実行中 | スタートアップの種類: 無効 / 状態: 停止 |
| クライアント証明書（コンピュータ） | certlm.msc の [個人] ストアに表示 | 該当証明書が存在しない |
| SCCM コンソールからの状態 | アクティブ / クライアント=はい | クライアント=いいえ / ハートビートが古い |
| クライアント自己修復 | ポリシー更新・自己修復で復旧可能 | 証明書がないため自己修復も開始されない |
ここまで揃うと、単純なポリシートラブルというよりは「アップグレード過程で SCCM クライアントが中途半端な状態になった」と判断するのが自然です。
なぜアップグレードで SCCM クライアント証明書が消えるのか（考えられる要因）
本事象の原因は環境ごとに異なりますが、代表的な要因として次のようなものが考えられます。
- インプレースアップグレード中に CCMExec や関連サービスが停止したまま再設定されなかった
- ドメイン参加情報やコンピューター SID の扱いにより、証明書のサブジェクト名や SAN（Subject Alternative Name）が整合しなくなった
- アップグレード中の一時的なプロファイル・ポリシー適用不整合により、自動登録済みの証明書がクリーンアップ対象として扱われた
特に、ドメインとの紐づき と 証明書テンプレートの条件（サブジェクト名＝DNS 名 など）がシビアな環境では、アップグレードタイミングで「別マシン扱い」されるような状態になり、既存証明書が無効認定 → クリーンアップ、という挙動になりがちです。
このような状況になった場合、SCCM クライアントの自己修復機構は「すでに信頼されたチャネルがある」という前提で動くため、そもそも証明書が無い状態では復旧処理まで到達できません。そのため、クライアント側で一度状態をリセットし、ドメインと PKI の両方から見て「新規端末」として再登録してもらう必要が出てきます。
実施した対処手順（再現性の高いパターン）
ここでは、実際に復旧に成功した一連の手順を、目的ごとに区切って解説します。ポイントは以下の 3 ステップです。
- ドメイン離脱・再参加とローカル証明書キャッシュの整理
- グループポリシーと証明書自動登録の再実行
- SCCM クライアントの完全再インストール
1. ドメイン再参加と証明書キャッシュ削除
まず、端末のドメイン参加状態をリセットします。これは「同じ名前の別マシン」のような半端な状態を解消する意味があります。
- PC をドメインから離脱（ワークグループに参加）
- 再起動
- 再度、同じドメインに参加
そのうえで、証明書キャッシュを整理します。ユーザー証明書ではなく、SCCM で利用しているストアに着目してください。
certmgr.mscを開き、不要な 個人証明書 を削除- 必要に応じて
certlm.msc（ローカル コンピュータ）側も確認し、不整合な証明書がないかチェック
ここでの狙いは「古い SID やドメイン情報と紐づいている証明書」を整理し、新しくクリーンな状態で再発行させる土台を作ることです。
2. グループポリシー再適用と自動登録トリガ
ドメイン再参加が完了したら、GPO による証明書自動登録を即座に走らせます。管理者権限のコマンドプロンプトまたは PowerShell で、次のコマンドを順に実行します。
gpupdate /force
certutil -pulse
gpupdate /force… コンピュータ・ユーザー両方のポリシーを強制再適用certutil -pulse… 証明書の自動登録（Auto-Enrollment）を手動トリガ
この後、数分待ってから certlm.msc を開き、SCCM クライアントで使用しているテンプレート由来のコンピュータ証明書が再発行されているか確認します。
3. SCCM クライアントの完全再インストール
証明書の再取得が確認できたら、SCCM クライアント自体を再インストールします。ポイントは「上書きインストールではなく、一度きれいにアンインストールすること」です。
管理者権限のコマンドプロンプトで、次のコマンドを実行します。
cd C:\Windows\CCMSetup
ccmsetup.exe /uninstall
アンインストール完了後に PC を再起動し、その後 SCCM コンソール側から「クライアントのインストール（クライアントプッシュ）」を実行します。もしくは、クライアント インストール用のスクリプトを配布している場合は、それを手動で実行しても構いません。
再インストール後、以下の点を確認します。
- サービス:
SMS Agent Hostのスタートアップの種類が「自動」、状態が「実行中」になっている - 証明書: コンピュータ証明書ストアに SCCM 用の証明書が 1 つ存在し、有効期限やサブジェクト名が正しい
- クライアント状態: SCCM コンソールで「クライアント＝はい」「アクティブ」になっている
なお、配布ポイント（DP）用の証明書がクライアント側に表示されない場合がありますが、基本的にクライアント機能には影響しません。重要なのは、管理ポイント・配布ポイントとの通信に使う コンピュータ証明書 が正しく存在していることです。
この問題は「ユーザー証明書バグ」とは別系統
ここまでの事象は、後半で解説する「Windows 11 23H2/24H2 におけるユーザー証明書の自動登録バグ」とは別物です。
- 今回の事象: インプレースアップグレードの過程で SCCM クライアントが壊れ、コンピュータ証明書が消失
- 後半の事象: Windows 11 側の Credential Roaming 周りの不具合により、ユーザー証明書だけが自動登録されない
環境によってはコンピュータ証明書のみで SCCM 通信が完結するため、ユーザー証明書の問題があっても SCCM 運用に直接の影響が出ない場合があります。逆に、VPN や Wi-Fi の EAP-TLS 認証でユーザー証明書を使っている環境では、後半の問題のインパクトが非常に大きくなります。
Windows 11 23H2/24H2 でユーザー証明書の自動登録が失敗するバグ
現象の特徴と切り分けのポイント
次に、Windows 11 23H2/24H2 で顕在化するユーザー証明書の自動登録（Auto-Enrollment）問題について整理します。代表的な特徴は以下の通りです。
- Windows 10 では問題なくユーザー証明書が自動配布されている
- 同じ GPO・同じ証明書テンプレートを使っているにもかかわらず、Windows 11 23H2/24H2 では ユーザー証明書だけ発行されない
- コンピュータ証明書は Windows 11 でも正常に自動登録される
- VPN（EAP-TLS）、Wi-Fi（EAP-TLS）、RDP NLA など、ユーザー証明書ベースの認証が軒並み失敗
切り分けの第一歩は、「PKI や GPO 設定の問題なのか、Windows 11 固有の問題なのか」を見極めることです。以下の観点でチェックすると判定しやすくなります。
| 確認項目 | 期待される結果 | 確認方法 |
|---|---|---|
| コンピュータ証明書の自動登録 | Windows 10 / 11 いずれも正常に発行される | certlm.msc → [個人] ストア |
| ユーザー証明書の自動登録 | Windows 10 のみ正常、Windows 11 では発行されない | certmgr.msc → [個人] ストア |
| GPO の適用状況 | Windows 10 / 11 ともに同じ GPO が適用 | gpresult /h report.html で比較 |
| CA 側の発行状況 | Windows 11 端末からの要求が記録されていない or エラーで棄却 | 証明機関の発行履歴・失敗ログを確認 |
ここで、「Windows 11 からはそもそもユーザー証明書の要求が CA に届いていない」場合、クライアント OS 側で何らかの理由により自動登録処理がキャンセルされていると考えるのが自然です。
原因：Credential Roaming と KSP パラメータの不具合
Windows 11 23H2/24H2 では、ユーザー証明書の自動登録処理に関与する Credential Roaming の内部処理に不具合があるとされています。特に、次のような条件が揃うと発生しやすくなります。
- ユーザー証明書のテンプレートで 「重複証明書があっても自動再登録しない」 オプションを有効にしている
- CNG/KSP（Key Storage Provider）方式のテンプレートを利用している
- 複数端末から同一ユーザーでログオンしている、あるいは過去にしていた履歴がある
内部的には、暗号化プロバイダーのパラメータ（使用する MAC アルゴリズムや暗号化アルゴリズム）が正しく設定されず、その結果として クライアント側で証明書要求が棄却される 形になっていると考えられます。表面的には「CA に要求が届かない」「イベントログに自動登録のエラーが残りにくい」という、非常に追いかけづらい症状になりがちです。
回避策・暫定対応の比較
この問題に対する現実的な対処は、大きく次の 3 つのパターンに分類できます。
| 方法 | 利点 | 欠点・注意点 |
|---|---|---|
| 1. 証明書テンプレートのオプション変更 「重複があっても自動再登録しない」を無効化 | 設定変更だけで即座に効果が出やすい GPO を変えずに CA 側だけで対応可能 | 同じユーザーが複数端末を使うと、重複証明書が大量に発行される 証明書の棚卸し・失効管理が煩雑になる |
| 2. レジストリ修正をクライアントに配布（推奨） | 「重複があっても自動再登録しない」オプションを維持したまま動作を安定させられる GPO で一括配布しやすい | OS 側の修正パッチが安定配信された後は不要となるため、削除タイミングを決めておく必要がある 暗号化アルゴリズム指定のレジストリ変更であるため、セキュリティポリシー上の説明が必要 |
| 3. 2025 年 7 月以降の累積更新プログラムを適用 | OS 側の根本修正により、テンプレートやレジストリに依存しない安定運用が期待できる | 環境によっては 7 月 CU だけでは安定せず、8 月以降の CU まで検証が必要なケースがある パッチ適用だけでは既存の壊れた状態（失敗した自動登録）が復旧しない場合もあり、再トリガが必要 |
方法 1：証明書テンプレートのオプションを緩和する
最も手早い対処は、ユーザー証明書テンプレートのプロパティで設定されている「重複証明書があっても自動再登録しない」に相当するオプションをオフにする方法です。
- CA 管理コンソールで対象テンプレートのプロパティを開く
- 重複回避に関するオプションを確認し、重複があっても再登録を許可する設定に変更
- テンプレートの再発行・再読み込みを実施
この方法は、Windows 11 側にレジストリを触らずに済む という意味で保守性が高い一方、同じユーザーが複数端末を利用する環境では、証明書がどんどん増えていきます。その結果、証明書一覧の管理が難しくなり、「どれが現役で、どれが不要なのか」が判別しづらくなるデメリットがあります。
短期間の暫定対応としては有効ですが、長期運用を考えると、後述のレジストリ修正や OS パッチ適用と組み合わせて、いずれは再度オプションをもとに戻す方針を検討するのが現実的です。
方法 2：レジストリ修正をクライアントに配布（推奨）
次に、Credential Roaming の暗号化スイートを明示的に指定するレジストリ修正です。これは「古い KSP 互換モードを復活させる」イメージで、Windows 11 の不具合部分を迂回させるものです。
対象となるレジストリキーは以下です。
キー:
HKLM\SOFTWARE\Microsoft\Cryptography\Protect\Providers\{df9d8cd0-1501-11d1-8c7a-00c04fc297eb}
値:
"MAC Alg" = dword:00008004 （SHA-1 HMAC）
"Encr Alg" = dword:00006603 （3DES）
これらの値を GPO の「レジストリの設定」や構成管理ツール（SCCM、Intune など）で一括配布することで、Credential Roaming の処理に必要な暗号化パラメータが明示され、自動登録処理が安定しやすくなります。
セキュリティ面での注意 としては、以下の点をドキュメント化しておくとよいでしょう。
- このレジストリ変更は、あくまで Windows 11 の不具合を回避するための暫定措置であること
- 現時点ではセキュリティ上の重大な懸念は報告されていないが、将来的に非推奨・削除される可能性があること
- OS の累積更新プログラムによる根本修正が十分に検証された段階で、レジストリを撤去する計画をあらかじめ決めておくこと
運用上は、次のようなステップで導入するとスムーズです。
- テスト OU を作成し、数台の Windows 11 端末でレジストリ配布を試験
- ユーザー証明書の自動登録が正常に行われるか、
certutil -pulseでトリガしながら確認 - VPN / Wi-Fi の EAP-TLS 認証が成功することを複数パターンで検証
- 問題がなければ、本番 OU に段階的にレジストリ配布を展開
方法 3：累積更新プログラムによる恒久対応
最後に、2025 年 7 月以降の累積更新プログラムによる根本修正です。将来的には、OS 側で Credential Roaming 周りの不具合が修正されることが前提となるため、最終的なゴールは「レジストリ回避策が不要な状態」に置くべきです。
ただし、実際の現場では次のような点に注意が必要です。
- パッチ適用だけでは、すでに失敗したまま止まっている自動登録処理が復活しない場合がある
- パッチ適用後に
gpupdate /forceとcertutil -pulseを併用して、明示的に自動登録を再トリガすることが望ましい - 本番展開前に、パイロット端末で十分な検証期間を設けること
また、レジストリ回避策を併用している環境では、「パッチ適用 → 正常動作を確認 → 段階的にレジストリを削除」という 3 ステップで慎重に移行することをおすすめします。
関連トラブルと追加ヒント
Wi-Fi の EAP-TLS だけ認証失敗する場合
ユーザー証明書は正しく自動登録されているにもかかわらず、「Wi-Fi の EAP-TLS 認証だけ失敗する」というケースもよくあります。Windows 11 では、ワイヤレスプロファイルに設定する ルート CA 証明書の拇印 の扱いがシビアになっており、古い拇印が残ったままだと認証に失敗することがあります。
切り分けのポイントは以下の通りです。
- Wi-Fi プロファイルで指定されているルート CA の拇印と、実際にクライアントにインストールされているルート CA 証明書の拇印が一致しているか
- ルート CA を更新した場合に、古い拇印がプロファイル側に残っていないか
- 同じアカウントで Windows 10 端末に接続すると正常に認証できるか
この問題は、ユーザー証明書の自動登録とは別のレイヤーで発生しますが、症状として「Wi-Fi がつながらない」としか報告されないことが多く、見落とされがちです。
テンプレートが KSP（Key Storage Provider）方式の場合の注意
ユーザー証明書のテンプレートが KSP 方式（例: 「Microsoft Software Key Storage Provider」）になっている場合、プロバイダの制限により自動登録がスキップされるケースがあります。
次のような検証を行うと、原因切り分けに役立ちます。
- 一時的に プロバイダ制限を緩和 し、別の KSP を利用可能にする
- テンプレートのコピーを作成し、シンプルな設定で自動登録を試す
- Windows 10 と Windows 11 で同一テンプレートを利用した場合の挙動を比較する
もし KSP 設定を変更したテンプレートでのみ自動登録が成功する場合は、Windows 11 と既存テンプレートの組み合わせに問題がある可能性が高くなります。
グループポリシー適用確認と証明書の確認コマンド
ユーザー証明書の自動登録トラブルシュートでは、「GPO が本当に適用されているのか」「証明書ストアには何が入っているのか」をコマンドで確認しておくと効率的です。
gpresult /h report.html <-- 適用 GPO を HTML で確認
certutil -store my <-- ユーザーの個人ストアを一覧表示
certutil -pulse <-- 自動登録処理を手動でトリガ
特に certutil -store my の結果は、スクリプトでパースしてログ収集することもできます。大規模環境では、「どの端末でどのテンプレートの証明書がいつ発行されているか」を可視化しておくことで、問題が起きたときの影響範囲を素早く把握できます。
SCCM・証明書トラブルに強くなる運用設計のポイント
アップグレード前にやっておくべき棚卸し
Windows 11 への移行プロジェクトを進める前に、次の項目を棚卸ししておくと、今回のようなトラブルの影響を最小限に抑えられます。
- どの業務がユーザー証明書に依存しているか
VPN、Wi-Fi、RDP、各種 Web アプリのクライアント証明書認証など。 - 証明書テンプレートごとの用途と有効期限
「ユーザー認証用」「クライアント認証＋メール暗号化」などを整理。 - SCCM クライアントが利用する証明書テンプレート
コンピュータ証明書のみか、ユーザー証明書も使う構成か。 - 重複証明書をどう扱うか
テンプレートの重複回避オプションと、失効・削除のポリシーを文書化。
パイロット展開と段階的ロールアウト
証明書まわりの問題は、全社展開してから初めて表面化すると致命的です。そこでおすすめなのが、用途別のパイロットグループ を作ることです。
- VPN ヘビーユーザー（リモートワーカー・出張者）
- Wi-Fi 依存度が高いユーザー（ノート PC の常用者）
- 開発・検証用端末（多種多様な証明書が入っているマシン）
- SCCM / Intune 管理端末（管理者用 PC）
それぞれのグループで Windows 11 23H2/24H2 へのアップグレードを段階的に行い、以下の観点でチェックします。
- アップグレード直後に SCCM クライアントが正常稼働しているか
- ユーザー証明書が自動登録されているか（
certmgr.mscやcertutil -storeで確認） - VPN・Wi-Fi・業務アプリへの接続に問題がないか
このフェーズで問題が見つかった場合、証明書テンプレートの見直しやレジストリ回避策の適用などを行い、本番展開に向けた「標準パターン」として固めていくと、後戻りが少なくなります。
運用ドキュメントに必ず書いておきたい 3 つの項目
証明書・SCCM クライアントのトラブルは、担当者が変わるとノウハウが失われがちです。次の 3 点は、必ず運用ドキュメントに明記しておくことをおすすめします。
- レジストリ回避策の内容と撤去条件
どのキーに何を設定しているのか、何のために入れたのか、どのタイミングで撤去するのか（例: 所定の CU を適用し、一定期間問題が出なければ削除）を明記します。 - 証明書テンプレートの設定方針
「重複証明書を許可するか」「どの用途でどのテンプレートを使うか」「更新期限前に何日前から自動再登録させるか」などをルール化します。 - トラブルシュートの標準手順
本記事で紹介したコマンドや確認ポイント（gpresult、certutil、SCCM クライアントの再インストール手順など）を、チェックリスト形式でまとめておきます。
まとめ：SCCM クライアントとユーザー証明書バグへの向き合い方
最後に、本記事で扱った 2 つの問題と対処方針を整理します。
- SCCM クライアントが起動しない問題
Windows 10 → Windows 11 へのインプレースアップグレード後に、SCCM クライアント証明書が消失し、SMS Agent Host（CCMExec）が無効化されるケースでは、以下の手順が有効です。- PC をドメインから離脱 → 再参加し、証明書キャッシュを整理
gpupdate /forceとcertutil -pulseで GPO と自動登録を再実行ccmsetup.exe /uninstallでクライアントを完全アンインストール → 再インストール
- ユーザー証明書が自動配布されない Windows 11 のバグ
Windows 11 23H2/24H2 でユーザー証明書の Auto-Enrollment が失敗する問題は、Credential Roaming と KSP のパラメータ不具合が絡んだ OS 側の問題と考えるのが自然です。対応の優先度としては次の順番を推奨します。- 証明書テンプレートの「重複があっても自動再登録しない」設定の見直し
- Microsoft 推奨レベルのレジストリ修正を GPO 等で配布し、不具合を回避
- 2025 年 7 月以降の累積更新プログラムを適用し、OS 側の恒久修正に移行
いずれの対処を行う場合も、重複証明書の整理 と レジストリ回避策をいつ撤去するのか を運用手順に組み込んでおくことが重要です。これにより、Windows 11 のアップグレードや今後の機能更新が行われた際にも、証明書と SCCM クライアントまわりのトラブルを最小限に抑えることができます。
Windows 11 への移行は一度きりではなく、今後も 23H2、24H2 といった機能更新のたびに繰り返されます。今回の知見を「一過性の対処」で終わらせず、標準運用として蓄積しておくことで、将来の移行プロジェクトやトラブルシュートの大きな武器となるはずです。
コメント