Configuration Manager中的状态消息传送说明
本文介绍 Configuration Manager 中的状态消息传送系统。
原始产品版本：Configuration Manager (Current Branch)
原始 KB 编号： 4459394
了解状态消息传送
Configuration Manager 中的状态消息传送是一种反映特定时间点的客户端条件的机制。 相比之下，状态消息有助于管理员通过各种Configuration Manager组件跟踪数据的工作流。
状态消息查看器内置于控制台中，以便可以查看和跟踪状态消息。 状态消息没有等效的查看器。 状态消息的结果显示在：
- 报告
- 控制台中的各种数据，例如必须更新的系统数
- 客户端日志
状态消息包含有关客户端就地条件的简明信息。 状态消息传送系统由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文件。 通过解释这些日志中的状态消息，我们可以清楚地了解该过程的各个步骤中发生的情况。
在检查日志代码示例之前，必须了解状态消息格式。 状态消息本身由几个部分组成，包括主题类型和状态消息 ID。 在日志中的某些位置，似乎已为你解释 主题类型 。
不会始终在同一日志中同时看到 “主题类型” 和“ 状态消息 ID ”。 一种没有另一种类型的数据并不能真正帮助你确定所需的内容。 但是，即使同时具有 “主题类型” 和“ 状态消息 ID”，信息也无济于事，除非你可以解释它。
下图可帮助你解释 和 StateID 的组合TopicType，以获取有意义的数据。
select * from v_StateNames
注意
下表包含 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 | 已下载更新 (s) |
| 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 中的状态消息。
以下示例对齐并比较Updatesdeployment.log和Statemessage.log文件。 通过将相同的 (绿色文本) 对齐，确保日志引用相同的 TopicID 状态消息。 它清楚地指示这两个日志引用的是同一状态消息。 以 TopicType 浅蓝色文本显示。 请注意，一个日志可能会显示可从 状态消息数据 图表中解释的实际数字。 另一个可能显示 (已解释) 的泛型值。 ) 状态StateId消息 ID (以紫色文本显示。
通过将 和 状态消息 ID (StateId) 组合TopicType在图表中，可以准确跟踪日志中发生的情况。 在此示例中，这些代码示例显示了以下信息：
- 更新评估
- 评估结果
- 正在下载的更新
- 正在安装的更新
- 挂起的系统重启
这只是如何将状态消息发送到状态系统的一个示例。
状态消息传送数据流
下图是状态消息数据如何进入管理点并将其处理到数据库的实际示例。
此示例使用测试客户端。 它首先强制客户端抓取 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 使客户端将其数据重新发到管理点。
通常，使用 (VBScript) 运行 cscriptVisual Basic 脚本。 请注意，如果尝试自己运行脚本，脚本可能会失败。 问题是，Configuration Manager是在 64 位服务器上运行的 32 位应用程序。 的默认版本 cscript 是 64 位版本，通常适用于任何 VBScript。 但是，在这种情况下，所执行的调用需要 32 位版本，该版本的 cscript syswow64 文件夹必须用完。
发生下一个状态消息轮询周期时，所有状态消息都会发送到管理点。
在 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.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 。 在这一点上，幕后还有更多。 但是，如果知道 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 任务：处理消息正文
中继：FileType= SMX
中继：发件箱 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 文件的示例。 突出显示了计算机和状态消息的详细信息。 它包含我们之前讨论过的信息，以及唯一 的“状态消息 ID ”值。
注意
如果重命名这些文件，请先将它们复制到其他文件夹，以免影响 Statesys.box 文件夹。
最后，状态消息必须处理到数据库中。 在 Statesys.log 文件中，可以看到类似于以下示例的此类消息：
找到要处理的新状态消息，正在开始处理线程
线程“状态消息处理线程 #0”id：5076 已启动
CMessageProcessor - 检测到父网站“site_name”
CMessageProcessor - 处理文件：mdlbp169。Smw 工
CMessageProcessor - 处理了 1 个记录，其中 0 个无效记录。
CMessageProcessor - 已成功复制文件“mdlbp169”。SMW“到父站点 site_name。
CMessageProcessor - 处理了此批中的 1 个消息文件，其中 0 个错误文件。
线程“状态消息处理线程 #0”id：5076 正常终止
可以通过启用 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设置
| 名称 | Value1 | Value2 | Value3 |
|---|---|---|---|
| 检测信号消息间隔 | 60 | ||
| 收件箱轮询间隔 | 900 | ||
| 加载程序区块大小 | 256 | ||
| 加载程序线程 | 4 | ||
| 提取的最大区块数 | 100 | ||
| 最小丢失邮件期限 | 2880 | ||
| 重新同步检查间隔 | 15 | ||
| 重试配置 | REG_SZ | < ><配置重试模式ID=“0” RetryQueue=“0”>7200,28800,86400</Retry></Config> | 0 |
注意
- 重新同步检查间隔 设置为 60 分钟。 这是用于检查需要状态消息重新同步的系统的计划。
- “最小缺失邮件期限 ”设置为 2880。 这是请求重新同步之前必须缺少消息的时间。