跟踪软件更新符合性评估
适用范围：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：已删除 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'
从 PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}' 中选择“版本”
如果 EXISTS (从 PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}') 更新策略集版本 = N'40.00' ，其中 PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}'ELSE 插入策略 (PolicyID，版本) 值 (N'{d0855677- b0a6-4e33-9bd5-7b0d06f0a2be}'， N'40.00')exec sp_describe_undeclared_parameters N'UPDATE Policy SET Body = @P1 where PolicyID = N'''{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be}'''
如果 EXISTS (从 PolicyAssignment 中选择 PADBID，其中 PADBID = 16777218) update 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.1.11'， HashAlgId = 32780， BodyHash = N'BodyHashTruncated<>'， TombstoneBodyHash = N'TombstoneBodyHashTruncated<>' ，其中 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 - 策略实例ModificationEvent 通知已收到 ScanAgent
WSUS 服务器位置
收到 UpdateSource 策略后，客户端具有启动扫描所需的配置。 但是，策略更新不会启动即时扫描。 扫描可以通过Configuration Manager控制面板手动触发，也可以在下一个计划时间自动进行。 此时，客户端将找到具有策略中指定的内容版本的 WSUS 计算机。 此过程与客户端查找特定包和版本的分发点位置的方式非常相似。
步骤 1：扫描代理基于可用策略创建扫描请求
以下记录ScanAgent.log：
CScanAgent：：ScanByUpdates - 可用于 UpdateSourceID={C2D17964-BBDD-4339-B9F3-12D7205B39CC} ContentVersion=38 ScanAgent
CScanAgent：：ScanByUpdates - 已将策略添加到最终 ScanRequest 列表 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- 输入的 ScanAgent
ScanJob ({4CD06388-D509-46E4-8C00-75909EDD9EE8}) ：CScanJob：：RequestLocations- entered ScanAgent
- - - - -从 LS 请求 WSUS 服务器位置，用于 {C2D17964-BBDD-4339-B9F3-12D7205B39CC} 版本 38 ScanAgent
- - - - -位置请求 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：定位服务将位置请求发送到管理点
位置服务创建位置请求并将其发送到管理点。 WSUS 位置请求的包 ID 是 UpdateSource 唯一 ID。 以下记录LocationServices.log：
CCCMWSUSLocation：：GetLocationsAsyncEx LocationServices
尝试保留 ContentID='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}' 和 ContentVersion='38' LocationServices 的 WSUS 位置请求
持久化 WSUS 位置请求 LocationServices
尝试发送 ContentID='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}的 WSUS 位置请求
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”/><Forest Name=“CONTOSO.COM”/><Domain Name=“CONTOSO.COM”/><IPAddresses IPAddress><SubnetAddress=“192.168.2.0” Address=“192.168.2.62”/></IPAddresses></ClientLocationInfo></WSUSLocationRequest> LocationServices
为包 {C2D17964-BBDD-4339-B9F3- 12D7205B39CC} 创建并发送了位置请求“{C2BB9710-C548-49D0-9DF8-5F9CFC5F3F3862}” LocationServices
步骤 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”/><Forest Name=“CONTOSO.COM”/><Domain Name=“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=“http://PS1SITE.CONTOSO.COM:8530” ServerName=“PS1SITE.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 文件显示已收到答复。 此消息已传递到位置服务：
消息“{76453CC6-76BA-4B68-BE30-BA70754570BB}”已向本地终结点队列“LS_ReplyLocations”CcmMessaging“回复”{8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C}”
OutgoingMessage (Queue='mp_[http]mp_locationmanager'， ID={76453CC6-76BA-4B68-BE30-BA70754570BB}) ：已成功传送到主机“PS1SYS.CONTOSO.COM”。 CcmMessaging
传递到终结点“LS_ReplyLocations”CcmMessaging“的消息”{8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C}”
步骤 7：定位服务分析响应并将位置发送回扫描代理
以下记录LocationServices.log：
处理位置回复消息 LocationServices 1/20/2014 12：18：09 PM
WSUSLocationReply ： <WSUSLocationReply SchemaVersion=“1.00”><Sites><Site><MPSite SiteCode=“PS1”/><LocationRecords><LocationRecord WSUSURL=“http://PS1SITE.CONTOSO.COM:8530” ServerName=“PS1SITE.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：
WSUSLocationUpdate 已收到位置请求 guid={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanAgent
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:8530WUAHandler
策略刷新已强制。 WUAHandler
等待 2 分钟，等待组策略通知 WUA 策略更改...WUAHandler
等待 30 秒策略在 WU 代理上生效。 WUAHandler
添加了内容类型为 2 WUAHandler 的更新源 ({C2D17964-BBDD-4339-B9F3-12D7205B39CC})
在此期间，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 更新 代理处理程序 (WUAHandler) 组件处理，该组件与 Windows 更新 代理通信。
步骤 1：扫描代理请求扫描，WUAHandler 启动扫描
扫描代理从 WUAHandler 请求扫描，WUAHandler 使用 Windows 更新 代理 API 从 Windows 更新 代理请求软件更新扫描。 以下记录ScanAgent.log：
ScanJob ({4CD06388-D509-46E4-8C00-75909EDD9EE8}) ：CScanJob：：Execute - 已成功请求扫描，ScanType=1 ScanAgent
以下记录WUAHandler.log：
仅当被 Service Pack 和定义更新取代时，扫描结果才会包括被取代的更新。 WUAHandler
搜索 Criteria 为 (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver') WUAHandler
运行更新的单调用扫描。 WUAHandler
已启动使用 WUAgent 对更新进行异步搜索。 WUAHandler
步骤 2：Windows 更新代理 (WUA) 启动对 WSUS 计算机的扫描
Windows 更新 代理在收到来自 Configuration Manager 客户端 (CcmExec) 的请求后开始扫描。 由于 Windows 更新 Server 值已设置为 SUP 服务器，因此，此扫描针对安装了 SUP 角色的 WSUS 服务器执行。 以下记录WindowsUpdate.log：
2014-01-20 12：18：42：694 3856 708 COMAPI -- START -- COMAPI： 搜索 [ClientId = CcmExec]
2014-01-20 12：18：42：752 3856 708 COMAPI <<-- 已提交 -- COMAPI： 搜索 [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 代理 * 联机 = 是;忽略下载优先级 = 是
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 代理 * 搜索 Scope = {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 result
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： 搜索 [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： 搜索 [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
...
已安装更新 () ：适用于基于 x64 系统的 Windows 7 安全更新 (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：已为 SYSTEM StateMessage 记录了 TopicType 500 和 TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 的 2)
对于每次更新，都会创建或更新 类的 CCM_UpdateStatus 实例，这将存储更新的当前状态。 类 CCM_UpdateStatus 位于 命名空间中 ROOT\CCM\SoftwareUpdates\UpdatesStore 。
同样，将创建或更新 类的 CCM_StateMsg 实例，这将存储更新的当前状态。 类 CCM_StateMsg 位于 命名空间中 ROOT\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”？>
<Report><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><优先级>5</Priority></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent><ReportType>Full</ReportType><Date>20140120194656.903000+000</Date><Version>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime=“20140120171855.573000+000” SerialNumber=“232”><Topic 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”？><Report><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><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime=“20140120171855.573000+000” SerialNumber=“232”><Topic 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
State Priority Directory = 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”？>
<Report><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><优先级>5</Priority></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent><ReportType>Full</ReportType><Date>20140120194656.903000+000</Date><Version>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime=“20140120171855.573000+000” SerialNumber=“232”><Topic 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 文件 (s) 。
在启用了详细日志记录的StateSys.log中：
收件箱通知已触发，暂停 10 秒......SMS_STATE_SYSTEM
找到要处理的新状态消息，正在启动处理线程SMS_STATE_SYSTEM
线程“状态消息处理线程 #0”id：4316 已启动SMS_STATE_SYSTEM
加载的总 chuck (1) SMS_STATE_SYSTEM
CMessageProcessor - 处理文件：YCE2H3VD。SMX SMS_STATE_SYSTEM
CMessageProcessor - 处理了 1 个记录，其中 0 个无效记录。 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
加载的总 chuck (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”？>
<Report><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><优先级>5</Priority></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent><ReportType>Full</ReportType><Date>20140120220131.071000+000</Date><Version>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime=“20140120171855.573000+000” SerialNumber=“239”><Topic ID=“505fda07-b4f3-45fb-83d9-8642554e2773” Type=“500” IDType=“3” User=“” UserS ID=“”/><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 数据库中的视图来查找有关 State System 执行的所有汇总任务的信息。 状态系统按配置的计划运行这些任务，并记录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控制台 >Software Library>Software 汇报中手动启动，然后单击“运行摘要”。 还可以通过选择“ 计划摘要”来更改默认计划。
SUM Migrate 更新状态
在数据库中内部迁移更新状态。 默认情况下，此任务每 24 小时运行一次。 无法从 Configuration Manager 控制台手动启动它。
SUM 删除过期状态
从数据库中的软件更新特定表中删除过期状态。 默认情况下，此任务每 24 小时运行一次。 无法从 Configuration Manager 控制台手动启动它。
软件更新点切换
在 System Center 2012 Configuration Manager SP1 及更高版本中，一个站点可以有多个 SUP。 这为 SUP 不可用的情况提供了容错能力。 有关 SUP 故障转移和切换的详细信息，请参阅以下文章：
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈