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 | 安装更新（s） |
| 301 | 2 | 等待重启 |
| 301 | 3 | 等待另一个安装完成 |
| 301 | 4 | 已成功安装更新（s） |
| 301 | 5 | 挂起的系统重启 |
| 301 | 6 | 无法安装更新（s） |
| 301 | 7 | 下载更新（秒） |
| 301 | 8 | 下载的更新（s） |
| 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 文本以浅蓝色文本显示。 请注意，一个日志可能会显示可从状态消息传送数据图表中解释的实际数字。 另一个可能显示泛型值（已解释）。 状态消息 ID （StateId） 以紫色文本显示。
通过组合图表中的TopicType状态消息 ID（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 状态消息数据</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-1 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
中继：发箱 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 通过添加 .xml 扩展名重命名文件，以便该文件命名 为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 条无效记录的记录。
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 |
|---|---|---|---|
| 检测信号 Msg 间隔 | 60 | ||
| 收件箱轮询间隔 | 900 | ||
| 加载程序区块大小 | 256 | ||
| 加载程序线程 | 4 | ||
| 提取的最大区块数 | 100 | ||
| 缺少消息的最小期限 | 2880 | ||
| 重新同步检查间隔 | 15 | ||
| 重试配置 | REG_SZ | <><配置重试 PatternID=“0” RetryQueue=“0”>7200,28800,86400</Retry></Config> | 0 |
注意
- 重新同步检查间隔 设置为 60 分钟。 这是检查需要状态消息重新同步的系统的计划。
- 最小缺失消息期限 设置为 2880。 这是请求重新同步之前必须缺少的消息时长。