故障排除在配置管理器中的软件更新管理


家庭用户: 本文仅供技术支持工程师和 IT 专业人员。如果您正在寻找可帮助解决问题,请询问 Microsoft 社区

该指南是做什么用的?

本指南可帮助您解决软件更新管理过程在 Microsoft 系统中心配置管理器中,包括客户端软件更新扫描、 同步问题和特定更新的检测问题。

本指南中的信息适用于 System Center 2012 配置管理器 (ConfigMgr 2012 年),System Center 2012 R2 配置管理器 (ConfigMgr 2012 R2) 及其所有版本的配置管理器中的当前分支中。

适用对象是哪些人?

本指南适用于 IT 专业人员需要理解、 诊断和解决问题的软件更新管理过程在 Microsoft 系统中心配置管理器。

它是如何工作?它分为三个主要部分:

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

本指南假定软件更新点,已安装和配置。在配置管理器中配置的软件更新的详细信息,请参阅以下资源:

在配置管理器中配置的软件更新

预计完成时间:

30-45 分钟。

进入实际的故障排除步骤之前, 是一定要强调,虽然它看起来很明显,更好地了解的问题您所经历的更快和更容易将为您修复它。无论您负责解决问题,遇到了自己或由您的组织中的某个人向您报告的问题,建议您花些时间,并回答以下问题:

  1. 特别不能正常工作和/或您的目标是什么?
  2. 针对问题的模式的频率是什么? 该问题仍然发生了吗?
  3. 您如何做意识到存在问题?
  4. 这曾经过吗? 如果是这样,当未它停止? 任何已在适当环境中之前就停止了工作?
  5. 客户端的百分之多少会受到影响?
  6. 内容已完成已经 (如果有的话),尝试修复它?
  7. 知道的确切版本的客户端和服务器的版本。这些系统是最新的?
  8. 哪些不影响客户端的共同点 (如相同的子网、 AD 站点、 域、 物理位置、 站点、 站点系统等)?

知道和了解这些问题的答案将使您快速而轻松地解析的最佳路径上您遇到任何问题。

如果您知道您想要解决问题的软件更新管理过程中的特定区域,请在下面选择。如果不确定,请与客户端软件更新扫描开始,我们将引导您完成整个过程从头到尾。

进入实际的故障排除步骤之前, 是一定要强调,虽然它看起来很明显,更好地了解的问题您所经历的更快和更容易将为您修复它。无论您负责解决问题,遇到了自己或由您的组织中的某个人向您报告的问题,建议您花些时间,并回答以下问题:

  1. 特别不能正常工作和/或您的目标是什么?
  2. 针对问题的模式的频率是什么? 该问题仍然发生了吗?
  3. 您如何做意识到存在问题?
  4. 这曾经过吗? 如果是这样,当未它停止? 任何已在适当环境中之前就停止了工作?
  5. 客户端的百分之多少会受到影响?
  6. 内容已完成已经 (如果有的话),尝试修复它?
  7. 知道的确切版本的客户端和服务器的版本。这些系统是最新的?
  8. 哪些不影响客户端的共同点 (如相同的子网、 AD 站点、 域、 物理位置、 站点、 站点系统等)?

知道和了解这些问题的答案将使您快速而轻松地解析的最佳路径上您遇到任何问题。

如果您知道您想要解决问题的软件更新管理过程中的特定区域,请在下面选择。如果不确定,请与客户端软件更新扫描开始,我们将引导您完成整个过程从头到尾。

以下步骤概述了客户端扫描进程。 确认每个步骤以正确地建立问题的位置。

客户进行的第一件事是设置将更新源软件更新扫描的 WSUS 服务器。下面详细说明了该过程。

ScanAgent.log:

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

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 类中:

Namespace: root\CCM\ScanAgent 类: CCM_ScanJobInstance

LocationServices.log:

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}   

CcmMessaging.log:

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

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 事件探查器:

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'  

 

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>  

 

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'  

 

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}  

 

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  

 

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 changeWaiting 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\AUUseWUServer (应该是 Dword 值 1)
  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate WUServer (这应该是一个字符串值,是完整的 WSUS 服务器 URL 包括端口)
  • WUStatusServer (这应该是一个字符串值,是完整的 WSUS 服务器 URL 包括端口)

 

例如:

关键名称: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate

值名称: WUServer

类型: REG_SZ

数据: http://PS1Site.Contoso.com:8530

 

值名称: WUStatusServer

类型: REG_SZ

数据: 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.  

 

ScanAgent.log:

ScanJob({JobID}): Raised UpdateSource ({UpdateSource}) state message successfully. StateId = 2 ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1
  1. 当配置管理器客户端需要处理软件更新扫描时,扫描代理将创建基于可用的策略,在此处所述扫描请求:
  2. 扫描代理现在发送位置服务请求 WSUS 位置此处所述:
  3. 位置服务创建位置请求,并将其发送到管理点。WSUS 位置请求包 ID 是更新源唯一的 id。
  4. CCM 消息发送到管理点的位置请求消息:
  5. 管理点分析此请求,并调用 MP_GetWSUSServerLocations 存储过程从数据库中获取 WSUS 位置:
  6. 从存储过程中获得的结果后, 管理点将响应发送到客户端:
  7. CCM 消息接收响应,并将其发送回服务位置:
  8. 位置服务分析响应并发送回扫描代理程序的位置:
  9. 扫描代理现在拥有的策略和内容的适当版本的更新源位置。
  10. 扫描代理通知 WUAHandler 添加更新源。WUAHandler 将更新源添加到注册表并启动组策略刷新 (如果在域中的客户端) 若要查看组策略是否重写我们刚刚添加了更新服务器。
  11. 已成功添加 updatesource 后,扫描代理引发状态消息和 initiatesthe 扫描:

疑难解答

日志的症状 要检查
ScanAgent.log 显示没有可用更新源并没有 WUAHandler.log 存在的策略或 WUAHandler.log 中的任何当前活动 请检查设置的客户端上启用软件更新。有关详细信息,请参阅以下 TechNet 文档: 关于客户端设置配置管理器中
ScanAgent/LocationServices 接收没有 WSUS 服务器位置 为该站点安装软件更新点 (SUP) 角色?如果不是,安装和配置软件更新点和进度监控 SUPSetup.log。请参阅下面的详细信息: 安装和配置软件更新点 如果已安装 SUP 角色,是其配置和同步?检查错误的WCM.logWSUSCtrl.logWSyncMgr.log选择 * 从 WSUSServerLocations 选择 * 从 Update_SyncStatus
客户端接收的 WSUS 位置,但无法配置 WSUS 的注册表项 WUAHandler.log每 2 分钟的超时时间内响应的组策略刷新?如果是这样,没有 WUAHandler 表示"组策略设置被覆盖由更高机构 (域控制器)"?检查域中设置的 GPO。

 

 

 

一旦客户端识别出并设置 WSUS 服务器将更新源的软件更新扫描,扫描代理然后从 WUAHandler,它使用 Windows 更新代理 API 来请求软件更新扫描 Windows 更新代理请求扫描。扫描可能会导致从预定或手动软件更新扫描、 预定或手动更新的软件部署重新评估,或将变为活动状态触发评估部署。

ScanAgent.log:

 

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

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 管理点返回。

疑难解答

丢失或损坏的文件或注册表项,或者通过组件注册问题,可能导致大量的问题与软件更新扫描。这些是通过 Windows 更新疑难解答,更新 Windows 更新代理或重置 Windows 更新代理数据存储区可修复:

Windows 更新疑难解答:

2714434-的 Windows 更新疑难解答 (http://support.microsoft.com/kb/2714434) 的说明

正在更新 Windows 更新代理:

949104-如何 Windows 更新代理更新到最新版本 (http://support.microsoft.com/kb/949104)

如果客户端正在运行较早版本的 Windows 更新代理,请注意,没有一个已知的问题 32 位 Windows 7 ConfigMgr 2012 R2 客户端请求更新扫描无法返回到配置管理器中的扫描结果。这将导致报告不正确的法规遵从性状态的客户端,安装后配置管理器请求更新周期更新失败。但是,如果您使用 Windows 更新控制面板小程序,这些更新将通常安装很正常。如果您遇到此问题,您应该注意到在WindowsUpdate.log以下类似的消息:

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

这是一个内存分配问题的核心,因此 64 位 Windows 7 的计算机将不会看到此错误因为其地址空间实际上不受限制。他们会但是,会表现出较高的内存和 CPU 使用率高,还可能会影响性能。注意该 x86 客户端同样会表现出较高的内存使用情况 (通常大约 1.2 到 1.4 gb)。

有关此问题的详细信息,请参阅以下文章:

支持提示: ConfigMgr 2012 更新扫描失败,会导致不正确的法规遵从性状态

幸运的是,这里对此问题的修补程序:

3050265-Windows 更新客户端的 Windows 7: 6 月 2015 (https://support.microsoft.com/en-us/kb/3050265)

重置 Windows 更新代理数据存储区:

要重置 Windows 更新代理数据存储区,请执行以下步骤:

  1. 通过在命令提示符下运行net stop 没有帮助的 wuauserv停止 Windows 更新服务。
  2. C:\Windows\SoftwareDistribution文件夹重命名为C:\Windows\SoftwareDistribution.old
  3. 通过在命令提示符下运行网络开始没有帮助的 wuauserv ,启动 Windows 更新服务。
  4. 启动一个软件更新扫描周期。

摘要

总之,在解决扫描失败时,您应该查看的日志是WUAHandler.logWindowsUpdate.log。由于 WUAHandler 仅报告 Windows 更新代理的报告,WUAHandler 中的错误将是同样 Windows 更新代理本身报告的错误,因此无法WindowsUpdate.log中找到有关该错误的详细信息。若要了解如何阅读WindowsUpdate.log,请参见下面的知识库文章:

902093-如何读取 Windowsupdate.log 文件 (https://support.microsoft.com/en-us/kb/902093)

您的信息的最佳来源将来自日志和它们所包含的错误代码。作为参考,您可以找到 Windows Update 错误代码的完整列表:

938205-Windows Update 错误代码列表 (http://support.microsoft.com/kb/938205)

 

一旦请求,Windows 更新代理程序 (WUA) 开始对其已配置的 WSUS 服务器进行扫描。

Windows 更新代理启动之后接收到的请求来自客户端配置管理器 (CcmExec) 的扫描。如果到 WSUS 计算机是通过本地策略网站有效 SUP 正确设置这些注册表值,则应该查看 COM API 搜索请求从配置管理器客户端 (客户机 Id = 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.asmxAgent ** 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}  

 

WindowsUpdate.log:

 

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] 

疑难解答

在扫描时,Windows 更新代理需要与 WSUS 计算机上的 ClientWebService 和 SimpleAuthWebService 的虚拟目录进行通信以便执行扫描。如果客户端无法与 WSUS 计算机进行通信,则扫描将会失败。这可能由于许多原因,包括

  • 代理相关的问题
  • HTTP 超时错误
  • 身份验证错误
  • 证书问题

我们将介绍其中的每个下面。

代理相关的问题

Windows 更新代理使用 WinHTTP 扫描可用的更新。当客户端和 WSUS 计算机之间的代理服务器时,代理设置必须允许它们与 WSUS 使用的 FQDN 进行通信的客户端上正确配置。对于代理问题, WindowsUpdate.log报告可能类似于以下内容的错误:

0x80244021 or HTTP Error 502 - Bad gateway0x8024401B or HTTP Error 407 - Proxy Authentication Required0x80240030 - The format of the proxy list was invalid0x8024402C - The proxy server or target server name cannot be resolved

大多数情况下,在 WSUS 计算机仍可能位于 intranet 内由于您可以跳过本地地址的代理服务器。但是,如果客户端是在 Internet 上,您必须确保代理服务器被配置为允许的通信。您可以运行下面的命令以查看 WinHTTP 代理设置:

  • 在 Windows XP 中: proxycfg.exe
  • 在 Windows Vista 上或以上: netsh winhttp 显示代理服务器

虽然在 Internet Explorer 中配置代理服务器设置的组成部分 WinINET 代理服务器设置,WinHTTP 代理设置并不一定与 Internet Explorer 中配置的代理服务器设置相同。但是,如果在 Internet Explorer 中正确设置的代理设置,您可以导入代理配置 IE 作为 WinHTTP 代理服务器设置。要从 Internet Explorer 导入代理服务器配置,请运行以下命令:

  • 在 Windows XP 中: proxycfg.exe u
  • 在 Windows Vista 上及以上: netsh winhttp 导入代理源 = ie

有关详细信息,请参阅以下:

900935-Windows 更新客户端如何确定哪个代理服务器用来连接到 Windows Update 网站

934864-Microsoft DNS 和 WINS 使用 WPAD 注册

DNS 和 DHCP 支持 Web 代理和防火墙客户端自动搜索: https://technet.microsoft.com/en-us/library/cc302584.aspx

HTTP 超时错误

要解决 HTTP 超时错误,请首先复查确认实际上正在从 WSUS 返回错误的 WSUS 计算机上的 IIS 日志。如果 WSUS 计算机没有返回错误,则可能与中间防火墙或代理问题。

如果 WSUS 计算机将返回错误,请验证与 WSUS 计算机建立连接。步骤如下:

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

WSUS 分配可能是不正确的常见原因包括组策略冲突或初始客户端安装后的添加到辅助站点 SUP。

注意:活动目录组策略可能会重写本地 WSUS 策略

软件更新功能自动配置本地组策略设置为配置管理器客户端以便获配的软件更新点源位置和端口号。服务器名称和端口号所需的客户端软件更新点。

如果Active Directory组策略设置应用到计算机的软件更新点客户端安装,这将覆盖本地组策略设置。因此,如果 AD 组策略中定义的设置的值是不同于通过配置管理器中,设置扫描将失败,客户端上因为找不到正确的 WSUS 计算机。在这种情况下,WUAHandler.log 将显示如下:

Group policy settings were overwritten by a higher authority (Domain Controller) to: Server http://server and Policy ENABLED 

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

假定服务器 URL 正确,请使用类似于下面的 URL 来验证客户端和 WSUS 计算机之间的连接的服务器访问:

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

检查 whetherthe 客户端可以访问 ClientWebService 虚拟目录,请尝试访问 aURL 与以下类似:

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

检查客户端是否可以访问 SimpleAuthWebService,请尝试访问类似于下面的 URL:

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

如果其中的任何失败,部分原因可能包括:

此故障可能致端口配置问题,因此它是一个好主意,要验证端口设置正确。可以将 WSUS 配置为使用以下端口中的任意: 80、 443 或 8530,8531。

对于 WSUS 计算机进行通信的客户端,必须在 WSUS 计算机上的防火墙允许相应的端口。软件更新点站点系统角色创建时配置端口设置。这些端口设置必须使用 WSUS 网站的端口设置为相同,或 WSUS 同步管理器将无法连接到 WSUS 的软件更新点上运行请求进行同步。下面的过程介绍如何验证使用 WSUS 和软件更新点的端口设置。

确定用于 IIS 7.0 及更高的 WSUS 端口设置

确定在 IIS 6.0 中的 WSUS 端口设置

为软件更新点配置端口

验证端口连接

要检查端口连接从客户端,请运行以下命令:

telnet SUPSERVER。CONTOSO.COM

例如,如果我们端口为 8530 我们将使用下面的命令:

telnet SUPSERVER。CONTOSO.COM 8530

如果无法访问端口,telnet 将返回类似于以下内容的错误:

Could not open connection to the host, on port <PortNumber>

 

此错误表明防火墙规则未配置为允许 WSUS 计算机的通信。请注意该错误可以还建议中间网络设备阻止该端口。若要验证,请尝试从同一子网上的本地客户端相同的测试。如果此程序,建议您的计算机是配置正确,但是路由器或防火墙之间段阻塞端口也导致故障。

  1. 请确保客户端使用正确的 URL
  2. 测试 URL
    • 在客户端上的名称解析问题。请验证您可以解析 WSUS 计算机的 FQDN。
    • 代理服务器配置问题。请参见上面的步骤 1。
    • 其他与网络相关的连接问题。
    • 端口配置问题 (见下文)。
    • IIS 的可用性问题。
    1. 在 WSUS 计算机上,打开Internet Information Services (IIS) 管理器
    2. 展开站点,右键单击 WSUS 计算机的网站,然后单击编辑绑定
    3. 站点绑定对话框中的 HTTP 和 HTTPS 端口值显示在端口列。
    1. 在 WSUS 服务器上,打开Internet Information Services (IIS) 管理器
    2. 展开Web 站点,右键单击的网站对于 WSUS 计算机,然后单击属性
    3. 单击网站选项卡。HTTP 端口设置显示在TCP 端口和 HTTPS 端口设置将显示在SSL 端口
    1. 在配置管理器控制台中,导航到管理窗格->站点配置->服务器和站点系统角色,然后单击< SiteSystemName >右侧窗格上的上。
    2. 在底部窗格中,用鼠标右键单击软件更新点,然后单击属性
    3. 转到常规选项卡并指定/确认 WSUS 配置端口号。

身份验证错误

扫描失败与身份验证错误 (HTTP 状态 401) 0x80244017 或 0x80244018 (HTTP 状态 403) 时,则通常表明

首先,确认正确 WinHTTP 代理设置使用下列命令:

  • 在 Windows Vista 上或以上: netsh winhttp 显示代理服务器
  • 在 Windows XP 中: proxycfg.exe

通过完成HTTP 超时错误上面中的步骤假定的代理服务器设置正确,验证与 WSUS 计算机建立连接。此外检查以确认正在从 WSUS 返回 HTTP 错误的 WSUS 计算机上的 IIS 日志。如果 WSUS 计算机没有返回错误,则可能与中间防火墙或代理问题。

证书问题

证书的问题通常指示错误代码 0x80072F0C,这意味着"证书需要完成客户端身份验证。"WSUS 计算机被配置为使用 SSL 的情况下,才应该发生该错误。为 SSL 配置的一部分,WSUS 虚拟目录必须配置为使用 SSL,将设置为"忽略"客户端证书。如果错误地将 WSUS 网站或任何这些虚拟目录配置为"接受"或"要求"客户端证书,会出现此错误。

按照以下步骤进行故障诊断与证书问题相关的错误:

验证软件更新点已配置的 SSL

  1. 在配置管理器控制台中,导航到管理窗格->站点配置->服务器和站点系统角色,然后在右侧窗格中单击< SiteSystemName >
  2. 在底部窗格中,用鼠标右键单击软件更新点,然后单击属性
  3. 常规选项卡上单击需要 SSL 通信到 WSUS 服务器

验证为 SSL 配置 WSUS 计算机

  1. 打开软件更新点网站上的 WSUS 控制台。
  2. 在控制台树窗格中,单击选项
  3. 在显示窗格中单击更新源和代理服务器
  4. 验证选中了使用 SSL 时同步更新信息

验证服务器身份验证证书添加到 WSUS 管理网站

若要将服务器身份验证证书添加到 WSUS 管理网站,完成以下任务:

  1. 在 WSUS 计算机上,打开Internet Information Services (IIS) 管理器
  2. 展开网站,用鼠标右键单击默认的 Web 站点WSUS 管理网站如果将 WSUS 配置为使用一个自定义的网站,然后选择编辑绑定
  3. 单击HTTPS条目,然后单击编辑。.
  4. 编辑站点绑定对话框中,选择服务器身份验证证书,然后单击确定
  5. 单击编辑网站绑定对话框中的确定,然后单击关闭
  6. 关闭Internet Information Services (IIS) 管理器

重要提示确保网站系统属性中所指定的 FQDN 匹配的证书中指定的 FQDN。如果软件更新点接受来自仅限于内联网连接,主题名称或者主题备用名称必须包含 intranet FQDN。当软件更新点接受来自 Internet 的客户端连接时,则证书因为 WCM 和 WSyncMgr 仍然使用 intranet FQDN 连接到软件更新点仍必须包含 Internet FQDN 和 intranet FQDN。如果软件更新点接受来自互联网与内联网连接,必须使用两个名称之间的 and 符 (&) 符号分隔符指定 Internet FQDN 和 intranet FQDN。

验证 SSL 配置 WSUS 计算机上

但是,可以使用相同的步骤在配置管理器 2012年中的 WSUS 上配置 SSL,下面的链接将应用于系统中心配置管理器 2007 年:

如何配置 WSUS 网站使用 SSL

重要提示不能将整个的 WSUS 网站,因为要求使用 SSL 配置,然后者必须到 WSUS 网站的所有通信进行加密。WSUS 加密更新元数据。如果一台计算机试图检索 HTTPS 端口上的更新文件,则传输将会失败。

WUAHandler 从 Windows 更新代理接收结果,并将标记为已完成扫描。

WUAHandler.log:

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

疑难解答

此处的问题应该得到解决上一步中的扫描失败一样。

前面已提到在本指南中,诊断扫描失败时,您应该查看的日志将是WUAHandler.logWindowsUpdate.log。因为 WUAHandler 只是报告 Windows 更新代理的报告,WUAHandler 中的错误将是同样的错误报告 Windows 更新代理本身,因此有关该错误的详细信息中找 WindowsUpdate.log。若要了解如何阅读 WindowsUpdate.log,请参见下面的知识库文章:

902093-如何读取 Windowsupdate.log 文件

一般来讲,有很多原因导致软件更新扫描可能失败。它可能是由于上面所提及的问题之一,或它可能简单地归结为通信或防火墙问题客户端软件更新点的计算机之间。您的信息的最佳来源将来自日志和它们所包含的错误代码。作为参考,您可以找到 Windows Update 错误代码的完整列表:

938205-Windows Update 错误代码列表

然后,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. 

疑难解答

此处的问题应该得到解决上一步中的扫描失败一样。

前面已提到在本指南中,诊断扫描失败时,您应该查看的日志将是WUAHandler.logWindowsUpdate.log。因为 WUAHandler 只是报告 Windows 更新代理的报告,WUAHandler 中的错误将是同样的错误报告 Windows 更新代理本身,因此有关该错误的详细信息中找 WindowsUpdate.log。若要了解如何阅读 WindowsUpdate.log,请参见下面的知识库文章:

902093-如何读取 Windowsupdate.log 文件

一般来讲,有很多原因导致软件更新扫描可能失败。它可能是由于上面所提及的问题之一,或它可能简单地归结为通信或防火墙问题客户端软件更新点的计算机之间。您的信息的最佳来源将来自日志和它们所包含的错误代码。作为参考,您可以找到 Windows Update 错误代码的完整列表:

938205-Windows Update 错误代码列表

更新存储记录状态,并引发在 WMI 中每个更新的状态消息。

可用的扫描结果后,这些结果存储在更新存储区中。 更新存储记录每个更新的当前状态,并创建每个更新的状态消息。 这些状态消息转发到站点服务器批量状态消息报告周期 (这是默认的分钟) 的结尾处。 请注意我们只发送状态邮件在下列情况下:

  • 以前的状态消息从不已发送的更新 (日志条目: 未完工之前,创建新的实例)
  • 更新的适用性状态已更改,因为提交的上次状态消息

UpdateStore.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 命名空间中。

疑难解答

此处的问题应该得到解决上一步中的扫描失败一样。

前面已提到在本指南中,诊断扫描失败时,您应该查看的日志将是WUAHandler.logWindowsUpdate.log。因为 WUAHandler 只是报告 Windows 更新代理的报告,WUAHandler 中的错误将是同样的错误报告 Windows 更新代理本身,因此有关该错误的详细信息中找 WindowsUpdate.log。若要了解如何阅读 WindowsUpdate.log,请参见下面的知识库文章:

902093-如何读取 Windowsupdate.log 文件

一般来讲,有很多原因导致软件更新扫描可能失败。它可能是由于上面所提及的问题之一,或它可能简单地归结为通信或防火墙问题客户端软件更新点的计算机之间。您的信息的最佳来源将来自日志和它们所包含的错误代码。作为参考,您可以找到 Windows Update 错误代码的完整列表:

938205-Windows Update 错误代码列表

当 WUAHandler 成功地收到来自 Windows 更新代理的结果时,它将标记为已完成扫描,并记录以下:

WUAHandler.log:

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

疑难解答

此处的问题应该得到解决一样扫描失败在上一步中,尽管在这一阶段的失败将可能才会显露出来在 WindowsUpdate.log 文件中明确。若要了解如何阅读 WindowsUpdate.log,请参见下面的知识库文章:

902093-如何读取 Windowsupdate.log 文件

一般来讲,有很多原因导致软件更新扫描可能失败。它可能是由于上面所提及的问题之一,或它可能简单地归结为通信或防火墙问题客户端软件更新点的计算机之间。您的信息的最佳来源将来自日志和它们所包含的错误代码。作为参考,您可以找到 Windows Update 错误代码的完整列表:

938205-Windows Update 错误代码列表

以下步骤概述了与 Microsoft 更新同步的 WSUS。 确认每个步骤以正确地建立问题的位置。

触发同步后,我们期望看到在 WSUS 服务器的 SoftwareDistribution.log 以下:

手动:

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

计划:

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

疑难解答

手动同步

  1. 请确认 theWSUS 服务正在运行。 如果您看到 thata 手动同步已开始,但它仍然为 0%,这通常是由于 WSUS 服务 (在 WSUS 上的"更新服务"3.x 版;"WSUSService"上 Windows Server 2012 +) 处于停止状态。
  2. 通过完成以下重置 WSUS 控制台的 MMC 缓存:

    1. 关闭在 WSUS 控制台
    2. 停止的 WSUS 服务 (在 WSUS 上的"更新服务"3.x 版;"WSUS 服务"上 Windows Server 2012 +)
    3. 浏览到%appdata%\Microsoft\mmc
    4. 重命名为"wsus_bak""wsus"
    5. 启动 WSUS 服务
    6. 打开 WSUS 控制台,请尝试另一个手动同步

计划的同步

  1. 请尝试从 WSUS 控制台中的手动同步。
  2. 如果手动同步效果很好,检查计划的同步设置。

启动同步后,WSUS 服务器将尝试进行 WinHTTP 通过 HTTP 连接。解决连接问题时,请考虑下列因素:

WSUS < = winhttp = > 网络实体 <> = 互联网

WSUS 宿主计算机和 Internet 之间存在网络实体 (代理服务器、 防火墙、 安全筛选器等)?

如果代理服务器存在并且 WSUS 服务器时需要使用代理服务器,代理服务器在配置,则 WSUS 设置正确吗?

疑难解答

手动同步

  1. 确认的 WSUS 服务正在运行。 如果您看到已启动手动同步,但它仍然为 0%,这通常是由于 WSUS 服务 (在 WSUS 上的"更新服务"3.x 版;"WSUS 服务"上 Windows Server 2012 +) 处于停止状态。
  2. 通过完成以下重置 WSUS 控制台的 MMC 缓存:
    1. 关闭在 WSUS 控制台
    2. 停止的 WSUS 服务 (在 WSUS 上的"更新服务"3.x 版;"WSUS 服务"上 Windows Server 2012 +)
    3. 浏览到%appdata%\Microsoft\mmc
    4. 重命名为"wsus_bak""wsus"
    5. 启动 WSUS 服务
    6. 打开 WSUS 控制台,请尝试另一个手动同步

计划的同步

  1. 请尝试手动同步从 WSUS 控制台中
  2. 如果手动同步效果很好,检查计划的同步设置。

一旦 WSUS 收到来自 Microsoft 更新产品的分类信息和订阅的任何元数据,WSUS 同步已完成。

出现的特定更新的部署问题可以分为下面的区域。开始进行故障排除时,请考虑以下这些领域与相关的组件。

区域->安装取代编号检测
-> 组件WUA 更新安装程序 (CBS,MSI) CCMExec更新程序元数据WUA 更新元数据更新安装程序 (CBS,MSI)

什么是安装程序 (CBS、 MSI,其他)?

CBS (基于组件服务):

适用于 Windows 操作系统 (Windows Vista 电流) 的更新,CBS 用于处理安装。

  1. 1.收集 CBS 日志 (Windir%\Logs\Cbs\Cbs.log %),并执行初审深入了解失败的原因。CBS 日志通过基于安装问题的故障排除本疑难解答,范畴是,但是下面的知识库文章可能会有所帮助:947821-修复 Windows 损坏错误使用 DISM 或系统更新准备工具
  2. 没有成功的用户身份登录安装更新? 如果它是否成功的用户身份登录安装的没有它只会失败,安装在系统上下文? 如果是这样,重点放在系统环境下的手动安装失败疑难解答。
MSI (Windows 安装程序):
对于非 Windows 软件更新,用于处理安装 MSI。
  1. 收集并查看默认 MSI 日志中的更新。检查关联的知识库文章有关的更新的任何已知问题/常见问题解答。
  2. 扩展 Windows 安装程序日志记录和重现故障。请参阅下面的知识库文章的详细信息:223300-如何启用 Windows 安装程序日志记录检查时所产生的日志,检查返回值 3 在日志和前深入失败项的行。
  3. 检查是否同一更新失败手动安装在本地系统上下文使用相同软件更新部署过程中失败的安装开关。如果此操作失败,请登录的用户具有相同的安装开关来了解这是否与安装在本地系统下一个问题与安装进行测试。若果真如此,您可以再集中精力如何正确安装使用本地系统上下文更新的问题。这可能需要更新或联机知识库中的管理部署指导检查。

尝试隔离问题与取代通过以下问题:

  1. 有关如何控制配置管理器何时到期更新,查看"取代规则"部分下面的: https://technet.microsoft.com/en-us/library/gg712312.aspx
  2. 如果通过配置管理器中已过期的更新,Microsoft 建议部署最新取代的更新。 如果您仍然需要将过期的更新部署,这些可以通过软件分发/应用程序管理软件更新部署外部署。
  3. 更新的取代逻辑密切相关的问题,首先查看知识库文章有关的更新的详细信息。 您还可以查看 Microsoft 更新目录,WSUS 控制台上或配置管理器控制台中的替换项。

确定每个客户端上更新的法规遵从性状态

  1. 查看更新的已知问题更新 KB 文章。
  2. 配置管理器客户端上运行"软件更新扫描周期"操作。
  3. 查看UpdatesStore.logWindowsUpdate.log

故障排除更新的适用性

  1. 检查正在使用更新的知识库文章缺少任何系统必备项。 例如,更新需要为应用程序或操作系统正在修补位于特定的服务包级别?
  2. 确认更新的唯一更新 ID 匹配内容部署。 例如,x86 是问题中的更新更新但 x64 到目标主机?

祝 !已解决了您的软件更新管理流程问题。

有关如何配置在配置管理器的软件更新的其他信息,请参阅:

您还可以将问题张贴在安全性、 更新和法规遵从性在此处我们配置管理器 2012年支持论坛中:

https://social.technet.microsoft.com/Forums/en-US/home?forum=configmanagersecurity

请访问我们的博客的所有最新的新闻、 信息和技术的提示在 Microsoft 系统中心配置管理器:

https://blogs.technet.microsoft.com/configurationmgr