Configuration Manager 中狀態傳訊的描述
本文說明 Configuration Manager 中的狀態傳訊系統。
原始產品版本： Configuration Manager（最新分支）
原始 KB 編號： 4459394
了解狀態消息
Configuration Manager 中的狀態傳訊是一種機制，可反映特定時間點的客戶端條件。 相反地，狀態消息的工作可協助系統管理員透過各種 Configuration Manager 元件追蹤數據的工作流程。
狀態消息查看器已內建在控制台中，以便檢視和追蹤狀態消息。 狀態消息沒有對等的查看器。 狀態訊息的結果會顯示在：
- reports
- 控制台中的各種數據，例如必須更新的系統數目
- 客戶端記錄
狀態消息包含用戶端上就地條件的精簡資訊。 Configuration Manager 的特定元件會使用狀態傳訊系統，包括：
- 軟體更新
- 所需的組態管理
- 網路存取保護
重大軟體更新數據依賴 Configuration Manager 中的狀態傳訊系統。 隨著更多元件利用 Configuration Manager，了解狀態傳訊在未來版本中會變得更加重要。
下圖提供狀態傳訊系統運作方式的良好描述。
綠色方塊代表狀態傳訊系統。 方塊內的元件是將資訊饋送至系統的元件。
收到狀態消息時，會發生兩件事：
- 狀態消息會儲存在 Windows Management Instrumentation （WMI） 提供者中。
- 狀態系統會針對尚未傳送的任何狀態消息，在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 |
啟用 | 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 | 狀態識別碼 | StateName |
|---|---|---|
| 300 | 0 | 合規性狀態未知 |
| 300 | 1 | 符合標準 |
| 300 | 2 | 不符合規範 |
| 300 | 3 | 偵測到衝突 |
| 301 | 0 | 強制狀態不明 |
| 301 | 1 | 安裝更新（s） |
| 301 | 2 | 等候重新啟動 |
| 301 | 3 | 等候另一個安裝完成 |
| 301 | 4 | 已成功安裝更新（秒） |
| 301 | 5 | 暫止的系統重新啟動 |
| 301 | 6 | 無法安裝 update（s） |
| 301 | 7 | 下載更新（秒） |
| 301 | 8 | 下載的更新（秒） |
| 301 | 9 | 無法下載更新（s） |
| 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 | 強制執行 |
| 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()
您可以在各種位置的 Web 上找到此文稿。 它會使用 Configuration Manager SDK，讓用戶端將其數據重新傳送至管理點。
一般而言，Visual Basic 腳本 （VBScript） 是使用 cscript來執行。 請注意，如果您嘗試自行執行腳本，腳本可能會失敗。 問題是 Configuration Manager 是在 64 位伺服器上執行的 32 位應用程式。 的預設版本 cscript 是 64 位版本，通常適用於任何 VBScript。 不過，在此情況下，所進行的呼叫需要 32 位版本的 cscript ，您必須用完 syswow64 資料夾。
當下一個狀態消息輪詢周期發生時，所有狀態消息都會傳送至管理點。
在Statemessage.log檔案中，您可以看到狀態訊息資訊已提取、格式化為 XML，然後傳送至管理點。 狀態訊息資訊應該類似下列範例：
<![LOG[StateMessage 本文： <？xml version=“1.0” encoding=“UTF-16”？>
<ReportHeader Identification Machine ClientInstalled 1/ClientInstalled>><ClientType>1<</ClientType><ClientID GUID：GUID</ClientID>><><><><>
<ClientVersion client_version_number</ClientVersion>><NetBIOSName 名稱</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.0<</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime=“time” SerialNumber=“serial_number”><Topic ID=“21e49ac6-a273-24a61-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 這項作業。 此時，幕後還有更多。 不過，知道 CCMMessaging 將數據傳送至管理點就已足夠了（在此案例中 MP_Relay 為元件）。
<![LOG[OutgoingMessage（Queue='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 ，您可以使用記事本之類的文本編輯器來開啟它，以查看詳細數據。 不過，檔案的格式可能無法讀取，如下列範例所示：
![[記事本] 中範例 SMX 檔案的螢幕快照。](media/state-messaging-description/notepad-example.png)
如果您藉由新增.xml擴展名來重新命名.smx檔案，以便將檔案命名為 file_name.smx.xml，然後按兩下新的檔名，XML 檔案會在 Internet Explorer 中開啟，而且更容易閱讀。
下圖是 Internet Explorer 中開啟的 XML 檔案範例。 計算機和狀態訊息的詳細數據會反白顯示。 其中包含我們先前討論過的資訊，並結合唯 一的狀態消息標識符 值。
注意
如果您重新命名這些檔案，請先將它們複製到不同的資料夾，以免影響 Statesys.box 資料夾。
最後，狀態消息必須處理到資料庫中。 在 Statesys.log 檔案中，您可以看到類似下列範例的這類訊息：
找到要處理的新狀態消息，開始處理線程
線程「狀態消息處理線程 #0」識別碼：5076 已啟動
CMessageProcessor - 偵測到的父網站 'site_name'
CMessageProcessor - 處理檔案：mdlbp169。SMW
CMessageProcessor - 已處理 1 筆無效記錄的記錄。
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 | ||
| Resync 簽到 terval | 15 | ||
| 重試設定 | REG_SZ | <Config><Retry PatternID=“0” RetryQueue=“0”>7200,28800,86400</Retry></Config> | 0 |
注意
- Resync 簽到 terval 設定為 60 分鐘。 這是檢查需要狀態消息重新同步的系統排程。
- 最小遺漏郵件年齡 設定為 2880。 這是要求重新同步處理之前必須遺失訊息的時間長度。