通过

排查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 站点、域、物理位置、站点、站点系统。

了解和理解这些问题的答案将使你能够快速轻松地解决遇到的任何问题。

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

客户端软件更新扫描

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

步骤 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. 位置服务创建位置请求并将其发送到管理点。 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 消息接收响应并将其发送回定位服务。 在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. 位置服务分析响应并将位置发送回扫描代理。 在 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 服务器后，扫描代理会从使用 Windows 更新 代理 API 的 WUAHandler 请求从 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) 的请求后开始扫描。 如果通过本地策略将这些注册表值正确设置为 WSUS 计算机，该计算机是站点的有效 SUP，则应会看到来自 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 WSUS 计算机上的 和 SimpleAuthWebService 虚拟目录通信才能执行扫描。 如果客户端无法与 WSUS 计算机通信，扫描将失败。 出现此问题的原因有很多，包括：

  • 代理相关问题

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

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

  • 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> 和策略已启用

      客户端安装和软件更新的软件更新点必须是同一服务器。 并且必须在 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>

      若要检查客户端是否可以访问 ，SimpleAuthWebService请尝试访问与此 URL 类似的 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) Manager。
        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 日志，以确认从 WSUS 返回 HTTP 错误。 如果 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 更新常见错误和缓解措施。

WSUS 到 Microsoft 更新同步

以下步骤概述了 WSUS 与 Microsoft 更新同步。 确认每个步骤，以正确确定问题所在。

步骤 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 Update (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 更新以及任何订阅的元数据接收产品和分类信息

WSUS 从 Microsoft 更新接收产品和分类信息以及任何订阅的元数据后，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. 检查同一更新是否无法在本地系统上下文下手动安装。 为此，请使用在软件更新部署期间失败的相同安装开关。

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

取代问题

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

  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支持论坛中的安全性、更新和合规性问题。

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