Configuration Manager での状態メッセージングの説明
この記事では、Configuration Manager の状態メッセージング システムについて説明します。
元の製品バージョン: Configuration Manager (Current Branch)
元の KB 番号: 4459394
状態メッセージングについて
Configuration Manager の状態メッセージングは、特定の時点のクライアント条件を反映するメカニズムです。 これに対し、ステータス メッセージは、管理者がさまざまな Configuration Manager コンポーネントを介してデータのワークフローを追跡するのに役立ちます。
ステータス メッセージ ビューアーはコンソールに直接組み込まれているため、ステータス メッセージを表示および追跡できます。 状態メッセージに同等のビューアーはありません。 状態メッセージの結果は次のようになります。
- reports
- 更新する必要があるシステムの数など、コンソール内のさまざまなデータ
- クライアント ログ
状態メッセージには、クライアント上のインプレース条件に関する簡潔な情報が含まれています。 状態メッセージング システムは、次のような Configuration Manager の特定のコンポーネントによって使用されます。
- ソフトウェア更新プログラム
- 必要な構成管理
- ネットワーク アクセス保護
重要なソフトウェア更新データは、Configuration Manager の状態メッセージング システムに依存します。 Configuration Manager の将来のバージョンでは、より多くのコンポーネントで利用されるため、状態メッセージングを理解することがさらに重要になります。
次の図は、状態メッセージング システムのしくみの適切な説明を示しています。
緑色のボックスは、状態メッセージング システムを表します。 ボックス内のコンポーネントは、システムに情報をフィードするコンポーネントです。
状態メッセージを受信すると、次の 2 つのことが発生します。
- 状態メッセージは、Windows Management Instrumentation (WMI) プロバイダーに格納されます。
- 状態システムは、送信されていない状態メッセージに対して 15 分のサイクル (既定) で WMI をスクレイピングし、管理ポイントに転送します。 サイクル期間は変更できます。
この図では、クライアント インストール部分がわかりやすくするために個別に示されています。 クライアントのインストール中に、管理ポイントが配置され、状態メッセージの対象になります。 クライアント インストールに関する状態メッセージは、次のいずれかの条件下でフォールバック ステータス ポイント (FSP) に転送されます (構成されている場合)。
- 管理ポイントに到達していません。
- 何らかの理由で管理ポイントがダウンしています。
それ以外の場合は、トラフィックは管理ポイントに直接送信されます。
管理ポイントに到着した状態メッセージは、MP Relay コンポーネントによって .smx ファイルに処理され、サイト サーバー上の auth\statesys.box\incoming フォルダーに格納されます。 次に、ワークフローを完了するためにデータベースに処理されます。
専門的な情報
詳細ログが有効になっていることを確認する必要があります。
- クライアント
- 管理ポイント
- サイト サーバー上の状態メッセージング コンポーネント
Configuration Manager クライアントまたは管理ポイントで詳細ログまたはデバッグ ログを設定するには、次のレジストリ エントリを編集または作成します。
| レジストリ サブキー | DWORD 名 | 値データ |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global |
LogLevel | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
Enabled | はい |
サイト サーバーで、次のレジストリ エントリを編集して詳細ログを有効にし、 SMS_Executive サービス (または状態システム コンポーネント) を再起動します。
| レジストリ サブキー | DWORD 名 | 値データ |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
詳細ログ記録 | 1 |
SQL コマンドをトレースするには、Configuration Manager コンポーネントに対して SQL トレースが有効になっている必要があります。 しかし、トレースから直接有用なデータを取得することはできません。 Profiler が有効になっている場合でも同様です。 そこで、クライアント上のファイルのUpdatesdeployment.logとStatemessage.logを調べます。 これらのログ内の状態メッセージを解釈することで、プロセスのさまざまな手順で何が発生しているのかを明確に把握できます。
ログ コードの例を調べる前に、状態メッセージの形式を理解する必要があります。 状態メッセージ自体は、 Topic Type および State Message ID など、いくつかの部分で構成されます。 ログ内の一部の場所では、 トピックの種類 は既に解釈されているようです。
トピックの種類と State メッセージ ID が同じログに表示されるわけではありません。 一方の種類のデータに他のデータがない場合は、必要なものを判断するのに役立ちません。 ただし、 Topic Type と State Message ID の両方がある場合でも情報は解釈できない限り役に立ちません。
次のグラフは、 TopicType と StateID の組み合わせを解釈して意味のあるデータを取得するのに役立ちます。
select * from v_StateNames
Note
次のグラフには、300、400、および 500 系列 トピックの種類 コードが含まれています。
状態メッセージング データ
| TopicType | StateID | StateName |
|---|---|---|
| 300 | 0 | コンプライアンスの状態が不明 |
| 300 | 1 | 対応 |
| 300 | 2 | 準拠していない |
| 300 | 3 | 競合が検出されました |
| 301 | 0 | 強制状態が不明 |
| 301 | 1 | 更新プログラムのインストール |
| 301 | 2 | 再起動の待機中 |
| 301 | 3 | 別のインストールが完了するのを待っている |
| 301 | 4 | 正常にインストールされた更新プログラム |
| 301 | 5 | 保留中のシステム再起動 |
| 301 | 6 | 更新プログラムのインストールに失敗しました |
| 301 | 7 | 更新プログラムのダウンロード |
| 301 | 8 | ダウンロードした更新プログラム |
| 301 | 9 | 更新プログラムのダウンロードに失敗しました |
| 301 | 10 | インストールする前にメンテナンス期間を待機しています |
| 301 | 11 | サード パーティ製オーケストレーターによるインストールの開始の待機 |
| 302 | 0 | 評価状態が不明 |
| 302 | 1 | 評価のアクティブ化 |
| 302 | 2 | 評価に成功しました |
| 302 | 3 | 評価に失敗しました |
| 400 | 0 | 検出状態が不明 |
| 400 | 1 | 任意 |
| 400 | 2 | 検出されませんでした |
| 400 | 3 | 検出された |
| 401 | 0 | コンプライアンスの状態が不明 |
| 401 | 1 | 対応 |
| 401 | 2 | 非準拠 |
| 401 | 3 | 競合が検出されました |
| 401 | 4 | エラー |
| 401 | 5 | 適用外 |
| 401 | 6 | 検出されませんでした |
| 401 | 7 | Enforced (強制) |
| 402 | 0 | 強制状態が不明 |
| 402 | 1 | 適用が開始されました |
| 402 | 2 | コンテンツの強制待機 |
| 402 | 3 | 別のインストールが完了するのを待っている |
| 402 | 4 | インストールする前にメンテナンス期間を待機しています |
| 402 | 5 | インストールする前に再起動する必要があります |
| 402 | 6 | 一般的なエラー |
| 402 | 7 | 保留中のインストール |
| 402 | 8 | 更新をインストールしています |
| 402 | 9 | 保留中のシステム再起動 |
| 402 | 10 | 正常にインストールされた更新プログラム |
| 402 | 11 | 更新プログラムのインストールに失敗しました |
| 402 | 12 | 更新プログラムのダウンロード |
| 402 | 13 | ダウンロードした更新プログラム |
| 402 | 14 | 更新プログラムのダウンロードに失敗しました |
| 500 | 0 | 検出状態が不明 |
| 500 | 1 | 更新は必要ありません |
| 500 | 2 | 更新が必要です |
| 500 | 3 | 更新プログラムがインストールされている |
| 501 | 0 | スキャン状態が不明 |
| 501 | 1 | スキャンがカタログの場所を待機しています |
| 501 | 2 | スキャンが実行されている |
| 501 | 3 | スキャンが完了しました |
| 501 | 4 | スキャンの再試行が保留中です |
| 501 | 5 | スキャンに失敗しました |
| 501 | 6 | エラーが発生してスキャンが完了しました |
詳細については、「Configuration Manager の State メッセージ」を参照してください。
次の例では、Updatesdeployment.logファイルとStatemessage.log ファイルを配置して比較します。 同じ TopicID (緑のテキスト) を揃えて、ログが同じ状態メッセージを参照していることを確認します。 これは、2 つのログが同じ状態メッセージを参照していることを明確に示します。 TopicTypeは水色のテキストで表示されます。 1 つのログに、 State メッセージング データ グラフから解釈できる実際の数が表示される場合があることに注意してください。 もう 1 つの値はジェネリック値 (既に解釈済み) を示している可能性があります。 State Message ID (StateId) は紫色のテキストで表示されます。
グラフから TopicType と State Message ID (StateId) を組み合わせることで、ログで発生している内容を正確に追跡できます。 この例では、次のコード例に次の情報を示します。
- 更新プログラムの評価
- 評価の結果
- ダウンロード中の更新プログラム
- インストールされている更新プログラム
- 保留中のシステム再起動
これは、状態メッセージを状態システムに送信する方法の 1 つの例にすぎません。
状態メッセージング データ フロー
次の図は、状態メッセージング データが管理ポイントに至り、データベースに対して処理される実際の例です。
この例では、テスト クライアントを使用します。 まず、クライアントにすべての状態メッセージング情報の WMI を強制的にスクレーピングし、次のポーリング サイクルでその情報を管理ポイントに送信します。
WMI では、状態メッセージは root\ccm\statemsg 名前空間に格納されます。 その名前空間には、 CCM_StateMsg_SerialNum と CCM_StateMsgの 2 つのクラスがあります。
CCM_StateMsg_SerialNum クラスは、状態メッセージに使用される最後のシリアル番号を記録するために使用されます。 すべての状態メッセージには、ハードウェア インベントリと同様に、一意のシリアル番号があります。 この方法では、サイト サーバーは、システムからの状態メッセージが見つからないかどうかを追跡できます。 状態メッセージが見つからないと、状態レポートが不完全または不正確になる可能性があるため、重要です。
CCM_StateMsg クラスには、状態メッセージ自体が含まれています。 クラス インスタンスでは、記録されているすべての状態メッセージを見つけることができます。
これらのメッセージのいずれかを開くと、次の例に示すように、状態メッセージの詳細と、前に説明したデータが表示されます。
次の再同期スクリプトを使用して、データを管理ポイントに再送信し、進行状況を追跡できます。
RefreshServerComplianceState()
Sub RefreshServerComplianceState()
dim newCCMUpdatesStore
set newCCMUpdatesStore = CreateObject ("Microsoft.CCM.UpdatesStore")
newCCMUpdatesStore.RefreshServerComplianceState
wscript.echo "Ran RefreshServerComplianceState."
End Sub
$UpdatesStore = New-Object -ComObject Microsoft.CCM.UpdatesStore
$UpdatesStore.RefreshServerComplianceState()
このスクリプトは、Web 上のさまざまな場所にあります。 Configuration Manager SDK を使用して、クライアントがそのデータを管理ポイントに再送信します。
通常、Visual Basic スクリプト (VBScript) は、 cscriptを使用して実行されます。 スクリプトを自分で実行しようとすると、スクリプトが失敗する可能性があることに注意してください。 問題は、Configuration Manager が 64 ビット サーバーで実行されている 32 ビット アプリケーションであるということです。 cscriptの既定のバージョンは 64 ビット バージョンであり、通常は任意の VBScript で正常に動作します。 ただし、この場合、呼び出しを行うには、syswow64 フォルダーを使い果たす必要がある 32 ビット バージョンの cscript が必要です。
次の状態メッセージ ポーリング サイクルが発生すると、すべての状態メッセージが管理ポイントに送信されます。
Statemessage.log ファイルでは、状態メッセージ情報がプルされ、XML に書式設定され、管理ポイントに送信されることがわかります。 状態メッセージの情報は、次の例のようになります。
<![LOG[StateMessage body: <?xml version="1.0" encoding="UTF-16"?>
<Report><ReportHeader><Identification><Machine><ClientInstalled>1</ClientInstalled><ClientType>1</ClientType><ClientID>GUID:GUID</ClientID>
<ClientVersion>client_version_number</ClientVersion><NetBIOSName>name</NetBIOSName><CodePage>437</CodePage>
<SystemDefaultLCID>1033</SystemDefaultLCID></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent>
<ReportType>Full</ReportType><Date>date</Date><Version>1.0</Version><Format>1.1 0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="time" SerialNumber="serial_number ><トピック ID="21e49ac6-a273-4a61-9794-eb675bc743e5" Type="500" IDType ="3"/><State ID="2" Criticality="0"/><UserParameters Flags="0" Count="1"><Param>102</Param></UserParameters></StateMessageserParameters></StateMessage></ReportBody></Report>
]LOG<![LOG[CStateMsgManager::GetSignEncyptMode]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1820">
<![LOG[Successfuled State Messages to the management point]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1527">
Note
この例では、XML ファイルのサイズが原因で 1 つの状態メッセージに切り捨てられます。
Statemessage.log ファイルは、メッセージが管理ポイントにディスパッチされたことを記録しますが、状態メッセージング システムは実際には管理ポイントにデータを移動しません。 次の例では、 CCMMessaging がこの操作を実行していることがわかります。 この時点でバックグラウンドで行われるものがあります。 ただし、 CCMMessaging が管理ポイント (この場合は MP_Relay コンポーネント) にデータを送信することを知って十分です。
<![LOG[OutgoingMessage(Queue='mp_mp_relayendpoint', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): 'host_name' をホストするために正常に配信されました。]LOG]!>
データは、 MP_Relayで処理するために到着すると、処理され、 .smx ファイル形式に変換され、 auth\statesys.box\incoming フォルダーに格納されます。
Inv-Relay タスク: メッセージ本文の処理
Relay: FileType= SMX
Relay: Outbox dir: C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
リレー: 0 個の添付ファイルを受信しました
リレー: 0 個の添付ファイルのうち 0 個が正常に処理されました
Inv-Relay: タスクが正常に完了しました
auth\statesys.box\incoming フォルダーには、処理中の.smx ファイルが表示されます。 通常、ここには表示されません。 ただし、ファイルがこのフォルダーに残っている場合は、メッセージの内容と、処理されていない理由を調査する必要があります。 .smx ファイルが見つかると、メモ帳などのテキスト エディターを使用してファイルを開き、詳細を表示できます。 ただし、次の例のように、ファイルの書式設定が読み取れない場合があります。
.xml拡張子を追加して.smxファイルの名前をfile_name.smx.xmlし、新しいファイル名をダブルクリックすると、INTERNET Explorer で XML ファイルが開き、読みやすくなります。
次の図は、Internet Explorer で開かれた XML ファイルの例です。 コンピューターの詳細と状態メッセージが強調表示されます。 これには、前に説明した情報と、一意の State メッセージ ID 値が含まれています。
Note
これらのファイルの名前を変更する場合は、最初に別のフォルダーにコピーして、 Statesys.box フォルダーに影響しないようにします。
最後に、状態メッセージをデータベースに処理する必要があります。 Statesys.log ファイルには、次の例のようなメッセージが表示されます。
処理する新しい状態メッセージが見つかりました。スレッドの処理を開始しています
スレッド "State Message Processing Thread #0" id:5076 started
CMessageProcessor - 検出された親サイト 'site_name'
CMessageProcessor - 処理ファイル: mdlbp169。SMW
CMessageProcessor - 0 個の無効なレコードを含む 1 つのレコードを処理しました。
CMessageProcessor - ファイル "mdlbp169" が正常にレプリケートされました。SMW" を親サイト site_nameに変換します。
CMessageProcessor - このバッチ内の 1 つのメッセージ ファイルを処理し、0 個の不適切なファイルを処理しました。
スレッド "State Message Processing Thread #0" id:5076 terminated normally
データベース処理コンポーネントは、SQL トレースを有効にすることで表示できますが、あまり役に立ちません。 代わりに SQL プロファイラーを使用する必要があります。 プロファイラーは、バックグラウンドで何が発生しているのかを示しますが、完全には行われません。 状態メッセージの処理は、いくつかの SQL ストアド プロシージャが担当します。 さらに、データベース内のいくつかのテーブルには、状態メッセージング データが格納されます。 状態メッセージ処理を実行するストアド プロシージャは、通常、名前 spProcessで始まります。 このような手順の多くがあります。
サイト サーバーは、状態メッセージの到着を追跡するため、不足しているメッセージにフラグを設定し、必要に応じて定期的に再同期を要求できます。 状態メッセージは重要です。 お見逃しなく。
状態メッセージが到着すると、一意の ID が読み取られ、データベースに格納されます。 処理が続行されると、データは定期的に更新されます。 ギャップが検出されると、そのデータにフラグが設定され、不足状態メッセージとして SR_MissingMessageRanges テーブルに格納されます。 理想的には、このテーブルは空になります。 ただし、運用環境では、テーブルにデータが表示される場合があります。 このテーブルは、再同期を必要とする状態メッセージを追跡するのに役立ちます。
サイト コントロール ファイルはデータベースにあります。 STATE_MESSAGE_SYSTEMの特定の設定を取得するには、プライマリ サイトまたは CAS サイトで次のクエリを実行します。
select * from SC_Component_Property where ComponentID in (select ID from SC_Component where ComponentName like 'SMS_STATE_SYSTEM') and sitenumber in (select SiteNumber from SC_SiteDefinition where Sitecode = (Select ThisSiteCode from SMSData))
STATE_MESSAGE_SYSTEM設定
| Name | Value1 | Value2 | Value3 |
|---|---|---|---|
| ハートビート メッセージの間隔 | 60 | ||
| 受信トレイのポーリング間隔 | 900 | ||
| ローダー チャンク サイズ | 256 | ||
| ローダー スレッド | 4 | ||
| フェッチされた最大チャンク数 | 100 | ||
| メッセージの最小欠落期間 | 2880 | ||
| resync チェックインterval | 15 | ||
| 構成の再試行 | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Note
- resync チェックインterval は 60 分に設定されます。 これは、状態メッセージの再同期を必要とするシステムをチェックするためのスケジュールです。
- メッセージの最小不足期間 は 2880 に設定されます。 これは、再同期が要求されるまでにメッセージが欠落している必要がある期間です。