SCCM (Microsoft Endpoint Configuration Manager) は企業内で Windows クライアントやサーバーのソフトウェア配布やパッチ管理を一元化できる頼もしいソリューションです。しかし、ネットワークの状況によってクライアントがインターネット接続かイントラネット接続かを誤って判定すると、配布やポリシー適用が適切に行われず、運用に大きな影響が生じることがあります。本記事では、SCCM クライアントがどのような仕組みで接続先を判断しているのか、また誤判定を起こした際の具体的な対策について詳しく解説します。
SCCMクライアントがインターネット/イントラネット接続を判断する仕組み
SCCM クライアントが自分自身の接続が「イントラネットか」「インターネットか」を判定する際には、複数の要素を総合的に参照します。ここでは代表的なメカニズムについて整理し、実際の設定や運用で押さえておくべきポイントを確認します。
1. Management Point（MP）の可用性
SCCM では、クライアントがサイトサーバーと通信するための窓口となる役割を持つサーバーを「Management Point (MP)」と呼びます。通常、イントラネット用に構成された MP と、インターネットベースでの管理 (IBCM: Internet-Based Client Management) 用に構成された MP を分けて運用するケースがあります。
クライアントはまずイントラネット側の MP にアクセスを試み、それが失敗するとインターネット用 MP にフォールバックするように設定可能です。これにより、イントラネットに接続できる状況であれば自然とイントラネット MP を使用し、接続できなければインターネットとして扱うという判定が行われます。
2. Service Location Management（SLM）キャッシュ
クライアントは、どの MP や配布ポイント (Distribution Point) が利用可能かといった情報をキャッシュとして保持しています。これを SLM キャッシュ (Service Location Management Cache) と呼びます。クライアントが一度イントラネット側の MP から情報を取得すると、接続先情報をしばらくキャッシュに保存し、次回以降の接続で再利用します。
しかし、何らかの理由でこのキャッシュが壊れていたり、古い情報を参照していたりすると、クライアントがイントラネット MP への接続に失敗したと誤認し、インターネット接続を前提とした動作に切り替わる場合があります。問題解消のためには SLM キャッシュをクリアして再取得を促す、またはクライアント再インストールなどのメンテナンスを行うことがあります。
3. ネットワーク ロケーション認識（NLA）
Windows OS の機能である Network Location Awareness (NLA) は、接続中のネットワークが「ドメイン」「プライベート」「パブリック」のどれに属するかを判断する仕組みです。SCCM クライアントはこの情報を参照し、ドメインネットワークであればイントラネット、パブリックネットワークであればインターネットとみなすロジックをもつ場合があります。
具体的には、クライアントが AD ドメイン参加しているかどうかや、DNS サフィックスの一致状況などを確認し、ドメインコントローラとの通信が可能であればイントラネット、そうでなければインターネットとして扱うことが多いです。
4. バウンダリグループ（Boundary Group）
SCCM はバウンダリ (Boundary) という単位でクライアントのネットワーク位置を管理します。バウンダリには、IP サブネットや AD サイト名、IP アドレス範囲などを定義し、それをバウンダリグループ (Boundary Group) にまとめることで、クライアントが属する場所に基づいて適切なサイトシステムを参照する仕組みが構築されます。
イントラネットバウンダリ内にクライアントが属していれば、イントラネット用の MP や配布ポイントを優先的に利用する設定となりますが、バウンダリが誤って設定されていると、クライアントが「自分は社外ネットワークにいる」と判断してしまい、インターネット向けの MP やプロキシを参照しにいく可能性があります。
バウンダリ設定の例
以下のようなテーブルを用いて、バウンダリ設定を管理します。たとえばサブネットベースの設定を行いたい場合、クライアントが属する IP サブネットを明確に定義しておくことで誤認識を防ぐことができます。
| バウンダリ名 | バウンダリタイプ | 設定例 (IP アドレス範囲) | 備考 |
|---|---|---|---|
| HQ_Subnet | IP Subnet | 192.168.0.0/24 | 本社オフィス用 |
| Branch_Subnet | IP Subnet | 10.10.10.0/24 | 支社オフィス用 |
| VPN_Subnet | IP Subnet | 172.16.100.0/24 | VPN クライアント接続用 |
これらをまとめたバウンダリグループで、イントラネット用とインターネット用の参照先 MP を使い分けることが重要です。
5. フォールバックステータスポイント（Fallback Status Point: FSP）
クライアントが MP と通信できなくなった場合、あるいは SCCM のクライアントエージェントをインストールした直後などに、ステータス情報 (エラーログやインストールログ) を送信する際に利用できるのがフォールバックステータスポイント (Fallback Status Point) です。
FSP への通信が成功するかどうかも、クライアントにとっては自分がどこにいるかを判断する際の間接的な材料となります。もしイントラネット側にしか存在しない FSP と通信できない場合、結果的にクライアントは「インターネットにいる」と判断せざるを得なくなる可能性があります。
6. クライアント設定とネットワーク構成
SCCM クライアントが HTTPS 通信を利用している場合、証明書 (PKI) の設定や DNS 名の整合性が非常に重要です。例えば、証明書の発行先にイントラネット用の FQDN が含まれており、かつその FQDN による名前解決ができなければ、クライアントはイントラネットを正しく認識できません。
また、クライアントインストール時のプロビジョニングモード（ネイティブモードや HTTPS モードなど）の設定が不適切な場合にも、誤った接続判定を起こすリスクがあります。
SCCMクライアントが誤ってインターネット接続と判断する場合のトラブルシューティング
クライアントが本来はイントラネット上にいるにもかかわらず、誤ってインターネット接続として扱われてしまうと、プロキシサーバを経由しようとして失敗したり、イントラネット用のポリシーやコンテンツが配布されなかったりと、さまざまなトラブルが生じます。ここでは、具体的なトラブルシューティング手順を紹介します。
1. 証明書設定・プロビジョニングモードのチェック
クライアントが HTTPS モードの場合、まずはクライアント証明書が正しくインストールされているか、証明書チェーンや失効リストに問題がないかを確認します。以下は Windows の証明書管理画面で確認する手順の例です。
# 証明書のインストール状況を確認する場合の例
Get-ChildItem Cert:\LocalMachine\My | Where-Object {
$_.Subject -like "*client.domain.local*"
}- もし目的の証明書が存在しなかったり、有効期限切れだったりする場合は、PKI の管理者に問い合わせるか、新しい証明書を再発行する必要があります。
- 「IsSslClientAuthEnabled – Determining provisioning mode state failed with 80070002…」のようなエラーがログに記録されている場合は、クライアントインストール時の設定ファイルやレジストリ値を再確認しましょう。
2. バウンダリグループの再確認
バウンダリ設定に誤りがあると、クライアントが適切なサイトシステムを参照できません。特にサブネットマスクや IP アドレスの範囲設定が漏れていたり間違っていたりすると、同一ネットワーク内のはずがバウンダリ外と判断される事態が起こります。
SCCM コンソールの「Administration」>「Hierarchy Configuration」>「Boundary Groups」から、問題が生じているクライアントの IP アドレスやサブネットが正しいバウンダリに含まれているかをチェックしてください。
3. NLA (Network Location Awareness) の状態を精査
Windows サーバーやクライアント OS がどのネットワークプロファイルを使っているかによって、SCCM クライアントの挙動にも影響が出ます。
- ドメインコントローラとの通信が正常にできるか
- DNS サフィックスが正しく設定されているか
- グループポリシーで余計なネットワークプロファイル強制がかかっていないか
こうした点を確認したうえで、同じサブネット内で正常に動作している他のサーバやクライアントとの比較を行うと、設定の差分を洗い出しやすくなります。
4. ログファイル解析で原因を特定
SCCM クライアント関連のトラブルシューティングでは、以下のログファイルが特に有用です。
- ccmsetup.log: クライアントエージェントのインストールに関する情報とエラーが記録される。
- ClientLocation.log: クライアントが現在どのようにサイトロケーションを検出しているかがわかる。
- LocationServices.log: 実際にどの MP に接続しようとしているのか、バウンダリやインターネット/イントラネットの判定がどのように行われているかを確認できる。
ログを確認する際は、エラーメッセージやワーニングを検索キーワードにして集中的に追いかけるのがポイントです。誤った接続先を選択している理由や、証明書の参照エラーなどを読み解く手がかりとなります。
ログ解析の具体例
たとえば、以下のようなログメッセージが出力されていたとします。
IsSslClientAuthEnabled - Determining provisioning mode state failed with 80070002. Defaulting to state of 31.
Client is on internetここで注目すべきは「IsSslClientAuthEnabled」というフラグの取得に失敗しており、デフォルト動作として「インターネット接続」と判定されている点です。このようなケースでは、クライアント証明書のインストールに問題があるか、インストール時のプロビジョニングモードが適切に設定されていない可能性が高いです。
5. クライアントエージェントの再インストール・再登録
アップグレードやパッチ適用のタイミングでクライアント構成ファイルが不整合を起こし、誤ったステータスのまま動作することもあります。
- クライアントエージェントをアンインストールし、キャッシュやレジストリの残存情報をクリアする
- 改めて正しいパラメータで ccmsetup.exe を実行し、クライアントを登録し直す
こうしたプロセスによって環境が正常化し、イントラネットとして正しく認識されるようになることがあります。
6. 証明書サービスやネットワークインフラ側の調整
SCCM 側の設定だけでなく、AD CS (Active Directory Certificate Services) やロードバランサ、ファイアウォール設定など、ネットワークインフラ全体も見直しが必要な場合があります。特に以下のような点に留意してください。
- クライアント証明書の自動更新が失敗していないか
- ルート証明書が有効な期間内に収まっているか
- ロードバランサ配下での SSL 設定に問題がないか
- ドメインコントローラや DNS の応答が遅延していないか
イントラネット環境における信用の基盤が崩れていると、SCCM クライアントが「自分はドメイン内にいないのでは？」と勘違いしてしまうことにつながります。
ネットワークテストのスクリプト例
例えば、クライアントからドメインコントローラや MP サーバーへの疎通を PowerShell でテストする場合は以下のように実行できます。
# ドメインコントローラの名前解決とPINGテスト
$domainController = "dc01.domain.local"
Resolve-DnsName $domainController
Test-Connection $domainController -Count 2 -Quiet
# Management Pointの疎通確認（HTTPSポート443の場合）
$mpServer = "mp01.domain.local"
Test-NetConnection $mpServer -Port 443これらの結果から、名前解決やTCP接続が正常かを検証し、問題箇所を切り分けます。
まとめと運用上のポイント
SCCM クライアントが誤ってインターネット接続と判定されると、MP へのアクセスやポリシー配信などの基本動作に支障をきたすため、早急な原因特定と対処が求められます。
運用上は以下のポイントを意識しておきましょう。
- バウンダリグループの定期的な見直し
新しいサブネットや拠点が追加された際には、きちんとバウンダリグループを更新し、クライアントが正しい範囲に属するようにメンテナンスを行う。 - 証明書のライフサイクル管理
HTTPS モードを利用している場合、クライアント証明書の有効期限や失効リスト (CRL) が常に適切な状態であるかを確認する。 - ログ解析の体制強化
SCCM のログ出力先や重要なログファイルの意味をチーム全体で共有し、トラブルシュートの効率を高める。 - ネットワークインフラとの連携
ネットワークチームと連携して、ファイアウォールやロードバランサの設定、DNS の正引き・逆引きなどを定期的にレビューする。
これらの対策を継続的に行うことで、クライアントのインターネット/イントラネット判定が安定し、SCCM を活用したソフトウェア配布やパッチ管理が円滑に進むことでしょう。
コメント