排查 Configuration Manager 中的软件更新管理问题

本文可帮助你排查 Configuration Manager 中的软件更新管理过程问题。 它包括客户端软件更新扫描、同步问题和特定更新的检测问题。

原始产品版本： Configuration Manager（Current Branch）、System Center 2012 R2 Configuration Manager、System Center 2012 Configuration Manager
原始 KB 数： 4505440

确定问题的范围

本指南假定已安装并配置了软件更新点。 有关在 Configuration Manager 中配置软件更新的详细信息，请参阅 准备软件更新管理。

在开始进行故障排除之前，请务必强调，越能更好地了解所遇到的问题、更快、更轻松的修复问题。 无论你是负责解决你遇到的问题，还是由组织中的某人报告的问题，请花点时间回答以下问题：

1. 你的目标是什么特别不起作用和/或目标是什么？
2. 问题的频率或模式是什么？ 问题是否仍在发生？
3. 你是如何意识到问题是否存在的？
4. 它曾经工作过吗？ 如果是这样，它什么时候停止了？ 在停止工作之前环境中有什么变化吗？
5. 受影响的客户端百分比是什么？
6. 已经做了什么（如果有的话）试图修复它？
7. 了解客户端的确切版本和服务器的版本。 这些系统是否是最新的？
8. 受影响的客户端有哪些共同之处？ 例如，同一子网、AD 站点、域、物理位置、站点、站点系统。

了解和理解这些问题的解答将使你成为快速轻松地解决所遇到的问题的最佳途径。

如果知道要进行故障排除的软件更新管理过程中的特定区域，请在下面选择它。 从客户端软件更新扫描开始（如果不确定），我们将从头到尾逐步完成整个过程。

• 客户端软件更新扫描
• 用于Microsoft更新同步的 WSUS
• 特定更新的安装、取代或检测问题

客户端软件更新扫描

以下步骤概述了客户端扫描过程。 确认每个步骤以正确确定问题所在位置。

步骤 1：客户端向管理点发送 WSUS 位置请求

客户端做的第一件事是设置 WSUS 服务器，该服务器将成为软件更新扫描的更新源。 此过程如下所述。

1. 当 Configuration Manager 客户端需要处理软件更新扫描时，扫描代理会根据可用策略创建扫描请求，如ScanAgent.log所述：

   CScanAgent::ScanByUpdates- Policy available for UpdateSourceID={SourceID}  
   ContentVersion=38  
   CScanAgent::ScanByUpdates- Added Policy to final ScanRequest List UpdateSourceID={SourceID}, Policy-ContentVersion=38, Required-ContentVersion=38
   

2. 扫描代理现在将 WSUS 位置请求发送到位置服务，如ScanAgent.log所述：

   Inside CScanAgent::ProcessScanRequest()  
   CScanJobManager::Scan- entered  
   ScanJob({JobID}): CScanJob::Initialize- entered  
   ScanJob({JobID}): CScanJob::Scan- entered  
   ScanJob({JobID}): CScanJob::RequestLocations- entered  
   - - - - - -Requesting WSUS Server Locations from LS for {WSUSLocationID} version 38  
   - - - - - -Location Request ID = {LocationRequestID}  
   CScanAgentCache::PersistInstanceInCache- Persisted Instance CCM_ScanJobInstance  
   ScanJob({JobID}): - - - - - -Locations requested for ScanJobID={JobID} (LocationRequestID={LocationRequestID}), will process the scan request once locations are available.
   

   提示

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

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

3. Location Services 创建位置请求并将其发送到管理点。 WSUS 位置请求的包 ID 是更新源唯一 ID。 在LocationServices.log：

   CCCMWSUSLocation::GetLocationsAsyncEx  
   Attempting to persist WSUS location request for ContentID='{ContentID}' and ContentVersion='38'  
   Persisted WSUS location request LocationServices  
   Attempting to send WSUS Location Request for ContentID='{ContentID}'
   WSUSLocationRequest : <WSUSLocationRequest SchemaVersion="1.00"><Content ID="{ContentID}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest>  
   Created and Sent Location Request '{LocationRequestID}' for package {ContentID}
   

4. CCM 消息传送将位置请求消息发送到管理点。 在CcmMessaging.log：

   Sending async message '{Message}' to outgoing queue 'mp:[http]mp_locationmanager'  
   Sending outgoing message '{Message}'. Flags 0x200, sender account empty
   

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

   MP LM: Message Body : \<WSUSLocationRequest SchemaVersion="1.00"><Content ID="{ContentID}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2PS1"/><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: calling MP_GetWSUSServerLocations
   

   在 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'{WSUSServerLocationsID}',N'38',N'PS1',N'PS1',N'0',N'CONTOSO.COM'
   

6. 从存储过程获取结果后，管理点会向客户端发送响应。 在MP_Location.log中：

   MP LM: Reply message body: <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>
   

7. CCM 消息传送接收响应并将其发送回 Location Services。 在CcmMessaging.log：

   Message '{Message1}' got reply '{Message2}' to local endpoint queue 'LS_ReplyLocations'  
   OutgoingMessage(Queue='mp_[http]mp_locationmanager', ID={*Message1*}):  
   Delivered successfully to host 'PS1SYS.CONTOSO.COM'.  
   Message '{Message2}' delivered to endpoint 'LS_ReplyLocations'
   

8. Location Services 分析响应并将位置发送回扫描代理。 在LocationServices.log：

   Processing Location reply message LocationServices  
   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>  
   Calling back with the following WSUS locations  
   WSUS Path='http://PS1SITE.CONTOSO.COM:8530', Server='PS1SITE.CONTOSO.COM', Version='38'  
   WSUS Path='https://PS1SYS.CONTOSO.COM:8531', Server='PS1SYS.CONTOSO.COM', Version='38'  
   Calling back with locations for WSUS request {WSUSLocationID}
   

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

   *****WSUSLocationUpdate received for location request guid={LocationGUID}  
   ScanJob({JobID}): CScanJob::OnLocationUpdate- Received  
   Location=<http://PS1SITE.CONTOSO.COM:8530>, Version=38  
   ScanJob({JobID}): CScanJob::Execute- Adding UpdateSource={SourceID}, ContentType=2, ContentLocation=<http://PS1SITE.CONTOSO.COM:8530>, ContentVersion=38
   

10. 扫描代理通知 WUAHandler 添加更新源。 WUAHandler 将更新源添加到注册表。 如果客户端位于域中，则它会启动组策略刷新，以查看组策略是否覆盖已添加的更新服务器。 WUAHandler.log中记录以下条目，其中显示了正在添加新的更新源：

    Its a WSUS Update Source type ({WSUSUpdateSource}), adding it  
    Its a completely new WSUS Update Source  
    Enabling WUA Managed server policy to use server: <http://PS1SITE.CONTOSO.COM:8530>
    Policy refresh forced  
    Waiting for 2 mins for Group Policy to notify of WUA policy change  
    Waiting for 30 secs for policy to take effect on WU Agent.  
    Added Update Source ({UpdateSource}) of content type: 2
    

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

    * WSUS server: <http://PS1SITE.CONTOSO.COM:8530> (Changed)  
    * WSUS status server: <http://PS1SITE.CONTOSO.COM:8530> (Changed)  
    Sus server changed through policy.
    

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

    注册表子项	值名称	类型	数据
    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表示内容版本递增时：

    Its a WSUS Update Source type ({WSUSUpdateSource}), adding it.  
    WSUS update source already exists, it has increased version to 38.
    

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

    ScanJob({JobID}): Raised UpdateSource ({UpdateSource}) state message successfully. StateId = 2  
    ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1
    

排查步骤 1 中的问题

问题	检查内容
ScanAgent.log显示没有可用于更新源的策略，并且WUAHandler.log中不存在或不存在任何当前活动WUAHandler.log	检查客户端 设置上的 “启用软件更新”。
扫描代理或位置服务未收到 WSUS 服务器位置	是否为站点安装了软件更新点 （SUP） 角色？ 如果没有，请安装和配置软件更新点并监视SUPSetup.log进度。 有关详细信息，请参阅 安装和配置软件更新点。 如果安装了 SUP 角色，是否配置并同步？ 检查WCM.log、WSUSCtrl.log和WSyncMgr.log是否存在错误。 select * from WSUSServerLocations select * from Update_SyncStatus
客户端接收 WSUS 位置，但无法配置 WSUS 注册表项	组策略刷新是否在每个WUAHandler.log的 2 分钟超时内做出响应？ 如果是这样，WUAHandler 是否表示 组策略设置被更高权限（域控制器）覆盖？ 有关详细信息，请参阅 组策略替代正确的 WSUS 配置信息。

有关软件更新扫描失败故障排除的详细信息，请参阅 软件更新扫描失败疑难解答。

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

在客户端识别并设置将成为软件更新扫描更新源的 WSUS 服务器后，扫描代理会从 WUAHandler 请求扫描，该扫描使用 Windows 更新 代理 API 从 Windows 更新 代理请求软件更新扫描。 扫描可能来自：

• 计划或手动软件更新扫描
• 计划或手动软件更新部署重新评估
• 变为活动的部署

扫描会触发评估。 在ScanAgent.log：

ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1

仅当被 Service Pack 和定义更新取代时，扫描结果才会包括被取代的更新。 在WUAHandler.log中：

Search Criteria is (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')  
Running single-call scan of updates.  
Async searching of updates using WUAgent started.

提示

在软件更新扫描后查看WUAHandler.log，查看是否存在任何新条目。 如果未出现新条目，则表示管理点未返回 SUP。

排查步骤 2 中的问题

软件更新扫描的许多问题可能由以下原因之一引起：

• 文件或注册表项缺失或损坏。
• 组件注册问题。

若要修复此类问题，请参阅 由于缺少或损坏组件而导致的扫描失败。

有一个已知问题，即请求更新扫描的 32 位 Windows 7 ConfigMgr 2012 R2 客户端无法将扫描结果返回到 Configuration Manager。 这会导致客户端报告不正确的符合性状态，当 Configuration Manager 请求更新周期时，更新无法安装。 但是，如果使用Windows 更新控制面板小程序，更新通常会安装正常。 遇到此问题时，会收到类似于WindowsUpdate.log中的消息：

WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E

这是内存分配问题，64 位 Windows 7 计算机不会看到此错误，因为它们的地址空间实际上不受限制。 但是，它们会显示高内存和高 CPU 使用率，可能会影响性能。 X86 客户端还会表现出较高的内存使用率（通常约为 1.2 GB 到 1.4 GB）。

若要解决此问题，请为 Windows 7 应用Windows 更新客户端：2015 年 6 月。

排查扫描失败问题时，请检查WUAHandler.log和WindowsUpdate.log文件。 WUAHandler 只是报告了代理Windows 更新报告的内容。 因此，WUAHandler 中的错误与 Windows 更新 代理本身报告的相同错误。 有关错误的详细信息，请参阅WindowsUpdate.log。 若要了解如何读取WindowsUpdate.log，请参阅Windows 更新日志文件。

最佳信息来源来自日志及其包含的错误代码。 有关错误代码的详细信息，请参阅Windows 更新常见错误和缓解措施。

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

Windows 更新代理从 Configuration Manager 客户端（CcmExec）收到请求后启动扫描。 如果这些注册表值正确设置为通过本地策略为站点的有效 SUP 的 WSUS 计算机，则应看到来自 Configuration Manager 客户端的 COM API 搜索请求（ClientId = CcmExec）。 在WindowsUpdate.log中：

COMAPI -- START -- COMAPI: Search [ClientId = CcmExec]  
COMAPI <<-- SUBMITTED -- COMAPI: Search [ClientId = CcmExec] PT + ServiceId = {ServiceID}, Server URL = <http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx>  
Agent ** START ** Agent: Finding updates [CallerId = CcmExec]  
Agent * Include potentially superseded updates  
Agent * Online = Yes; Ignore download priority = Yes  
Agent * Criteria = "(DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')"  
Agent * ServiceID = {ServiceID} Managed  
Agent * Search Scope = {Machine}

PT + ServiceId = {ServiceID}, Server URL = <http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx>  
Agent * Added update {4AE85C00-0EAA-4BE0-B81B-DBD7053D5FAE}.104 to search result  
Agent * Added update {57260DFE-227C-45E3-9FFC-2FC77A67F95A}.104 to search result  
Agent * Found 163 updates and 70 categories in search; evaluated appl. rules of 622 out of 1150 deployed entities  
Agent ** END ** Agent: Finding updates [CallerId = CcmExec]  
COMAPI >>-- RESUMED -- COMAPI: Search [ClientId = CcmExec]  
COMAPI - Updates found = 163  
COMAPI -- END -- COMAPI: Search [ClientId = CcmExec]

排查步骤 3 中的问题

在扫描期间，Windows 更新代理需要与 ClientWebService SimpleAuthWebService WSUS 计算机上的虚拟目录通信才能执行扫描。 如果客户端无法与 WSUS 计算机通信，扫描将失败。 此问题可能由于多种原因而发生，包括：

• 代理相关问题

  若要解决这些问题，请参阅 代理相关问题导致的扫描失败。

  有关代理服务器的详细信息，请参阅以下文章：

  • Windows 更新客户端如何确定用于连接到Windows 更新网站的代理服务器
  • 对 Web 代理和防火墙客户端自动发现的 DNS 和 DHCP 支持

• HTTP 超时错误

  若要排查 HTTP 超时错误，请先查看 WSUS 计算机上的 Internet Information Services （IIS）日志，以确认这些错误实际上是从 WSUS 返回的。 如果 WSUS 计算机未返回错误，则可能是中间防火墙或代理出现问题。

  如果 WSUS 计算机返回错误，请验证与 WSUS 计算机的连接。 步骤如下：

  1. 若要确认客户端连接到正确的 WSUS 服务器，请查找 Windows 更新 代理客户端使用的 WSUS 计算机的 URL。 可以通过检查 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate 注册表子项或查看WindowsUpdate.log文件来找到此 URL。

     WSUS 分配可能不正确的常见原因包括：

     • 组策略冲突
     • 初始客户端安装后将 SUP 添加到辅助站点

     注意

     Active Directory 组策略可能会替代本地 WSUS 策略。

     软件更新功能会自动为 Configuration Manager 客户端配置本地组策略设置，以便使用软件更新点源位置和端口号对其进行配置。 客户端需要服务器名称和端口号才能查找软件更新点。

     如果将 Active Directory 组策略设置应用于计算机进行软件更新点客户端安装，则会替代本地组策略设置。 如果 Active Directory 组策略中定义的设置值与 Configuration Manager 设置的值不同，则扫描将在客户端上失败，因为它找不到正确的 WSUS 计算机。 在这种情况下，WUAHandler.log将显示以下消息：

     组策略设置被更高权限（域控制器）覆盖，以：服务器 <http://server> 和策略 ENABLED

     客户端安装和软件更新的软件更新点必须是相同的服务器。 必须使用正确的名称格式和端口信息在 Active Directory 组策略设置中指定它。 例如， <http://server1.contoso.com:80> 如果软件更新点使用默认网站，

  2. 如果服务器 URL 正确，请使用类似于以下 URL 的服务器访问服务器，以验证客户端与 WSUS 计算机之间的连接：

     <http://SUPSERVER.CONTOSO.COM:8530/Selfupdate/wuident.cab>

     若要检查客户端是否可以访问 ClientWebService 虚拟目录，请尝试访问类似于以下 URL 的 URL：

     <http://SUPSERVER.CONTOSO.COM:8530/ClientWebService/wusserverversion.xml>

     若要检查客户端是否可以访问该 SimpleAuthWebServiceURL，请尝试访问类似于下面的 URL：

     <http://SUPSERVER.CONTOSO.COM:8530/SimpleAuthWebService/SimpleAuth.asmx>

     如果其中任一 URL 失败，一些可能的原因包括：

     • 客户端上的名称解析问题。 验证是否可以解析 WSUS 计算机的 FQDN。

     • 代理配置问题。

     • 其他与网络相关的连接问题。

     • 端口配置问题，因此最好验证端口设置是否正确。 WSUS 可配置为使用以下任一端口：80、443 或 8530、8531。

       若要使客户端与 WSUS 计算机通信，必须在 WSUS 计算机上的防火墙上允许相应的端口。 在创建软件更新点站点系统角色时配置端口设置。 这些端口设置必须与 WSUS 网站使用的端口设置相同。 否则，WSUS 同步管理器将无法连接到在软件更新点上运行的 WSUS 以请求同步。 以下过程提供有关如何验证 WSUS 和软件更新点使用的端口设置的信息。

       1. 确定 IIS 7.0 及更高版本中使用的 WSUS 端口设置。

       2. 确定 IIS 6.0 中的 WSUS 端口设置。

       3. 配置软件更新点的端口。

       4. 验证端口连接

          若要检查客户端的端口连接，请运行以下命令：

          telnet SUPSERVER.CONTOSO.COM <portnumber>
          

          例如，如果端口为 8530，请运行以下命令：

          telnet SUPSERVER.CONTOSO.COM 8530
          

          如果端口无法访问，telnet 将返回类似于以下端口的错误：

          端口 PortNumber <上无法打开与主机的连接>

          此错误表明防火墙规则未配置为允许 WSUS 计算机的通信。 此错误还表明中间网络设备正在阻止该端口。 若要验证，请从同一本地子网上的客户端尝试相同的测试。 如果正常工作，则计算机已正确配置。 但是，段之间的路由器或防火墙会阻止端口并导致故障。

     • IIS 可用性问题。

       1. 在 WSUS 计算机上，打开 Internet Information Services （IIS） 管理器。
       2. 展开 “站点”，右键单击 WSUS 计算机的网站，然后单击“ 编辑绑定”。
       3. 在 “站点绑定 ”对话框中，HTTP 和 HTTPS 端口值显示在 “端口 ”列中。
       4. 在 WSUS 服务器上，打开 Internet Information Services （IIS） 管理器。
       5. 展开 “网站”，右键单击 WSUS 计算机的网站，然后单击“ 属性”。
       6. 单击“网站”选项卡。HTTP 端口设置显示在 TCP 端口中，HTTPS 端口设置显示在 SSL 端口中。
       7. 在 Configuration Manager 控制台中，转到“管理>站点配置>服务器”和“站点系统角色”，然后单击“<SiteSystemName>”右侧窗格。
       8. 在底部窗格中，右键单击“ 软件更新点 ”，然后单击“ 属性”。
       9. 转到 “常规 ”选项卡，指定或验证 WSUS 配置端口号。

• 身份验证错误

  扫描失败时，通常会指示扫描失败并出现身份验证错误0x80244017（HTTP 状态 401）或0x80244018（HTTP 状态 403）。

  首先，使用以下命令确认正确的 WinHTTP 代理设置：

  • 在 Windows Vista 或更高版本上： netsh winhttp show proxy
  • 在 Windows XP 上： proxycfg.exe

  如果代理设置正确，请通过完成 HTTP 超时错误中的步骤来验证与 WSUS 计算机的连接。 另请查看 WSUS 计算机上的 IIS 日志，确认 HTTP 错误是从 WSUS 返回的。 如果 WSUS 计算机未返回错误，则可能是中间防火墙或代理出现问题。

• 证书问题

  证书问题由错误代码0x80072F0C指示，这意味着“需要证书才能完成客户端身份验证”。 若要解决此问题，请参阅 扫描失败并出现错误0x80072f0c。

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

WUAHandler.log中记录以下内容：

Async searching completed.  
Finished searching for everything in single call.

排查步骤 4 中的问题

此处的问题应与步骤 3 中的扫描失败相同。

如本指南前面所述，排查扫描失败时，请检查WUAHandler.log和WindowsUpdate.log文件。 WUAHandler 只是报告了代理Windows 更新报告的内容。 因此，WUAHandler 中的错误与Windows 更新代理本身报告的错误相同。 有关此错误的详细信息，请参阅WindowsUpdate.log。 若要了解如何读取WindowsUpdate.log，请参阅Windows 更新日志文件。

软件更新扫描可能失败的原因有很多。 这可能是由前面提到的问题之一或客户端与软件更新点计算机之间的通信或防火墙问题引起的。 最佳信息来源来自日志及其包含的错误代码。 有关错误代码的详细信息，请参阅Windows 更新常见错误和缓解措施。

步骤 5：WUAHandler 分析扫描结果

然后，WUAHandler 分析结果，其中包括每个更新的适用性状态。 在此过程中，取代的更新将被淘汰。检查适用性状态，了解符合 CCMExec 提交到 Windows 更新 代理的条件的所有更新。 此处要了解的重要事项是，无论这些更新是否在部署中，都应看到更新的适用性结果。

WUAHandler.log中记录以下条目：

> Pruning: update id (70f4f236-0248-4e84-b472-292913576fa1) is superseded by (726b7201-862a-4fde-9b12-f36b38323a6f).  
> ...  
> Update (Installed): Security Update for Windows 7 for x64-based Systems (KB2584146) (4ae85c00-0eaa-4be0-b81b-dbd7053d5fae, 104)  
> Update (Missing): Security Update for Windows 7 for x64-based Systems (KB2862152) (505fda07-b4f3-45fb-83d9-8642554e2773, 200)  
> ...  
> Successfully completed scan.

排查步骤 5 中的问题

问题可以像步骤 3 中的扫描失败一样解决。

如本指南前面所述，排查扫描失败时，请检查WUAHandler.log和WindowsUpdate.log文件。 WUAHandler 只是报告了代理Windows 更新报告的内容。 因此，WUAHandler 中的错误与Windows 更新代理本身报告的错误相同。 有关此错误的详细信息，请参阅WindowsUpdate.log。 若要了解如何读取WindowsUpdate.log，请参阅Windows 更新日志文件。

一般来说，软件更新扫描可能失败的原因有很多。 这可能是由前面提到的问题之一或客户端与软件更新点计算机之间的通信或防火墙问题引起的。 最佳信息来源来自日志及其包含的错误代码。 作为参考，请参阅Windows 更新常见错误和缓解措施。

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

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

• 以前的状态消息从未为更新发送（日志条目： 以前未报告过，创建新实例）。
• 自上次提交状态消息以来，更新的适用性状态已更改。

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

Processing update status from update (505fda07-b4f3-45fb-83d9-8642554e2773) with ProductID = 0fa1201d-4330-4fa8-8ae9b877473b6441  
Update status from update (505fda07-b4f3-45fb-83d9-8642554e2773) hasn't been reported before, creating new instance.  
Successfully raised state message for update (505fda07-b4f3-45fb-83d9-8642554e2773) with state (Missing).  
Successfully added WMI instance of update status (505fda07-b4f3-45fb-83d9-8642554e2773).

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

Adding message with TopicType 500 and TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 to WMI  
State message(State ID : 2) with TopicType 500 and TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 has been recorded for SYSTEM

提示

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

排查步骤 6 中的问题

此处的问题应与步骤 3 中的扫描失败相同。

如本指南前面所述，排查扫描失败时，请检查WUAHandler.log和WindowsUpdate.log文件。 WUAHandler 只是报告了代理Windows 更新报告的内容。 因此，WUAHandler 中的错误与Windows 更新代理本身报告的错误相同。 有关此错误的详细信息，请参阅WindowsUpdate.log。 若要了解如何读取WindowsUpdate.log，请参阅Windows 更新日志文件。

一般来说，软件更新扫描可能失败的原因有很多。 这可能是由前面提到的问题之一或客户端与软件更新点计算机之间的通信或防火墙问题引起的。 最佳信息来源来自日志及其包含的错误代码。 作为参考，请参阅Windows 更新常见错误和缓解措施。

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

当 WUAHandler 成功收到来自Windows 更新代理的结果时，它会将扫描标记为已完成，并在WUAHandler.log中记录以下消息：

Async searching completed. WUAHandler  
Finished searching for everything in single call

排查步骤 7 中的问题

此处的问题应与步骤 3 中的扫描失败相同，尽管此阶段的故障可能会具体显示在WindowsUpdate.log文件中。 若要了解如何读取WindowsUpdate.log，请参阅Windows 更新日志文件。

一般来说，软件更新扫描可能失败的原因有很多。 这可能是由前面提到的问题之一或客户端与软件更新点计算机之间的通信或防火墙问题引起的。 最佳信息来源来自日志及其包含的错误代码。 作为参考，请参阅Windows 更新常见错误和缓解措施。

用于Microsoft更新同步的 WSUS

以下步骤概述了与 Microsoft Update 同步的 WSUS。 确认每个步骤以正确确定问题所在位置。

步骤 1：同步从计划请求或手动请求开始

触发同步时，我们希望在 WSUS 服务器的SoftwareDistribution.log中看到以下消息：

对于手动同步：

Changew3wp.6AdminDataAccess.StartSubscriptionManuallySynchronization manually started  
Info WsusService.27EventLogEventReporter.ReportEvent  
EventId=382,Type=Information,Category=Synchronization,Message=A manual synchronization was started.

对于计划的同步：

InfoWsusService.10EventLogEventReporter.ReportEvent  
EventId=381,Type=Information,Category=Synchronization,Message=A scheduled synchronization was started.

排查步骤 1 中的手动同步问题

1. 确认 WSUS 服务正在运行。 如果手动同步已启动，但保持为 0%，这是因为 WSUS 服务（WSUS 3.x 上的更新服务 ）; Windows Server 2012 及更高版本的 WSUSService 处于停止状态。

2. 按照以下步骤重置 WSUS 控制台 MMC 缓存：

   1. 关闭 WSUS 控制台。
   2. 停止 WSUS 服务（更新 WSUS 3.x 上的服务 ; Windows Server 2012 及更高版本的 WSUS 服务 ）。
   3. 浏览到 %appdata%\Microsoft\mmc 。
   4. 将 wsus 重命名为 wsus_bak。
   5. 启动 WSUS 服务。
   6. 打开 WSUS 控制台并尝试另一个手动同步。

排查步骤 1 中的计划同步问题

1. 尝试从 WSUS 控制台手动同步。
2. 如果手动同步正常工作，请检查计划的同步设置。

步骤 2：WSUS 生成与Microsoft更新的连接（MU）

同步启动后，WSUS 服务器会尝试通过 WinHTTP 建立 HTTP 连接。 排查连接问题时，请考虑以下因素：

WSUS <=winhttp=> 网络实体 <=> Internet

• WSUS 主机与 Internet 之间是否存在网络实体（代理、防火墙、安全筛选器等） ？
• 如果存在代理并且需要使用该代理的 WSUS 服务器，是否在正确的 WSUS 设置中配置代理？

排查步骤 2 中的手动同步问题

1. 确认 WSUS 服务正在运行。 如果手动同步已启动，但保持为 0%，这是因为 WSUS 服务（WSUS 3.x 上的更新服务 ）; Windows Server 2012 及更高版本的 WSUS 服务 处于停止状态。

2. 通过完成以下步骤重置 WSUS 控制台 MMC 缓存：

   1. 关闭 WSUS 控制台。
   2. 停止 WSUS 服务（更新 WSUS 3.x 上的服务 ; Windows Server 2012 及更高版本的 WSUS 服务 ）。
   3. 浏览到 %appdata%\Microsoft\mmc 。
   4. 将 wsus 重命名为 wsus_bak。
   5. 启动 WSUS 服务。
   6. 打开 WSUS 控制台并尝试另一个手动同步。

排查步骤 2 中的计划同步问题

1. 尝试从 WSUS 控制台手动同步。
2. 如果手动同步正常工作，请检查计划的同步设置。

步骤 3：WSUS 计算机从 Microsoft Update 和任何订阅的元数据接收产品和分类信息

WSUS 收到产品和分类信息以及来自 Microsoft Update 的任何订阅元数据后，WSUS 同步已完成。

特定更新的安装、取代或检测问题

特定更新发生的部署问题可能分为以下区域。 开始故障排除时，请考虑以下与这些区域关联的组件。

Areas	安装	取代	检测
组件	WUA 更新安装程序 （基于组件的服务 （CBS）， MSI） CCMExec	更新元数据	WUA 更新元数据 更新安装程序 （CBS， MSI）

安装问题

什么是安装程序（CBS、MSI 和其他） ？

CBS

对于适用于 Windows Vista 及更高版本的更新，CBS 用于处理安装。

1. 收集 CBS 日志（%Windir%\Logs\Cbs\Cbs.log）并执行初始评审，以便深入了解失败的原因。 通过 CBS 日志排查基于安装的问题超出了本指南的范围。 有关详细信息，请参阅 使用 DISM 或系统更新就绪性工具修复 Windows 损坏错误。
2. 更新是否成功作为已登录用户安装？ 如果是这样，它是否仅在系统上下文下安装时才失败？ 在这种情况下，请专注于在系统上下文中排查手动安装失败问题。

MSI （Windows Installer）

对于非 Windows 软件更新，MSI 用于处理安装。

1. 收集和查看更新的默认 MSI 日志。 有关任何已知问题或常见问题解答，请查看关联的知识库文章。

2. 启用 Windows Installer 日志记录 并重现失败。

   查看生成的日志时，请检查日志中的返回值 3，以及该条目前面的行，以便深入了解失败。

3. 检查同一更新是否无法在本地系统上下文下手动安装。 为此，请使用在软件更新部署过程中失败的相同安装开关。

   如果失败，请使用同一安装开关以登录用户的身份测试安装。 检查是否在本地系统下安装存在问题。 如果有效，则可以将问题集中在如何使用本地系统上下文正确安装更新上。 它可能需要检查知识库中的管理部署指南以获取更新或联机。

取代问题

尝试使用以下问题来隔离与取代相关的问题：

1. 有关如何控制 Configuration Manager 何时过期更新的问题，请参阅 取代规则。
2. 如果 Configuration Manager 已过期更新，Microsoft建议部署最新的取代更新。 如果仍需要部署过期的更新，可以通过软件分发或应用程序管理在软件更新部署外部部署这些更新。
3. 有关专门与更新取代逻辑相关的问题，请先查看有关更新的知识库文章以了解详细信息。 还可以查看Microsoft更新目录、WSUS 控制台或 Configuration Manager 控制台中的取代。

检测问题

确定客户端上的每个更新的符合性状态

1. 查看更新知识库文章，了解更新的已知问题。
2. 在 Configuration Manager 客户端上运行软件更新扫描周期 操作。
3. 查看UpdatesStore.log和WindowsUpdate.log。

排查更新适用性问题

1. 使用知识库文章检查更新是否缺少任何先决条件。 例如，更新是否需要将应用程序或 OS 修补到特定的 Service Pack 级别？
2. 确认有问题的更新的唯一更新 ID 与所部署的内容匹配。 例如，有问题的更新是 32 位更新，而是面向 64 位主机？

详细信息

有关如何在 Configuration Manager 中配置软件更新的详细信息，请参阅以下文章：

• 在 Configuration Manager 中规划软件更新
• 如何配置软件更新点以使用网络负载平衡 （NLB） 群集
• 如何为软件更新启用 CRL 检查

还可以在此的 Configuration Manager 支持论坛中发布问题，了解安全性、更新和合规性。

请访问 我们的博客 ，了解 Configuration Manager 上的所有最新新闻、信息和技术提示。