跟踪软件更新符合性评估

项目
11/20/2024

适用于： Configuration Manager

在将软件更新部署到客户端之前，客户端必须运行软件更新符合性扫描。我们建议客户端有足够的时间完成扫描和报告符合性结果，以便可以查看符合性结果，并仅部署客户端上所需的更新。

安装并同步软件更新点（SUP）时，将创建站点范围的计算机策略，告知客户端计算机 Configuration Manager 软件更新已启用站点。客户端收到该计算机策略后，会计划在接下来的两个小时内随机启动符合性评估扫描。启动扫描后，软件更新客户端代理进程将清除扫描历史记录，提交一个请求以查找应该用于扫描的 Windows Server Update Services （WSUS）服务器，并使用 WSUS 位置更新本地组策略。

有关合规性评估过程的概述，请参阅软件更新符合性评估。

软件更新扫描策略

在客户端尝试扫描更新之前，它需要 UpdateSource 策略。成功同步 SUP 后，此策略在站点服务器上创建。本部分讨论以下过程如何创建此策略：

步骤 1：成功同步后，WSyncMgr 更新数据库中的内容版本和上次同步时间

在主站点上成功同步后，WSyncMgr 会更新 SUP 数据库中的上次同步时间和内容版本。这是通过执行存储过程完成的 spProcessSUMSyncStateMessage 。在以下示例 SQL Server Profiler 跟踪中，将执行此存储过程，将内容版本更新为 36：

declare @Error int; exec spProcessSUMSyncStateMessage N'2014-01-17 17：59：54'， N'PS1'， N'{C2D17964-BBDD-4339-B9F3-12D7205B39CC}'， 1， 0， '36'， @Error output， N'PS1SITE.CONTOSO。COM'

步骤 2：触发 SMSDBMON 并删除一个。policypv.box 中的 STN 文件

spProcessSUMSyncStateMessageUpdate_SyncStatus使用新的内容版本和同步时间更新表。对表的 Update_SyncStatus 此更新会触发 SMSDBMON 删除 <UpdateSource_UniqueID>。STN 文件（STN 代表 policypv.box 中的扫描工具通知），以指示扫描工具定义中的更改。 SMSDBMON.log中记录以下内容：

RCV：UpdSyncStatus_iu Update_SyncStatus更新 [{C2D17964-BBDD-4339-B9F3-12D7205B39CC}][46680] SMS_DATABASE_NOTIFICATION_MONITOR
SND： Dropd E：\ConfigMgr\inboxes\policypv.box{C2D17964-BBDD-4339-B9F3-12D7205B39CC}。STN （非零） [46680] SMS_DATABASE_NOTIFICATION_MONITOR

步骤 3：策略提供程序在数据库中创建或更新 UpdateSource 策略

<UpdateSource_UniqueID>。STN 文件通知策略提供程序应唤醒并更新数据库中的 UpdateSource 策略。

以下记录PolicyPv.log：

找到 {C2D17964-BBDD-4339-B9F3-12D7205B39CC}。STN SMS_POLICY_PROVIDER
添加了扫描工具 ID {C2D17964-BBDD-4339-B9F3-12D7205B39CC} SMS_POLICY_PROVIDER
添加到删除列表：E：\ConfigMgr\inboxes\policypv.box{C2D17964-BBDD-4339-B9F3-12D7205B39CC}。STN SMS_POLICY_PROVIDER

在 SQL Server Profiler 跟踪中：

从 SettingsPolicy 中选择 PolicyID、PolicyAssignmentID、SourceCRC、PADBID，其中 SourceID = N'PS1' 和 SourceType = N'UpdateSource'

从 Policy 中选择 PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}'
IF EXISTS （从 PolicyID 中选择 PolicyID =N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}'）更新策略集版本 = N'40.00' where PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}' ELSE insert Policy （PolicyID， Version）值（N'{d0855677- b0a6-4e33-9bd5-7b0d06f0a2be}'， N'40.00'）

exec sp_describe_undeclared_parameters N'UPDATE Policy SET Body = where PolicyID = @P1 N''{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be}'''
IF EXISTS （从 POLICYAssignment 中选择 PADBID，其中 PADBID = 16777218）更新 PolicyAssignment set Version = N'40.00'， InProcess = 1， BodyHash = null where PADBID = 16777218 ELSE insert PolicyAssignment （PolicyAssignmentID， PADBID， Version， PolicyID）值（N'{375c8020-3cae-4736-89ca-ccf1ce6e3709}'， 16777218， N'40.00'， N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}'）

exec sp_describe_undeclared_parameters N'UPDATE PolicyAssignment SET Body = @P1 where PADBID = 16777218'

update PolicyAssignment set InProcess = 0， BodySignature = N'BodySignatureTruncated'， TombstoneBodySignature = N'TombstoneBodySignatureTruncated<>'， HashAlgOID = N'1.2.840.113549.1.11'， HashAlgId = 32780， BodyHash = N'BodyHashTruncated><'， TombstoneBodyHash = N'TombstoneBodyHashTruncated<>' where PADBID = 16777218<>

若要查看数据库中的此策略，请运行以下查询：

SELECT CONVERT(XML, Body, 1), * FROM Policy WHERE PolicyID = (SELECT PolicyID FROM SettingsPolicy WHERE SourceType = 'UpdateSource')

此策略包含更新服务器的内容版本，用于查找客户端可以扫描的 WSUS 计算机的位置。在数据库中创建或更新此策略后，客户端在下一个策略评估周期中获取新的或更新的 UpdateSource 策略。

步骤 4：在客户端上下载和评估策略

在客户端上PolicyAgent.log登录以下内容：

已成功启动策略“CCM_Policy_Policy5.PolicyID=”{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}“，PolicySource=”SMS：PS1“，PolicyVersion=”40.00“”PolicyAgent_ReplyAssignments
策略“CCM_Policy_Policy5.PolicyID=”{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}“，PolicyVersion=”40.00“，PolicySource=”SMS：PS1“”成功编译PolicyAgent_PolicyDownload

在客户端上的PolicyEvaluator.log：

更新策略CCM_Policy_Policy5.PolicyID=“{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be}”，PolicySource=“SMS：PS1”，PolicyVersion=“40.00” PolicyAgent_PolicyEvaluator
应用的策略CCM_Policy_Policy5.PolicyID=“{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be}”，PolicySource=“SMS：PS1”，PolicyVersion=“40.00” PolicyAgent_PolicyEvaluator
[CCM_Policy_Policy5.PolicyID=“{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}”的策略状态，PolicyVersion=“40.00”，PolicySource=“SMS：PS1”] 当前为 [Active] PolicyAgent_PolicyEvaluator

若要在客户端上查找 PolicyID UpdateSource 策略，请运行以下 WQL 查询：

命名空间：ROOT\ccm\Policy\Machine\RequestedConfig
查询：SELECT * FROM CCM_Policy_Policy5 WHERE PolicyCategory = 'UpdateSource'

在客户端上编译此策略后，UpdateSource 信息将存储在以下 WMI 类中：

命名空间：ROOT\ccm\Policy\Machine\ActualConfig
类：CCM_UpdateSource

提示

如果将客户端上的类实例 CCM_UpdateSource 与从策略表中检索的 XML 正文进行比较，你会注意到 XML 的内容与实例相同。

步骤 5：扫描代理收到更新 UpdateSource 策略的通知

在客户端上ScanAgent.log登录以下内容：

在 CScanAgent：：Notify（） ScanAgent 中
CScanAgent：：OnPolicyChange- Policy InstanceModificationEvent 通知已接收 ScanAgent

WSUS 服务器位置

收到 UpdateSource 策略后，客户端具有启动扫描所需的配置。但是，策略更新不会启动即时扫描。可以通过 Configuration Manager 控制面板手动触发扫描，也可以在下一个计划时间自动进行扫描。此时，客户端会找到 WSUS 计算机，其中包含策略中指定的内容版本。此过程与客户端查找特定包和版本的分发点的位置的方式非常相似。

步骤 1：扫描代理根据可用策略创建扫描请求

以下记录ScanAgent.log：

CScanAgent：：ScanByUpdates - 适用于 UpdateSourceID 的策略={C2D17964-BBDD-4339-B9F3-12D7205B39CC} ContentVersion=38 ScanAgent
CScanAgent：：ScanByUpdates- 向最终 ScanRequest List UpdateSourceID={C2D17964-BBDD-4339-B9F3-12D7205B39CC}、Policy-ContentVersion=38、Required-ContentVersion=38 ScanAgent

步骤 2：扫描代理将 WSUS 位置的请求发送到位置服务

扫描代理现在从位置服务请求 WSUS 位置，并等待响应。在此示例中，位置请求 ID 为 {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}。以下记录ScanAgent.log：

在 CScanAgent：:P rocessScanRequest（） ScanAgent 中
CScanJobManager：：Scan- 输入的 ScanAgent
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）： CScanJob：：Initialize- entered ScanAgent
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）： CScanJob：：Scan- entered ScanAgent
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）： CScanJob：：RequestLocations- entered ScanAgent
- - - - - -从 LS 请求 WSUS 服务器位置以获取 {C2D17964-BBDD-4339-B9F3-12D7205B39CC} 版本 38 ScanAgent
- - - - - -Location 请求 ID = {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanAgent
CScanAgentCache：:P ersistInstanceInCache- Persisted Instance CCM_ScanJobInstance ScanAgent
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）：- - 为 ScanJobID 请求的位置={4CD06388-D509-D509-46E4-8C00-75909EDD9EE8} （LocationRequestID={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}）将在可用位置后处理扫描请求。 ScanAgent

每个扫描作业存储在类中的 WMI 中 CCM_ScanJobInstance ：

命名空间：root\CCM\ScanAgent
类：CCM_ScanJobInstance

步骤 3：位置服务将位置请求发送到管理点

Location Services 创建位置请求并将其发送到管理点。 WSUS 位置请求的包 ID 是 UpdateSource 唯一 ID。以下记录LocationServices.log：

CCCMWSUSLocation：：GetLocationsAsyncEx LocationServices
尝试保留 ContentID='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}' 和 ContentVersion='38' LocationServices 的 WSUS 位置请求
持久化 WSUS 位置请求 LocationServices
尝试发送 ContentID 的 WSUS 位置请求='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}' LocationServices
WSUSLocationRequest ： <WSUSLocationRequest SchemaVersion=“1.00”><Content ID=“{C2D17964-BBDD-4339-B9F3- 12D7205B39CC}” Version=“38”/><AssignedSite SiteCode=“PS1”/><ClientLocationInfo onInternet=“0”><ADSite Name=“CM 12-R2- PS1”/><林名称=“CONTOSO.COM”/><域名=“CONTOSO.COM”/><IPAddresses><IPAddress SubnetAddress=“192.168.2.0” Address=“192.168.2.62”/></IPAddresses></ClientLocationInfo></WSUSLocationRequest> LocationServices
为包 {C2D17964-BBDD-4339-B9F3- B9F39CC} LocationServices 创建和发送位置请求“{C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}”

步骤 4：CCM 消息传送将位置请求消息发送到管理点

CcmMessaging.log中记录以下内容：

将异步消息“{76453CC6-76BA-4B68-BE30-BA70754570BB}”发送到传出队列“mp：[http]mp_locationmanager” CcmMessaging
发送传出消息“{76453CC6-76BA-4B68-BE30-BA70754570BB}”。标志0x200，发送方帐户为空 CcmMessaging

步骤 5：管理点分析请求，从数据库获取 WSUS 位置，并发送响应

管理点分析此请求，并调用 MP_GetWSUSServerLocations 存储过程从数据库获取 WSUS 位置。以下记录在MP_Location.log：

MP LM：消息正文： WSUSLocationRequest SchemaVersion=“1.00”><Content ID=“{C2D17964-BBDD-4339-B9F3- 12D7205B39CC}” Version=“38”/><AssignedSite SiteCode=“PS1”/><ClientLocationInfo onInternet=“0”><ADSite Name=“CM12-- R2- PS1”/><林名称=“CONTOSO.COM”/><域名=“CONTOSO.COM”/><IPAddresses><IPAddress SubnetAddress=“192.168.2.0” Address=“192.168.2.62”/></IPAddresses></ClientLocationInfo></WSUSLocationRequest> MP_ <LocationManager
MP LM：调用MP_GetWSUSServerLocations MP_LocationManager

在 SQL Server Profiler 跟踪中：

exec MP_GetMPSitesFromAssignedSite N'PS1'
exec MP_GetSiteInfoUnified N'ClientLocationInfo< OnInternet=“0”><ADSite Name=“CM12-R2-PS1”/><Forest Name=“CONTOSO.COM”/><Domain Name=“CONTOSO.COM”/><IPAddresses><IPAddress SubnetAddress=“192.168.2.0” Address=“192.168.2.62”/></IPAddresses></ClientLocationInfo>'
exec MP_GetWSUSServerLocations N'{C2D17964-BBDD-4339-B9F3-12D7205B39CC}'，N'38'，N'PS1'，N'PS1'，N'0'，N'CONTOSO。COM'

从存储过程获取结果后，管理点会向客户端发送响应。 MP_Location.log中记录以下内容：

MP LM：回复消息正文：
<WSUSLocationReply SchemaVersion=“1.00”><Sites Site MPSite SiteCode><=“PS1”/><LocationRecords><LocationRecord WSUSURL=“” ServerName=“http://PS1SITE.CONTOSO.COM:8530PS1SITE.CONTOSO.COM” Version== “38”/><LocationRecord WSUSURL=“https://PS1SYS.CONTOSO.COM:8531” ServerName=“PS1SYS.CONTOSO.COM” Version=“38”//><LocationRecords></Site></Sites></WSUSLocationReply>>< MP_LocationManager

步骤 6：CCM 消息传送接收响应并将其发送回位置服务

客户端上的CcmMessaging.log文件显示收到回复。此消息已传递到 Location Services：

消息“{76453CC6-76BA-4B68-BE30-BA70754570BB}”收到回复“{8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C}”到本地终结点队列“LS_ReplyLocations”CcmMessaging
OutgoingMessage（Queue='mp_[http]mp_locationmanager'， ID={76453CC6-76BA-4B68-BE30-BA70754570BB}）：已成功传送到主机“PS1SYS.CONTOSO.COM”。 CcmMessaging
消息“{8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C}”传递到终结点“LS_ReplyLocations” CcmMessaging

步骤 7：Location Services 分析响应并将位置发送回扫描代理

以下记录LocationServices.log：

处理位置回复消息 LocationServices 1/20/2014 12：18：09 PM
WSUSLocationReply ： <WSUSLocationReply SchemaVersion=“1.00”><Sites><Site MPSite SiteCode><=“PS1”/><LocationRecords><LocationRecord WSUSURL=“” ServerName=“http://PS1SITE.CONTOSO.COM:8530PS1SITE.CONTOSO.COM” Version=“38”/><LocationRecord WSUSURL=“https://PS1SYS.CONTOSO.COM:8531” ServerName=“PS1SYS.CONTOSO.COM” Version=“38”//LocationRecords></><Site></Sites></WSUSLocationReply> LocationServices
使用以下 WSUS 位置 LocationServices 进行回叫
WSUS Path=''http://PS1SITE.CONTOSO.COM:8530，Server='PS1SITE。CONTOSO。COM'， Version='38' LocationServices
WSUS Path=''https://PS1SYS.CONTOSO.COM:8531，Server='PS1SYS。CONTOSO。COM'， Version='38' LocationServices
使用 WSUS 请求的位置调用 {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} LocationServices

步骤 8：扫描代理通知 WUAHandler 将更新源添加到注册表

扫描代理现在具有具有相应内容版本的策略和更新源位置。以下记录ScanAgent.log：

为位置请求 guid={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanAgent 收到的 WSUSLocationUpdate
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）： CScanJob：：OnLocationUpdate- Received Location=http://PS1SITE.CONTOSO.COM:8530， Version=38 ScanAgent
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）： CScanJob：：Execute- 添加 UpdateSource={C2D17964-BBDD-4339-B9F3-12D7205B39CC}， ContentType=2， ContentLocation=http://PS1SITE.CONTOSO.COM:8530， ContentVersion=38 ScanAgent

扫描代理通知 WUAHandler 添加更新源。 WUAHandler 将更新源添加到注册表，并启动组策略刷新（如果客户端位于域中），以查看组策略是否替代刚刚添加的更新服务器。下面记录在新客户端上的WUAHandler.log，其中显示了要添加的新更新源：

其 WSUS 更新源类型（{C2D17964-BBDD-4339-B9F3-12D7205B39CC}），将其添加。 WUAHandler
其全新的 WSUS 更新源。 WUAHandler
启用 WUA 托管服务器策略以使用服务器： http://PS1SITE.CONTOSO.COM:8530 WUAHandler
强制策略刷新。 WUAHandler
等待 2 分钟组策略通知 WUA 策略更改...WUAHandler
等待 30 秒的策略对 WU 代理生效。 WUAHandler
添加了内容类型的更新源（{C2D17964-BBDD-4339-B9F3-12D7205B39CC}）内容类型：2 WUAHandler

在此期间，Windows 更新代理会看到 WSUS 配置更改。以下记录在WindowsUpdate.log：

2014-01-20 12：18：11：520 968 9d0 代理 * WSUS 服务器： http://PS1SITE.CONTOSO.COM:8530 （已更改）
2014-01-20 12：18：11：520 968 9d0 代理 * WSUS 状态服务器： http://PS1SITE.CONTOSO.COM:8530 （已更改）
2014-01-20 12：18：11：520 968 9d0 AU Sus 服务器通过策略更改。

检查并设置以下注册表项：

注册表子项	值名称	类型	数据
`HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate`	WUServer	REG_SZ	完整的 WSUS 服务器 URL，包括端口。例如： `http://PS1Site.Contoso.com:8530`
`HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate`	WUStatusServer	REG_SZ	完整的 WSUS 服务器 URL，包括端口。例如： `http://PS1Site.Contoso.com:8530`
`HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU`	UseWUServer	REG_DWORD	0x1

对于现有客户端，我们预计在内容版本递增时，WUAHandler.log中看到以下内容：

其 WSUS 更新源类型（{C2D17964-BBDD-4339-B9F3-12D7205B39CC}），将其添加。 WUAHandler
WSUS 更新源已存在，版本已增加到 38。 WUAHandler

步骤 9：扫描代理启动扫描

成功添加更新源后，扫描代理将引发状态消息并启动扫描。以下记录ScanAgent.log：

ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）：引发 UpdateSource （{C2D17964-BBDD-4339-B9F3-12D7205B39CC}）状态消息成功。 StateId = 2 ScanAgent
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）：CScanJob：：Execute - 已成功请求扫描，ScanType=1 ScanAgent

客户端上的软件更新扫描

更新源策略和更新源位置可用后，扫描代理将启动扫描。软件更新扫描实际上是由 Windows 更新代理执行的。但是，Configuration Manager 客户端与 Windows 更新代理交互以执行扫描并获取扫描结果。此交互由与 Windows 更新代理通信的 Windows 更新代理处理程序（WUAHandler）组件处理。

步骤 1：扫描代理请求扫描，WUAHandler 启动扫描

扫描代理从 WUAHandler 请求扫描，该扫描使用 Windows 更新代理 API 从 Windows 更新代理请求软件更新扫描。 ScanAgent.log中记录以下内容：

ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）：CScanJob：：Execute - 已成功请求扫描，ScanType=1 ScanAgent

WUAHandler.log中记录以下内容：

仅当被 Service Pack 和定义更新取代时，扫描结果才会包括被取代的更新。 WUAHandler
搜索条件为（DeploymentAction=* AND Type='Software'） OR （DeploymentAction=* AND Type='Driver'） WUAHandler
运行更新的单调用扫描。 WUAHandler
已启动使用 WUAgent 对更新进行异步搜索。 WUAHandler

步骤 2：Windows 更新代理（WUA）启动针对 WSUS 计算机的扫描

Windows 更新代理从 Configuration Manager 客户端（CcmExec）收到请求后启动扫描。由于Windows 更新服务器值已设置为 SUP 服务器，因此对安装了 SUP 角色的 WSUS 服务器执行此扫描。以下记录在WindowsUpdate.log：

2014-01-20 12：18：42：694 3856 708 COMAPI -- START -- COMAPI： Search [ClientId = CcmExec]
2014-01-20 12：18：42：752 3856 708 COMAPI -- SUBMITTED -- COMAPI <<： Search [ClientId = CcmExec]
2014-01-20 12：18：47：511 968 f58 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}，服务器 URL = http://PS1SITE.CONTOSO.COM:8530/ClientWebService/client.asmx
2014-01-20 12：18：48：662 968 f58 代理 ** START ** 代理：查找更新 [CallerId = CcmExec]
2014-01-20 12：18：48：662 968 f58 代理 * 包括可能取代的更新
2014-01-20 12：18：48：662 968 f58 代理 * Online = 是;忽略下载优先级 = 是
2014-01-20 12：18：48：662 968 f58 代理 * Criteria = “（DeploymentAction=* AND Type='Software'） OR （DeploymentAction=* AND Type='Driver'）”
2014-01-20 12：18：48：662 968 f58 代理 * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} 托管
2014-01-20 12：18：48：662 968 f58 代理 * 搜索范围 = {Machine}

Windows 更新代理现在扫描 WSUS 服务器，并将结果报告给 CcmExec（特别是 WUAHandler）。以下记录在WindowsUpdate.log：

2014-01-20 12：18：49：175 968 f58 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}，服务器 URL = http://PS1SITE.CONTOSO.COM:8530/ClientWebService/client.asmx
2014-01-20 12：18：52：680 968 f58 代理 * 添加了更新 {4AE85C00-0EAA-4BE0-B81B-DBD7053D5FAE}.104 tosearch 结果
2014-01-20 12：18：52：683 968 f58 代理 * 向搜索结果添加了更新 {57260DFE-227C-45E3-9FFC-2FC77A67F95A}.104
2014-01-20 12：18：52：694 968 f58 代理 * 在搜索中找到 163 个更新和 70 个类别：评估的 appl。1150 个已部署实体中 622 个规则
2014-01-20 12：18：52：745 968 f58 代理 ** END ** 代理：查找更新 [CallerId = CcmExec]
2014-01-20 12：18：52：755 3856 708 COMAPI -- RESUMED -- COMAPI >>： Search [ClientId = CcmExec]
2014-01-20 12：18：53：137 3856 708 COMAPI - 找到的更新 = 163
2014-01-20 12：18：53：137 3856 708 COMAPI -- END -- COMAPI： Search [ClientId = CcmExec]

步骤 3：WUAHandler 接收来自Windows 更新代理的结果，并将扫描标记为已完成

WUAHandler.log中记录以下内容：

异步搜索已完成。 WUAHandler
已完成在单个调用中搜索所有内容。 WUAHandler

步骤 4：WUAHandler 分析扫描结果

然后，WUAHandler 分析结果，其中包括每个更新的适用性状态。在此过程中，取代的更新将被淘汰。WUAHandler.log中记录以下内容：

修剪：更新 ID （70f4f236-0248-4e84-b472-292913576fa1）被（726b7201-862a-4fde-9b12-f36b38323a6f）取代。 WUAHandler
...
更新（已安装）：Windows 7 的安全更新（适用于基于 x64 的系统（KB2584146）（4ae85c00-0eaa-4be0-b81b-dbd7053d5fae， 104） WUAHandler
更新（缺失）：Windows 7 的基于 x64 的系统安全更新（KB2862152）（505fda07-b4f3-45fb-83d9-8642554e2773， 200） WUAHandler
...
成功完成扫描。 WUAHandler

步骤 5：更新存储记录状态，并为 WMI 中的每个更新引发状态消息

扫描结果可用后，这些结果将存储在更新存储中。更新存储记录每个更新的当前状态，并为每个更新创建状态消息。这些状态消息会在状态消息报告周期结束时批量转发到站点服务器（默认为 15 分钟）。

UpdatesStore.log显示正在记录的缺失更新（KB2862152）的状态，并引发状态消息：

处理更新状态（505fda07-b4f3-45fb-83d9-8642554e2773），ProductID = 0fa1201d-4330-4fa8-8ae9- b877473b6441 UpdatesStore
更新状态（505fda07-b4f3-45fb-83d9-8642554e2773）之前尚未报告，创建新实例。 UpdatesStore
已成功引发状态消息，用于更新（505fda07-b4f3-45fb-83d9-8642554e2773）的状态消息（缺少）。 UpdatesStore
已成功添加更新状态的 WMI 实例（505fda07-b4f3-45fb-83d9-8642554e2773）。 UpdatesStore

StateMessage.log显示状态消息，其中 记录了状态 ID 2 （缺失）：

使用 TopicType 500 和 TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 向 WMI StateMessage 添加消息
状态消息（状态 ID ： 2）已记录 SYSTEM StateMessage 的 TopicType 500 和 TopicId 505fda07-b4f3-45fb-83d9-8642554e2773

对于每个更新，将创建或更新类的 CCM_UpdateStatus 实例，这会存储更新的当前状态。 CCM_UpdateStatus 类位于 ROOT\CCM\SoftwareUpdates\UpdatesStore 命名空间中。

CCM_UpdateStatus类实例的屏幕截图。

同样，将创建或更新类的 CCM_StateMsg 实例，这会存储更新的当前状态。 CCM_StateMsg 类位于 ROOT\CCM\StateMsg 命名空间中。

CCM_StateMsg类实例的屏幕截图。

步骤 6：状态消息发送到管理点

如前所述，状态消息会根据状态消息报告周期计划（默认配置为 15 分钟）发送到管理点。将状态消息发送到管理点后， MessageSent 类中 CCM_StateMsg 状态消息实例的属性将设置为 True。

在StateMessage.log：

StateMessage 正文： <XML 报告正文截断> StateMessage
已成功将状态消息转发到 MP StateMessage

以下是状态消息正文对于更新的外观。通常，此 XML 正文对于日志太大，在 CMTrace 中被截断。但是，可以在记事本中看到整个 XML 正文。

StateMessage 正文： <？xml version=“1.0” encoding=“UTF-16”？>
<ReportHeader Identification Machine ClientInstalled>1</ClientInstalled><ClientType 1</ClientType>><ClientID>GUID： A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.00.7958.1000</ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName><>CodePage>437</CodePage><SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5</><><><><Priority></Machine></Identification><ReportDetails><ReportContent State Message Data</ReportContent><>ReportType Full</ReportType><>Date>20140120194656.903000+000</Date><Version 1.0</Version><>格式>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime=“20140120171855.573000+000” SerialNumber=“232”><主题 ID=“505fda07-b4f3-45fb-83d9-8642554e2773” Type=“500” IDType=“3” User=“” UserSID =“”/><State ID=“2” Criticality=“0”/><UserParameters Flags=“0” Count=“1”><Param 200</Param><>/UserParameters></StateMessage/ReportBody></Report> StateMessage><
已成功将状态消息转发到 MP StateMessage

状态消息处理流

现在，我们知道如何记录状态消息以及存储这些状态消息的 WMI 位置。我们还知道，默认情况下，客户端上的未发送状态消息每 15 分钟发送到管理点，具体取决于状态消息报告周期。可以在自定义或默认客户端设置的状态消息传送中修改此计划。

尽管StateMessage.log报告 已成功将状态消息转发到 MP，但状态消息组件实际上不会发送这些消息本身。从管理点发送和接收的所有消息均由客户端上的 CCM 消息传送组件处理。 CCM 消息传送是与管理点进行通信以发送和接收数据的实际组件。管理点定义了用于处理不同类型的传入流量的各种队列。对于状态消息，处理此流量的队列是 MP_RelayEndpoint 队列。

步骤 1：状态消息组件开始将消息发送到管理点

在StateMessage.log：

StateMessage 正文：<？xml version=“1.0” encoding=“UTF-16”？><ReportHeader Identification Machine ClientInstalled>1</ClientInstalled><ClientType 1</ClientType>><ClientID>GUID： A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.00.7958.1000</ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName><>CodePage>437</CodePage><SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5</><><><><Priority></Machine></Identification><ReportDetails><ReportContent State Message Data</ReportContent><>ReportType Full</ReportType><>Date>20140120194656.903000+000</Date><Version 1.0</Version><>格式>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime=“20140120171855.573000+000” SerialNumber=“232”><主题 ID=“505fda07-b4f3-45fb-83d9-8642554e2773” Type=“500” IDType=“3” User=“” UserSID =“”/><State ID=“2” Criticality=“0”/><UserParameters Flags=“0” Count=“1”><Param 200</Param><>/UserParameters></StateMessage/ReportBody></Report> StateMessage><
已成功将状态消息转发到 MP StateMessage

步骤 2：CCM 消息传送将包含状态消息 XML 正文的消息发送到管理点

CCM 消息传送成功将消息发送到 MP_RelayEndpoint 队列。此消息没有答复，与我们之前在 WSUS 位置请求部分中注意到的回复不同，其中包含位置请求的消息收到答复。

在CcmMessaging.log：

将异步消息“{95F79010-D0EB-49A6-8A1E-3897883105F2}”发送到传出队列“mp：mp_relayendpoint” CcmMessaging
发送传出消息“{95F79010-D0EB-49A6-8A1E-3897883105F2}”。标志0x200，发送方帐户为空 CcmMessaging
POST：Host=PS1SYS。CONTOSO.COM、Path=/ccm_system/request、Port=443、Protocol=https、Flags=512、Options=480 CcmMessaging
消息“{95F79010-D0EB-49A6-8A1E-3897883105F2}”没有回复 CcmMessaging
OutgoingMessage（Queue='mp_mp_relayendpoint'， ID={95F79010-D0EB-49A6-8A1E-3897883105F2}）：已成功传送到主机“PS1SYS.CONTOSO.COM”。 CcmMessaging

步骤 3：在管理点上接收消息，然后MP_Relay处理该消息并创建 SMX 文件

由于所有消息都使用 HTTP/HTTPS 发送，并由 IIS 接收。在此示例中，向CCM_System虚拟目录发出此请求。

在 IIS 日志中：

192.168.2.12 CCM_POST /ccm_system/request - 443 - 192.168.2.62 ccmhttp - 200 0 0 542 31

成功在管理点上收到消息后， MP_Relay 组件将处理此消息，将消息转换为 SMX 文件，并将 SMX 文件移动到适当的位置，具体取决于管理点是否并置在站点服务器上。

在远程管理点：\SMS\mp\outboxes\StateMsg.box
在站点服务器上并置的管理点上：\inboxes\auth\StateSys.box\incoming

在位于站点服务器上的管理点MP_Relay.log：

Mp 消息处理程序：启动中继的消息处理----------------------- MP_RelayEndpoint
Mp 消息处理程序：FileType=SMX MP_RelayEndpoint
消息正文： <XML 正文截> 断MP_RelayEndpoint
中继：发箱 dir：E：\ConfigMgr\inboxes\auth\statesys.box\incoming MP_RelayEndpoint
消息中的优先级 = 5 MP_RelayEndpoint
状态优先级目录 = E：\ConfigMgr\inboxes\auth\statesys.box\incoming MP_RelayEndpoint
Inv-Relay：任务成功完成MP_RelayEndpoint

在远程管理点上的MP_Relay.log：

Mp 消息处理程序：启动中继的消息处理------------------------------ MP_RelayEndpoint
Mp 消息处理程序：FileType=SMX MP_RelayEndpoint
消息正文：
<？xml version=“1.0” encoding=“UTF-16”？>
<ReportHeader Identification Machine ClientInstalled>1</ClientInstalled><ClientType 1</ClientType>><ClientID>GUID： A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.00.7958.1000</ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName><>CodePage>437</CodePage><SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5</><><><><Priority></Machine></Identification><ReportDetails><ReportContent State Message Data</ReportContent><>ReportType Full</ReportType><>Date>20140120194656.903000+000</Date><Version 1.0</Version><>格式>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime=“20140120171855.573000+000” SerialNumber=“232”><主题 ID=“505fda07-b4f3-45fb-83d9-8642554e2773” Type=“500” IDType=“3” User=“” UserSID =“”/><State ID=“2” Criticality=“0”/><UserParameters Flags=“0” Count=“1”><Param 200</Param><>/UserParameters></StateMessage></ReportBody></Report> MP_RelayEndpoint
Inv-Relay 任务：处理消息正文MP_RelayEndpoint
中继：发箱 dir： C：\SMS\mp\outboxes\StateMsg.box MP_RelayEndpoint
消息中的优先级 = 5 MP_RelayEndpoint
State Priority Directory = C：\SMS\mp\outboxes\StateMsg.box MP_RelayEndpoint
Inv-Relay：任务成功完成MP_RelayEndpoint

XML 正文看起来与客户端上StateMessage.log登录的内容相同。

步骤 4：MP 文件调度管理器将 SMX 文件发送到站点服务器（仅当管理点未并置在站点服务器上时）

当管理点远程到站点服务器时，文件到达发件箱\StateMsg.box 后，MP 文件调度管理器（MPFDM）负责将这些文件移动到站点服务器上的 StateMsg.box 收件箱。在站点服务器上并置管理点时，这些文件将直接移动到相应的收件箱文件夹，因此不涉及 MPFDM。

在远程管理点MPFDM.log：

移动了文件 C：\SMS\MP\OUTBOXES\statemsg.box\TAZGYTSJ。SMX 到 \\PS1SITE.CONTOSO.COM\SMS_PS1\inboxes\auth\statesys.box\incoming\TAZGYTSJ。SMX SMS_MP_FILE_DISPATCH_MANAGER

要使 MPFDM 将文件移动到相应的收件箱，远程管理点必须能够访问站点服务器的注册表以确定收件箱源位置。因此，远程注册表服务必须正在运行，组策略不应阻止注册表访问。 MPFDM 通过访问站点服务器上的以下注册表项来确定收件箱位置：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Inbox Source

步骤 5：站点服务器上的 StateSys 组件将状态消息处理到数据库

文件到达站点服务器上的 \inboxes\auth\StateSys.box 后，State System Manager （StateSys）组件将唤醒并处理 SMX 文件。

在启用了详细日志记录的StateSys.log中：

触发收件箱通知，暂停 10 秒......SMS_STATE_SYSTEM
找到要处理的新状态消息，开始处理线程SMS_STATE_SYSTEM
线程“状态消息处理线程 #0” id：4316 已启动SMS_STATE_SYSTEM
总切克加载（1） SMS_STATE_SYSTEM
CMessageProcessor - 处理文件：YCE2H3VD。SMX SMS_STATE_SYSTEM
CMessageProcessor - 处理了 1 条无效记录的记录。 SMS_STATE_SYSTEM
CMessageProcessor - 处理了此批中的 1 个消息文件，其中 0 个错误的文件。 SMS_STATE_SYSTEM
总切克加载（0） SMS_STATE_SYSTEM
线程“状态消息处理线程 #0” id：4316 已正常终止SMS_STATE_SYSTEM

在未启用详细日志记录的StateSys.log中：

找到要处理的新状态消息，开始处理线程SMS_STATE_SYSTEM
线程“状态消息处理线程 #0” id：1988 已启动SMS_STATE_SYSTEM
总切克加载（1） SMS_STATE_SYSTEM
总切克加载（0） SMS_STATE_SYSTEM
线程“状态消息处理线程 #0” id：1988 已正常终止SMS_STATE_SYSTEM

除非为 State System Manager 启用了详细日志记录，否则StateSys.log文件不会记录文件名。

移动到 StateSys.box 文件夹的 SMX 文件包含消息正文 XML。当 StateSys 处理此文件时，它将调用 spProcessStateReport 存储过程，并将此 XML 正文作为参数传递给存储过程。

在 SQL Server Profiler 跟踪中：

exec dbo.spProcessStateReport N'<？xml version=“1.0” encoding=“UTF-16”？>
<ReportHeader Identification Machine ClientInstalled>1</ClientInstalled><ClientType 1</ClientType>><ClientID>GUID： A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.00.7958.1000</ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName><>CodePage>437</CodePage><SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5</><><><><Priority></Machine></Identification><ReportDetails><ReportContent State Message Data</ReportContent><>ReportType Full</ReportType><>Date>20140120220131.071000+000</Date><Version 1.0</Version><>格式>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime=“20140120171855.573000+000” SerialNumber=“239”><主题 ID=“505fda07-b4f3-45fb-83d9-8642554e2773” Type=“500” IDType=“3” User=“” UserSID=“”/><State ID=“2” Criticality=“0”/><UserParameters Flags=“0” Count=“1”><Param 200</Param><>/UserParameters></StateMessage></ReportBody></Report>'

spProcessStateReport 是 CLR 存储过程，CLR 定义具有确定正在处理的状态消息类型的逻辑。根据状态消息的类型，它会适当地处理状态消息，并在数据库中插入数据。

可以通过使用以下命令查询SR_StateNames表来查找所有状态消息主题类型和 ID 的友好名称：

SELECT * FROM SR_StateNames

软件更新摘要

在控制台或报表中显示软件更新符合性数据之前，必须汇总软件更新符合性数据。这是必要的，因为控制台和报表通常只显示汇总的数据。站点服务器上的状态系统组件执行软件更新摘要以及其他组件的汇总，例如应用程序、DCM 部署和客户端运行状况。可以通过查询 vSR_SummaryTasks Configuration Manager 数据库中的视图来查找状态系统执行的所有汇总任务的相关信息。状态系统按配置的计划和记录有关StateSys.log中每个任务的详细信息：

启动的任务“TaskName>”<SMS_STATE_SYSTEM
任务“<TaskName>”在运行 15 秒后成功完成，状态为 8。 SMS_STATE_SYSTEM

对于其中大多数任务，StateSys.log记录的状态不是错误代码。而是执行汇总的相应 SQL Server 存储过程返回的行数。

特定于软件更新的摘要任务包括：

SUM 分配符合性评估器

汇总所有软件更新组分配的状态消息（部署）。默认情况下，此任务每小时运行一次。可以为 Configuration Manager 控制台>监视>部署中的特定部署手动启动它，右键单击部署，然后单击“运行摘要”。
SUM 更新组状态摘要生成器

汇总更新组的状态。默认情况下，此任务每小时运行一次。可为 Configuration Manager 控制台>软件更新>>软件更新组中的特定更新组手动启动它，右键单击更新组，然后单击“运行摘要”。

还可以通过右键单击软件更新组或在功能区中选择“计划摘要”来更改此任务的计划。
SUM 更新状态摘要生成器

汇总所有客户端的更新状态。默认情况下，此任务每小时运行一次。可以在 Configuration Manager 控制台>软件库>软件更新中手动启动它，然后单击“运行摘要”。还可以通过选择“计划摘要”来更改默认计划。
SUM Migrate 更新状态

在数据库中内部迁移更新状态。默认情况下，此任务每 24 小时运行一次。无法从 Configuration Manager 控制台手动启动它。
SUM 删除过期状态

从数据库中的软件更新特定表中删除过期状态。默认情况下，此任务每 24 小时运行一次。无法从 Configuration Manager 控制台手动启动它。

软件更新点切换

在 System Center 2012 Configuration Manager SP1 和更高版本中，站点可以有多个 SUP。这为 SUP 不可用的情况提供容错。有关 SUP 故障转移和切换的详细信息，请参阅以下文章：

通过

跟踪软件更新符合性评估

软件更新扫描策略

步骤 1：成功同步后，WSyncMgr 更新数据库中的内容版本和上次同步时间

步骤 2：触发 SMSDBMON 并删除一个。policypv.box 中的 STN 文件

步骤 3：策略提供程序在数据库中创建或更新 UpdateSource 策略

步骤 4：在客户端上下载和评估策略

步骤 5：扫描代理收到更新 UpdateSource 策略的通知

WSUS 服务器位置

步骤 1：扫描代理根据可用策略创建扫描请求

步骤 2：扫描代理将 WSUS 位置的请求发送到位置服务

步骤 3：位置服务将位置请求发送到管理点

步骤 4：CCM 消息传送将位置请求消息发送到管理点

步骤 5：管理点分析请求，从数据库获取 WSUS 位置，并发送响应

步骤 6：CCM 消息传送接收响应并将其发送回位置服务

步骤 7：Location Services 分析响应并将位置发送回扫描代理

步骤 8：扫描代理通知 WUAHandler 将更新源添加到注册表

步骤 9：扫描代理启动扫描

客户端上的软件更新扫描

步骤 1：扫描代理请求扫描，WUAHandler 启动扫描

步骤 2：Windows 更新代理（WUA）启动针对 WSUS 计算机的扫描

步骤 3：WUAHandler 接收来自Windows 更新代理的结果，并将扫描标记为已完成

步骤 4：WUAHandler 分析扫描结果

步骤 5：更新存储记录状态，并为 WMI 中的每个更新引发状态消息

步骤 6：状态消息发送到管理点

状态消息处理流

步骤 1：状态消息组件开始将消息发送到管理点

步骤 2：CCM 消息传送将包含状态消息 XML 正文的消息发送到管理点

步骤 3：在管理点上接收消息，然后MP_Relay处理该消息并创建 SMX 文件

步骤 4：MP 文件调度管理器将 SMX 文件发送到站点服务器（仅当管理点未并置在站点服务器上时）

步骤 5：站点服务器上的 StateSys 组件将状态消息处理到数据库

软件更新摘要

软件更新点切换

反馈

其他资源

通过

跟踪软件更新符合性评估

软件更新扫描策略

步骤 1：成功同步后，WSyncMgr 更新数据库中的内容版本和上次同步时间

步骤 2：触发 SMSDBMON 并删除一个 。policypv.box 中的 STN 文件

步骤 3：策略提供程序在数据库中创建或更新 UpdateSource 策略

步骤 4：在客户端上下载和评估策略

步骤 5：扫描代理收到更新 UpdateSource 策略的通知

WSUS 服务器位置

步骤 1：扫描代理根据可用策略创建扫描请求

步骤 2：扫描代理将 WSUS 位置的请求发送到位置服务

步骤 3：位置服务将位置请求发送到管理点

步骤 4：CCM 消息传送将位置请求消息发送到管理点

步骤 5：管理点分析请求，从数据库获取 WSUS 位置，并发送响应

步骤 6：CCM 消息传送接收响应并将其发送回位置服务

步骤 7：Location Services 分析响应并将位置发送回扫描代理

步骤 8：扫描代理通知 WUAHandler 将更新源添加到注册表

步骤 9：扫描代理启动扫描

客户端上的软件更新扫描

步骤 1：扫描代理请求扫描，WUAHandler 启动扫描

步骤 2：Windows 更新代理（WUA）启动针对 WSUS 计算机的扫描

步骤 3：WUAHandler 接收来自Windows 更新代理的结果，并将扫描标记为已完成

步骤 4：WUAHandler 分析扫描结果

步骤 5：更新存储记录状态，并为 WMI 中的每个更新引发状态消息

步骤 6：状态消息发送到管理点

状态消息处理流

步骤 1：状态消息组件开始将消息发送到管理点

步骤 2：CCM 消息传送将包含状态消息 XML 正文的消息发送到管理点

步骤 3：在管理点上接收消息，然后MP_Relay处理该消息并创建 SMX 文件

步骤 4：MP 文件调度管理器将 SMX 文件发送到站点服务器（仅当管理点未并置在站点服务器上时）

步骤 5：站点服务器上的 StateSys 组件将状态消息处理到数据库

软件更新摘要

软件更新点切换

反馈

其他资源

步骤 2：触发 SMSDBMON 并删除一个。policypv.box 中的 STN 文件