MECM（SCCM）2010へアップグレード後、「コンソールではクライアントが 5.00.9040.1015 と表示されるのに、コレクションのクエリでは 5.00.9040.1010 までしか選べず、手入力しても0件」という現象の原因と、正しいWQLの作り方を実務目線で整理します。
MECM / SCCM 2010で「クライアント バージョンがクエリで選べない」現象を整理する
アップグレード直後の環境で、次のような食い違いが起きることがあります。
| 見えている場所 | 表示・挙動 | 直感的な解釈 | 実際に起きていること |
|---|---|---|---|
| 管理コンソール（デバイス一覧など） | クライアント バージョンが 5.00.9040.1015 | 「1015が展開済み」 | クライアント本体のバージョンを参照している |
| コレクションのクエリ 〜 値の選択（候補） | 最大が 5.00.9040.1010 まで | 「1015が存在しない？」 | 参照クラスが別物で、候補の作られ方も違う |
| クエリ条件に 5.00.9040.1015 を手入力 | 結果が0件 | 「展開失敗？」 | そもそもその値を持つレコードが無いクラスを見ている |
ここで重要なのは、「クライアント バージョン」という言葉が、どのデータを見ているかで意味が変わることです。MECM/SCCMは内部的に、端末情報を複数の“器”に分けて保持しています。クエリが参照している器を取り違えると、今回のように「表示は1015なのに検索では出ない」というズレが生まれます。
結論：クライアント本体のバージョンで絞り込むなら「SMS_R_System.ClientVersion」
先に結論だけ押さえると、次の整理になります。
クライアント本体のバージョン（例：5.00.9040.1015）でデバイスコレクションを作りたい
- 使用すべきクラス：SMS_R_System
- 参照すべきプロパティ：ClientVersion
コンポーネント（エージェント部品）ごとのバージョン差を追いたい
- 使用することがあるクラス：SMS_G_System_SMS_ADVANCED_CLIENT_STATE など
- ただし、これはクライアント本体のバージョンそのものとは一致しないことがある
今回の「1015を条件にしても0件」「候補に1015が出ない」は、クライアント本体ではなく“コンポーネントのバージョン”を見ていたことが原因です。
なぜ起きる？原因は「参照しているクラスがコンポーネントのバージョン」だった
問題になっていたクエリが参照していたのが、次のクラスです。
- SMS_G_System_SMS_ADVANCED_CLIENT_STATE
このクラスは、端末が報告したクライアントの状態（Advanced Client State）に近い情報を持ち、実体としてはクライアントを構成する各コンポーネント（部品）の情報を持ちます。つまり、ここで扱っているのは「クライアント本体のバージョン」ではなく、部品ごとのバージョンです。
そのため、次のようなことが起こります。
- コンソールで見える「クライアント バージョン」＝クライアント本体のバージョン（ClientVersion）
- SMS_G_System_SMS_ADVANCED_CLIENT_STATEが持つ値＝コンポーネントのバージョン
- コンポーネント側が 5.00.9040.1010 までしか存在しない（あるいは収集がそこまで）なら、クエリ候補の最大も1010になる
- そこに 5.00.9040.1015 を手入力しても、一致するレコードが無いため0件
ここで誤解しやすいポイントは、「1015が存在するのに検索できない」のではなく、検索対象のテーブル（クラス）に“1015という値自体が存在しない”という構造になっていることです。クエリは正直なので、存在しない値を指定すると正しく0件になります。
クライアント本体とコンポーネントは“粒度”が違う
MECM/SCCMクライアントは、単一のexeやdllだけで完結しているわけではなく、複数のコンポーネントで構成されています。サイト更新やホットフィックス適用の影響で、
- コンソールが表示する「クライアント本体のバージョン」
- インベントリ/状態クラスに並ぶ「コンポーネントのバージョン」
が完全に一致しないことは珍しくありません。特に末尾のビルド番号は、更新の入り方によって差が出やすい領域です。
正しいクラス：SMS_R_System の ClientVersion を使う（WQL例あり）
クライアント本体のバージョン（例：5.00.9040.1015）でコレクションを作りたい場合は、SMS_R_System を参照します。これはいわゆる“ディスカバリ系”のクラスで、端末の基本情報を持ち、コンソールの表示とも整合が取りやすい領域です。
WQLクエリの例は次の通りです。
select
SMS_R_SYSTEM.ResourceID,
SMS_R_SYSTEM.ResourceType,
SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier,
SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client
from SMS_R_System
where SMS_R_System.ClientVersion = "5.00.9040.1015"この形で作ると、コンソール上で「クライアント バージョン 5.00.9040.1015」と見えている端末を、そのまま素直に集められます。
実務でよく使う：クライアントが入っている端末だけに絞る
環境によっては、ディスカバリにより未管理端末が混ざることがあります。意図として「クライアントが導入済みの端末だけ」を対象にするなら、次の条件も併用しやすいです。
select
SMS_R_SYSTEM.ResourceID,
SMS_R_SYSTEM.Name
from SMS_R_System
where SMS_R_System.Client = 1
and SMS_R_System.ClientVersion = "5.00.9040.1015"これにより、Client = 1（クライアントあり）かつ特定バージョン、という実運用に沿った集合になります。
コンソールの表示とクエリ結果がズレる理由を“データの出どころ”で理解する
今回のポイントは「バージョンが違う」ではなく、参照している情報源が違うことです。よく混同されるので、データの種類を表で整理します。
| 分類 | クラス名の傾向 | 主な用途 | 今回の“バージョン”の意味 | 向いているケース |
|---|---|---|---|---|
| ディスカバリ（Discovery） | SMS_R_〜 | 端末の基本情報・管理状態 | クライアント本体のバージョン（ClientVersion） | 特定バージョンの端末をコレクション化、展開対象の絞り込み |
| ハードウェア/状態系（Inventory/State） | SMS_G_System_〜 | 収集した詳細情報（コンポーネントや製品情報など） | コンポーネントのバージョンになりやすい | 部品単位の差異追跡、特定エージェントの不整合調査 |
「クエリ ビルダーでバージョン候補が1010までしか出ない」のは、ビルダーがそのクラスに存在する値を候補として列挙しているためです。クラス側に1015が無ければ、候補にも出ませんし、手入力しても一致しません。
クエリ ビルダーでの作成手順：表示されない値は“クエリ言語の表示”で確実に指定する
ConfigMgr コンソールでは、コレクションの「クエリ ルール」を作成するとき、GUI操作だけで条件を組むことが多いと思います。しかし今回のように、
- ドロップダウンの候補に欲しい値が出ない
- 選べるクラスを間違えやすい
というケースでは、WQLを直接貼り付けて作るのが最短・確実です。
- デバイス コレクションを作成（または既存を右クリック）し、プロパティを開く
- メンバーシップ ルールのタブで、クエリ ルールを追加
- クエリ ステートメントの編集 → クエリ ビルダーを開く
- 右側（または下部）の 「クエリ言語の表示」 をクリック
- 表示されたWQL欄に、次のような SMS_R_System + ClientVersion のクエリを貼り付ける
- OKで戻って保存し、コレクション更新を待つ（または手動更新）
select
SMS_R_SYSTEM.ResourceID,
SMS_R_SYSTEM.ResourceType,
SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier,
SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client
from SMS_R_System
where SMS_R_System.ClientVersion = "5.00.9040.1015"GUI上で「クラス選択」を間違えるのが一番の落とし穴なので、最初からWQLを固定してしまうのが運用として強いです。特に、サイトアップグレード後の移行期間（旧クライアントと新クライアントが混在する期間）では、コレクション設計がそのまま作業効率と事故率に直結します。
よくある誤り：SMS_G_System_SMS_ADVANCED_CLIENT_STATE を“クライアント バージョン”として使ってしまう
なぜこの誤りが起きやすいかというと、クエリ ビルダーの画面上で、
- 「クライアント」っぽい名前のクラスが複数ある
- “Advanced Client”という名称が、歴史的にクライアント全体を想起させる
- プロパティ名や説明だけでは、コンポーネント単位の情報だと気づきにくい
といった背景があります。
対策としては、クエリを書き始める前に「何を判定したいのか」を一段階だけ言語化するのが効果的です。
| 判定したいこと | おすすめの参照先 | 理由 |
|---|---|---|
| クライアント本体が 5.00.9040.1015 か | SMS_R_System.ClientVersion | コンソール表示と整合しやすく、コレクション用途に向く |
| 特定コンポーネントのビルドだけが古い端末があるか | SMS_G_System_SMS_ADVANCED_CLIENT_STATE | 部品単位の差異を拾える（ただし本体バージョンとは別） |
「正しいクエリにしたのに0件」のときに疑うべきポイント
今回のケースは“クラスの取り違え”が原因でしたが、実務では「SMS_R_Systemに直したのにまだ0件」という状況も起こり得ます。その場合は、次の観点で切り分けると迷いにくいです。
| 症状 | ありがちな原因 | 確認ポイント | 対処例 |
|---|---|---|---|
| コンソールのデバイス一覧では1015が見えるが、コレクションだけ0件 | コレクションの更新タイミング | 評価スケジュール、増分更新、フル更新 | 手動更新・評価間隔の見直し（移行期間は特に） |
| 一部端末だけClientVersionが空/古い | ディスカバリ/ハートビート反映が遅い | 対象端末の「最終アクティビティ」やクライアント状態 | クライアント側でハートビート/ポリシー取得を促す、ネットワーク疎通確認 |
| 確かに1015へ更新したはずなのに、DBが1010のまま | 更新が途中、または一部コンポーネントのみ更新 | クライアントの「About」画面や ccmexec の情報、ログ | クライアントの修復/再インストール、境界/配布ポイント/コンテンツ配布の確認 |
| クエリが一致しない（表記ゆれ） | 比較が文字列で、入力ミスや余分な空白 | ダブルクォート内の値、全角・半角、末尾 | まずは1台の端末を特定し、正確なClientVersionをコピーして使う |
特に移行直後は「端末側は更新済みだが、サイト側への反映が追いついていない」というズレが起きやすいです。まずは1台の端末を決めて、コンソール表示（ClientVersion）とWMI/ログの情報が揃っているかを見ていくと、原因がすぐ絞れます。
実務的な使い分け：ClientVersionコレクションとコンポーネント追跡を混ぜない
クライアント バージョンでコレクションを組む（展開・運用の基本）
サイト更新直後に、
- 新しいクライアントだけにアプリを配布したい
- 古いクライアント端末を洗い出して更新対象にしたい
- サポート対象外のバージョンを棚卸ししたい
といった場面では、基本的に SMS_R_System.ClientVersion を使うのが安全です。コレクションは「展開の母集団」になるため、判定軸はできるだけブレないもの（コンソール表示と一致しやすいもの）に寄せるのが、事故を減らすコツです。
コンポーネントごとの差異を見る（トラブルシュート向き）
一方で、
- 特定のエージェントだけ更新されていない
- クライアントは導入済みだが機能の一部が動かない
- 更新後にだけ特定ログが異常
のような“部品の不整合”を疑うなら、SMS_G_System_SMS_ADVANCED_CLIENT_STATE のようなクラスを参照して、コンポーネント単位で差分を拾うのが有効です。ここはコレクション条件の主軸にするというより、原因調査用の切り口として使うと噛み合います。
WQLやクラス確認に便利：WMI Explorerで「そのクラスに何が入っているか」を見る
「このクラスに本当に1015が存在するのか？」を最短で確認したいときは、WMIブラウザ系ツールが強力です。たとえば WMI Explorer を使うと、サイトサーバーのWMIへ接続して次のような確認ができます。
- ネームスペース：root\sms\site_<サイトコード>
- クラス：SMS_R_System / SMS_G_System_SMS_ADVANCED_CLIENT_STATE など
- プロパティの一覧（ClientVersionがあるか、どの名前か）
- サンプル値の確認（1015が存在するか、1010までなのか）
- WQLのテスト（条件を変えながら結果を見る）
ここで重要なのは、コンソールの“候補”や“表示”だけに頼らず、実データの格納先（クラスとプロパティ）を直接確認することです。クライアント更新やサイト更新のように変更点が多い作業では、見えているものが何を参照しているかが曖昧になりがちです。WMI Explorerで一度でも「この値はこのクラスに入っている」を体感すると、次回以降のトラブルシュートが速くなります。
応用：バージョン指定の“表現”を工夫して運用しやすくする
固定の完全一致（= “5.00.9040.1015”）は最も明快ですが、運用上は「末尾のビルドが環境差で微妙に揺れる」こともあります。たとえば、特定の機能更新の系統だけをまとめたいなら、like での前方一致が便利なことがあります。
同じ系統（5.00.9040.10xx）をまとめて拾う例
select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.Name
from SMS_R_System
where SMS_R_System.Client = 1
and SMS_R_System.ClientVersion like "5.00.9040.10%"この形なら、1010/1015のような末尾差があっても同じコレクションに収まり、移行期間中の展開に使いやすいことがあります。逆に「ピンポイントで1015だけ」をやりたい場合は、完全一致で運用します。
注意：WQLは“バージョン比較”が得意ではない
「1010より古い」「1015より新しい」といった数値比較を直感的に書きたい場面もありますが、WQLは基本的に文字列比較になるため、バージョンの大小比較は思った通りにならないことがあります。範囲指定が必要なら、
- 前方一致（like）で“系統”をまとめる
- 必要に応じてレポート（SQL側）で棚卸しする
- コレクションは「展開対象の確実な抽出」に寄せる
といった割り切りが、運用の安定につながります。
まとめ：見ている“バージョン”が違えば、クエリ結果が違うのは自然
クライアント バージョンで端末を絞り込みたいなら、SMS_R_System.ClientVersion を使う。SMS_G_System_SMS_ADVANCED_CLIENT_STATE はコンポーネントのバージョンであり、5.00.9040.1015 を持たないためクエリでヒットしない。
今回の現象は、「MECM/SCCMの不具合」や「クライアント更新の失敗」を疑ってしまいがちですが、構造としてはとてもシンプルです。
- コンソールが表示する“クライアント バージョン”は、ClientVersion（本体）の値
- クエリで参照していたのは、コンポーネントの値を持つクラス
- だから候補に1015が出ず、手入力しても0件になる
サイトアップグレード後は、管理対象端末の状態が混在しやすく、クエリを間違えると展開ミスにも直結します。クラス選定（SMS_R_Systemか、SMS_G_Systemか）を最初に正しく決めて、必要ならWMI Explorerで中身を見ながら進めるのが、最短で確実な解決策です。
コメント