WSUS 客户端检测到 0 个更新

WSUS 客户端检测到 0 个更新

我最近在我们的域上设置了两台新服务器,分别标记为 CADCS001 和 CADCS001。除了主机名之外,这些服务器几乎完全相同,并且已设置为尽可能相似。其中一台服务器成功从我们的 WSUS 服务器下载更新,而另一台则没有。

两台服务器都是运行 Microsoft Windows Server 2008 R2 Standard x64 SP1 的 VMware ESXi VM。每台服务器都是从头开始设置的,并且每台服务器上都手动安装了 Windows(即它们不是从彼此或任何其他 VM 克隆的)。SP1 被集成到安装文件中,而不是单独安装的。

我们的 WSUS 服务器已使用一年多,似乎运行正常。我们有大约 30 台服务器和 150 台客户端 PC,据我所知,它们似乎都在下载和安装已批准的更新。两台服务器都位于 Active Directory 中的同一 OU 中,应用了相同的 GPO(并且成功应用了这些 GPO),并且都位于 WSUS 控制台上的同一容器中。

两台服务器均成功向 WSUS 服务器报告。更新设置为自动下载,但需要等待手动干预才能安装。两台服务器最初均报告有 131 个待处理更新。CADCS002 显示 Windows 更新系统托盘图标,然后安装了这些更新 - 剩下 1 个尚未批准的待处理更新。CADCS001 根本没有显示 Windows 更新系统托盘图标,但 WSUS 继续显示它有 131 个待处理更新。

运行“wuauclt /detectnow”或从控制面板中的 Windows 更新部分选择“检查更新”会在 WindowsUpdates.log 文件中创建以下条目:

2013-07-09  16:57:13:353     772    820 AU  #############
2013-07-09  16:57:13:353     772    820 AU  ## START ##  AU: Search for updates
2013-07-09  16:57:13:353     772    820 AU  #########
2013-07-09  16:57:13:353     772    820 AU  <<## SUBMITTED ## AU: Search for updates [CallId = {0A1B8894-16B0-4ACC-8CBA-59D074B91FA3}]
2013-07-09  16:57:13:353     772    138 Agent   *************
2013-07-09  16:57:13:353     772    138 Agent   ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
2013-07-09  16:57:13:353     772    138 Agent   *********
2013-07-09  16:57:13:353     772    138 Agent     * Online = Yes; Ignore download priority = No
2013-07-09  16:57:13:353     772    138 Agent     * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
2013-07-09  16:57:13:353     772    138 Agent     * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
2013-07-09  16:57:13:353     772    138 Agent     * Search Scope = {Machine}
2013-07-09  16:57:13:369     772    138 Setup   Checking for agent SelfUpdate
2013-07-09  16:57:13:369     772    138 Setup   Client version: Core: 7.6.7600.256  Aux: 7.6.7600.256
2013-07-09  16:57:13:369     772    138 Misc    Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
2013-07-09  16:57:13:369     772    138 Misc     Microsoft signed: Yes
2013-07-09  16:57:13:369     772    138 Misc    Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
2013-07-09  16:57:13:369     772    138 Misc     Microsoft signed: Yes
2013-07-09  16:57:13:369     772    138 Misc    Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
2013-07-09  16:57:13:384     772    138 Misc     Microsoft signed: Yes
2013-07-09  16:57:13:384     772    138 Misc    Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
2013-07-09  16:57:13:384     772    138 Misc     Microsoft signed: Yes
2013-07-09  16:57:13:400     772    138 Setup   Determining whether a new setup handler needs to be downloaded
2013-07-09  16:57:13:400     772    138 Setup   SelfUpdate handler is not found.  It will be downloaded
2013-07-09  16:57:13:400     772    138 Setup   Evaluating applicability of setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~amd64~~7.6.7600.256"
2013-07-09  16:57:13:400     772    138 Setup   Setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~amd64~~7.6.7600.256" is already installed.
2013-07-09  16:57:13:400     772    138 Setup   Evaluating applicability of setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.256"
2013-07-09  16:57:13:431     772    138 Setup   Setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.256" is already installed.
2013-07-09  16:57:13:431     772    138 Setup   Evaluating applicability of setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.256"
2013-07-09  16:57:13:478     772    138 Setup   Setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.256" is already installed.
2013-07-09  16:57:13:478     772    138 Setup   SelfUpdate check completed.  SelfUpdate is NOT required.
2013-07-09  16:57:13:790     772    138 PT  +++++++++++  PT: Synchronizing server updates  +++++++++++
2013-07-09  16:57:13:790     772    138 PT    + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://al_s0006/ClientWebService/client.asmx
2013-07-09  16:57:16:052     772    138 PT  +++++++++++  PT: Synchronizing extended update info  +++++++++++
2013-07-09  16:57:16:052     772    138 PT    + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://al_s0006/ClientWebService/client.asmx
2013-07-09  16:57:16:286     772    138 Agent     * Found 0 updates and 65 categories in search; evaluated appl. rules of 557 out of 847 deployed entities
2013-07-09  16:57:16:286     772    138 Agent   *********
2013-07-09  16:57:16:286     772    138 Agent   **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
2013-07-09  16:57:16:286     772    138 Agent   *************
2013-07-09  16:57:16:286     772    6d8 AU  >>##  RESUMED  ## AU: Search for updates [CallId = {0A1B8894-16B0-4ACC-8CBA-59D074B91FA3}]
2013-07-09  16:57:16:286     772    6d8 AU    # 0 updates detected
2013-07-09  16:57:16:286     772    6d8 AU  #########
2013-07-09  16:57:16:286     772    6d8 AU  ##  END  ##  AU: Search for updates [CallId = {0A1B8894-16B0-4ACC-8CBA-59D074B91FA3}]
2013-07-09  16:57:16:286     772    6d8 AU  #############
2013-07-09  16:57:16:286     772    6d8 AU  Successfully wrote event for AU health state:0
2013-07-09  16:57:16:286     772    6d8 AU  Featured notifications is disabled.
2013-07-09  16:57:16:286     772    6d8 AU  AU setting next detection timeout to 2013-07-10 13:10:52
2013-07-09  16:57:16:286     772    6d8 AU  Successfully wrote event for AU health state:0
2013-07-09  16:57:16:286     772    6d8 AU  Successfully wrote event for AU health state:0
2013-07-09  16:57:21:294     772    138 Report  REPORT EVENT: {DFDBAD4C-18AC-4483-91BA-112B6A866228}    2013-07-09 16:57:16:286+0100    1   147 101 {00000000-0000-0000-0000-000000000000}  0   0   AutomaticUpdates    Success Software Synchronization    Windows Update Client successfully detected 0 updates.
2013-07-09  16:57:21:294     772    138 Report  REPORT EVENT: {17AD4928-509E-47E6-856E-BE1F42AEE74D}    2013-07-09 16:57:16:286+0100    1   156 101 {00000000-0000-0000-0000-000000000000}  0   0   AutomaticUpdates    Success Pre-Deployment Check    Reporting client status.
2013-07-09  16:57:21:294     772    138 Report  CWERReporter finishing event handling. (00000000)

该日志文件似乎表明没有待处理的更新,但 WSUS 清楚地显示有更新,并且 CADCS002 已成功安装它们。

选择“在线检查 Microsoft Update 的更新”效果很好。它会显示所有待处理的更新(包括我们尚未批准安装的更新)并允许安装它们。对所有重要更新执行此操作可将 WSUS 中报告的待处理更新数量从 131 个减少到 12 个,因此服务器肯定报告成功。不幸的是,仍然没有 Windows 更新系统托盘图标来安装剩余的 12 个更新,并且从控制面板中的 Windows 更新部分单击“检查更新”仍会显示“Windows 已更新”消息。

我尝试安装“Windows Server 2008 R2 x64 版的系统更新准备工具 (KB947821)”,安装正确但没有报告任何错误:

=================================
Checking System Update Readiness.
Binary Version 6.1.7601.21645
Package Version 19.0
2013-07-09 16:16

Checking Windows Servicing Packages

Checking Package Manifests and Catalogs

Checking Package Watchlist

Checking Component Watchlist

Checking Packages

Checking Component Store

Summary:
Seconds executed: 333
 No errors detected
(w) Unable to get system disk properties    0x0000045D  IOCTL_STORAGE_QUERY_PROPERTY    Disk Cache

据我所知,“无法获取系统磁盘属性”消息似乎是正常的。

我无法运行“WSUS 客户端诊断工具”因为这是 64 位 Windows 2008 安装。

我尝试从 WSUS 控制台删除计算机并运行“wuauclt /resetauthorization /detectnow”,成功将其重新添加到“未分配的计算机”容器中。然后,我将其移至正确的容器并等待其报告,结果它又说有 12 个待处理的更新,但服务器本身仍然拒绝确认它们。

我尝试从 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate 中删除 SusClientId 和 SusClientIdValidation 注册表项,并重复上述过程,结果完全相同。

我已将 CADCS001 上的 WindowsUpdate.log 文件的输出与 CADCS002 上的输出进行了比较,除了时间戳以及 CallID 和 clientId 字符串之外,唯一的区别是以下几行:

CADCS001:

Agent * Found 0 updates and 65 categories in search; evaluated appl. rules of 557 out of 847 deployed entities

CADCS002:

Agent * Found 0 updates and 65 categories in search; evaluated appl. rules of 557 out of 895 deployed entities

服务器已多次重启,并多次运行“wuauclt /detectnow”。每次在 CADCS001 上检查 WindowsUpdate.log 文件时,它都显示“检测到 0 个更新”。

  • 两个服务器应该相同。
  • 两者都正确向 WSUS 报告,并且 WSUS 正确指出了需要将哪些更新应用到每台服务器。
  • 新的服务器和 WSUS 服务器均未在事件查看器、WindowsUpdate.log 文件或系统更新准备工具中报告任何错误。
  • 这两台新服务器都能够直接从 Microsoft Update 检测和安装 Windows 更新。

但由于某种原因,其中一台服务器坚持认为 WSUS 没有可用的更新。

还有其他人经历过这种情况吗?

更新 - 已修复

该问题似乎是由于 \Windows\SoftwareDistribution 文件夹损坏造成的。以下步骤解决了该问题:

  1. 停止“Windows 更新”服务
  2. 重命名 \Windows\SoftwareDistribution 文件夹
  3. 重新启动“Windows 更新”服务
  4. 打开命令提示符并wuauclt /resetauthorization输入wuauclt /detectnow

几分钟后,Windows 更新系统托盘图标出现,可以安装待处理的更新。然后可以安全删除重命名的(旧)文件夹。

答案1

这可能是多种原因造成的。例如,我曾见过更新意外地破坏 WSUS 客户端。不过,我认为我从未见过客户端错误地报告没有更新,除非缺少先决条件更新。

看起来您已经检查过注册表项,因此我将跳过该步骤。

因此我要推荐:

  • 检查是否有任何“先决条件”更新。
  • \Windows\SoftwareDistribution 目录可能已损坏。wuauclt /detectnow如果是这样,重命名或删除文件夹并运行应该会有所帮助。
  • Microsoft 提供了一系列 dll,您可以尝试重新注册等,网址为:
    http://support.microsoft.com/kb/555989

希望对您有帮助。祝您好运!

答案2

2013-07-09 16:57:16:286 772 138 代理 * 搜索中找到 0 个更新和 65 个类别;

这是关键信息。此日志条目意味着没有更新可用的针对此客户。

WSUS 环境中更新的可用性需要两个条件: - 更新已获准用于客户端为其指定成员的目标组。 - 更新的安装文件已下载到 WSUS 服务器。

在大多数情况下,这种情况的发生是因为已批准的更新文件尚未下载到 WSUS 服务器。有时这是因为批准了太多更新,导致下载队列被数百个文件(涉及数十 GB 的下载)堵塞。有时这是因为下载实际上失败了,通常是因为 Web 过滤器或代理服务器干扰了。

检查 WSUS 控制台主页上的“下载状态”,并检查应用程序事件日志中的 EventID 364。

相关内容