Configuration Manager 中狀態傳訊的描述

本文說明 Configuration Manager 中的狀態傳訊系統。

原始產品版本：Configuration Manager (最新分支)
原始 KB 編號： 4459394

了解狀態傳訊

Configuration Manager 中的狀態傳訊是一種機制，可在特定時間點反映客戶端條件。 相反地，狀態消息可協助系統管理員透過各種 Configuration Manager元件追蹤數據的工作流程。

狀態消息查看器會直接內建在控制台中，以便檢視和追蹤狀態消息。 狀態消息沒有對等的查看器。 狀態消息的結果如下所示：

• 報告
• 控制台中的各種數據，例如必須更新的系統數目
• 客戶端記錄

狀態消息包含有關用戶端上就地條件的簡要資訊。 狀態傳訊系統是由 Configuration Manager 的特定元件使用，包括：

• 軟體更新
• 所需的組態管理
• 網路存取保護

重要的軟體更新數據依賴 Configuration Manager 中的狀態傳訊系統。 隨著更多元件利用狀態傳訊，了解狀態傳訊在未來的 Configuration Manager 版本中會變得更加重要。

下圖提供狀態傳訊系統運作方式的良好描述。

綠色方塊代表狀態傳訊系統。 方塊內的元件是將資訊饋送至系統的元件。

收到狀態消息時，會發生兩件事：

1. 狀態消息會儲存在 Windows Management Instrumentation (WMI) 提供者中。
2. 狀態系統會在 15 分鐘的迴圈中抓取 WMI， (任何尚未傳送之狀態消息的預設) ，然後將它們轉送到管理點。 可以變更週期週期。

在圖表中，為了清楚起見，用戶端安裝部分會個別顯示。 在用戶端安裝期間，管理點是以狀態消息為目標。 如果用戶端安裝的狀態消息是在下列其中一個情況下設定) ，則會轉送到 FSP) ( (後援狀態點：

• 未到達管理點。
• 管理點因為某些原因而關閉。

針對其他所有專案，流量會直接流向管理點。

抵達管理點的狀態消息會由 MP 轉送元件處理到 .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	True

在月臺伺服器上，編輯下列登錄專案以啟用詳細資訊記錄，然後重新啟動 SMS_Executive 服務 (或狀態系統元件) ：

登錄子機碼	DWORD 名稱	數值資料
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM	詳細信息記錄	1

追蹤 SQL 命令需要針對 Configuration Manager元件啟用 SQL 追蹤。 但無法直接從追蹤取得太多有用的數據。 即使已啟用 Profiler，也是如此。 因此，我們將檢查用戶端上的Updatesdeployment.log和Statemessage.log檔案。 藉由解譯這些記錄中的狀態消息，我們可以清楚瞭解程式中各種步驟中發生的情況。

在檢查記錄程式碼範例之前，我們必須了解狀態消息格式。 狀態消息本身包含數個部分，包括 主題類型 和 狀態消息標識碼。 在記錄中的某些位置， 主題類型 似乎已經為您解譯。

您不一定會在同一個記錄中一起看到 主題類型 和 狀態消息標識 碼。 沒有另一種數據的其中一種數據類型，實際上無法協助您判斷需要什麼。 不過，即使您同時有 主題類型 和 狀態消息標識碼，除非您可以加以解譯，否則資訊並無説明。

下圖可協助您解譯 和 StateID 的TopicType組合，以取得有意義的數據。

select * from v_StateNames  

注意事項

下圖包含 300、400 和 500 系列 主題類型 代碼。

狀態傳訊數據

TopicType	StateID	StateName
300	0	合規性狀態未知
300	1	Compliant
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	Compliant
401	2	不符合規範
401	3	偵測到衝突
401	4	錯誤
401	5	不適用
401	6	未偵測到
401	7	已強制
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 中的狀態消息。

下列範例會對齊並比較Updatesdeployment.log和Statemessage.log檔案。 請確定記錄參考相同的狀態消息，方法是將相同的 TopicID (綠色文字) 。 這清楚地指出這兩個記錄參考相同的狀態消息。 會 TopicType 以淺藍色文字顯示。 請注意，一個記錄檔可能會顯示可從 狀態傳訊數據 圖表解譯的實際數目。 另一個可能顯示已解譯) (泛型值。 狀態消息標識碼 (StateId) 會以紫色文字顯示。

藉由結合 圖表中 TopicType () StateId 的 和 狀態消息識別碼，您可以確切地追蹤記錄中發生的狀況。 在此範例中，這些程式碼範例會顯示下列資訊：

• 更新評估
• 評估的結果
• 正在下載的更新
• 正在安裝的更新
• 擱置中的系統重新啟動

這隻是如何將狀態消息傳送至狀態系統的其中一個範例。

狀態傳訊數據流

下圖是狀態傳訊數據如何前往管理點並處理至資料庫的實際範例。

此範例會使用測試用戶端。 其一開始會強制用戶端抓取所有狀態傳訊資訊的 WMI，然後在下一個輪詢週期將該資訊傳送至管理點。

在WMI中，狀態消息會儲存在 命名空間中 root\ccm\statemsg 。 在該命名空間中，有兩個感興趣的類別： CCM_StateMsg_SerialNum 和 CCM_StateMsg。

類別 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()

此腳本可在不同位置的網頁上找到。 它會使用 Configuration Manager SDK，讓用戶端將其數據重新傳送至管理點。

一般而言， (VBScript) 的 Visual Basic 腳本是使用 來執行 cscript。 請注意，如果您嘗試自行執行腳本，腳本可能會失敗。 問題在於 Configuration Manager 是在64位伺服器上執行的32位應用程式。 的預設版本 cscript 是 64 位版本，通常適用於任何 VBScript。 不過，在此情況下，所進行的呼叫需要 32 位版本 cscript 的 ，您必須用完 syswow64 資料夾。

當下一個狀態消息輪詢循環發生時，所有狀態消息都會傳送至管理點。

在Statemessage.log檔案中，您可以看到狀態消息資訊已提取、格式化為 XML，然後傳送至管理點。 狀態訊息資訊應該類似下列範例：

<![LOG[StateMessage body： <？xml version=“1.0” encoding=“UTF-16”？>
<ReportHeader><><識別><機器><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><Datedate<>/Date><Version>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime=“time” SerialNumber=“serial_number”><Topic 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[成功將狀態消息轉送至管理點]LOG]！><time=“time” date=“date” component=“StateMessage” context=“” type=“1” thread=“3592” file=“statemsg.cpp：1527”>

注意事項

這個範例會因為 XML 檔案的大小而截斷成單一狀態消息。

雖然 Statemessage.log 檔案會記錄訊息已分派至管理點，但狀態消息系統實際上不會將數據移至管理點。 在下列範例中，您可以看到執行 CCMMessaging 這項作業。 此時會在幕後進行更多作業。 不過，在本例MP_Relay中，CCMMessaging元件) 就足以知道將數據傳送至管理點 (。

<![LOG[OutgoingMessage (Queue='mp_mp_relayendpoint'， ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}) ： 已成功傳遞至主機 'host_name'。]LOG]！>

當數據抵達 進行處理時 MP_Relay，它會進行處理並轉譯成 .smx 檔格式，然後放入資料夾中 auth\statesys.box\incoming 。

Inv-Relay 工作：處理訊息本文
轉送：FileType= SMX
轉送：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，然後按兩下新的檔名，XML 檔案就會在Internet Explorer 中開啟，而且更容易閱讀。

下圖是 Internet Explorer 中開啟之 XML 檔案的範例。 計算機和狀態消息的詳細數據會反白顯示。 它包含我們先前討論過的資訊，並結合唯一的 狀態消息標識碼 值。

注意事項

如果您重新命名這些檔案，請先將它們複製到不同的資料夾，以免影響 Statesys.box 資料夾。

最後，狀態消息必須處理到資料庫中。 在 Statesys.log 檔案中，您可以看到類似下列範例的這類訊息：

找到要處理的新狀態消息，開始處理線程
線程 “State Message Processing Thread #0” id：5076 started
CMessageProcessor - 偵測到父網站 'site_name'
CMessageProcessor - 處理檔案：mdlbp169。Smw 工
CMessageProcessor - 處理了 1 筆記錄，其中包含 0 筆無效的記錄。
CMessageProcessor - 成功復寫檔案 “mdlbp169。SMW“ 至父月 臺site_name。
CMessageProcessor - 處理此批次中的 1 個訊息檔案，其中包含 0 個不正確的檔案。
線程「狀態消息處理線程 #0」識別碼：5076 正常終止

您可以啟用 SQL 追蹤來顯示資料庫處理元件，但這並沒有太大的説明。 我們必須改用 SQL 分析工具。 分析工具會提供幕後發生的提示，但並非完全。 數個 SQL 預存程式負責處理狀態消息。 此外，資料庫中的數個數據表會儲存狀態傳訊數據。 執行狀態消息處理的預存程式通常會以 名稱 spProcess開頭。 有許多這類程式。

月臺伺服器會在狀態消息送達時追蹤狀態消息，因此它可以標示任何遺漏的訊息，並在必要時定期要求重新同步處理。 狀態消息很重要。 您不想要錯過任何專案。

當狀態消息送達時，會讀取唯一標識符並儲存在資料庫中。 隨著處理的繼續，數據會定期更新。 如果偵測到間距，該數據會標示並儲存為數據表中遺漏的 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設定

名稱	Value1	Value2	Value3
活動訊號訊號間隔			60
收件匣輪詢間隔			900
載入器區塊大小			256
載入器線程			4
擷取的最大區塊數			100
最小遺漏訊息存留期			2880
重新同步檢查間隔			15
重試設定	REG_SZ	<Config><Retry PatternID=“0” RetryQueue=“0”>7200,28800,86400</Retry></Config>	0

注意事項

• [重新同步檢查間隔 ] 設定為 60 分鐘。 這是檢查需要狀態消息重新同步處理之系統的排程。
• 最小遺漏訊息存留期 設定為 2880。 這是要求重新同步之前必須遺失訊息的時間長度。