SCCM 2012 SP1 - DownloadContentFiles() 失败，hr=0x80041013

Question

我们注意到我们的软件更新自动部署规则未能自动从Microsoft下载并应用本月的补丁，尽管它们已正确列在目录中。

自动部署规则将其最后一个错误代码列为0X87D20417，最后一个错误描述列为“自动部署规则下载失败”。手动重新运行规则会重现此错误。删除并重新创建自动部署规则也会重现相同的错误。

查看 SMS_RULE_ENGINE 日志显示以下错误：

Error   Milestone   004 6/19/2013 3:42:21 PM    SCCM.ad.example.com SMS_RULE_ENGINE 8706     Content download failed.   Message: Failed to download one or more content files.   Source: SMS Rule Engine.   
Error   Milestone   004 6/19/2013 3:42:07 PM    SCCM.ad.example.com SMS_RULE_ENGINE 8706     Content download failed.   Message: Failed to download one or more content files.   Source: SMS Rule Engine.   
Error   Milestone   004 6/19/2013 2:45:44 PM    SCCM.ad.example.com SMS_RULE_ENGINE 8706     Content download failed.   Message: Failed to download one or more content files.   Source: SMS Rule Engine.   
Error   Milestone   004 6/19/2013 2:43:29 PM    SCCM.ad.example.com SMS_RULE_ENGINE 8706     Content download failed.   Message: Failed to download one or more content files.   Source: SMS Rule Engine.   

如果我查看 ruleengine.log（大概是 SCCM 中更高级别的 SMS_RULE_ENGINE 日志从中生成的日志文件）并协调自动部署规则应该将这些更新放在我中的相关部署包的包 ID找到以下内容：

Contents 16821586 is already present in the package "0040000F". Skipping download.  SMS_RULE_ENGINE 6/19/2013 3:41:58 PM    9068 (0x236C)
Downloading contents (count = 10) for UpdateID 16829711 SMS_RULE_ENGINE 6/19/2013 3:41:58 PM    9068 (0x236C)
List of update content(s) which match the content rule criteria = {16821659,16821660,16821661,16821662,16821663,16821664,16821665,16821666,16821667,16821668}   SMS_RULE_ENGINE 6/19/2013 3:41:58 PM    9068 (0x236C)
Downloading content with ID 16821659 in the package SMS_RULE_ENGINE 6/19/2013 3:41:58 PM    9068 (0x236C)
Failed to download the update from internet. Error = 4115   SMS_RULE_ENGINE 6/19/2013 3:41:58 PM    9068 (0x236C)
Failed to download ContentID 16821659 for UpdateID 16829711. Error code = 4115  SMS_RULE_ENGINE 6/19/2013 3:41:58 PM    9068 (0x236C)

在这一点上，我认为三个不同的错误都是由同一事件产生的。当然，它们可能不是，这就是为什么它们都包含在这里。我确实协调了日志文件中的时间，并且有理由相信它们都与自动部署规则的问题有关。

• 0X87D20417 - 从 SCCM 控制台的自动部署规则
• 8706 - 来自 SCCM 控制台的监控 SMS_RULE_ENGINE 日志
• Error code = 4115 - 来自 [SCCMInstallationPath]\Logs\ruleengine.log 的 SCCM 站点服务器日志

我们似乎无法下载这些更新。显然，解决这类问题的地方是PatchDownloader.log。并且'瞧，那里还记录了另一个错误：

Trying to connect to the \\SCCM.ad.example.com\root\sms\site_REV namespace on the SCCM.ad.example.com machine.  Software Updates Patch Downloader   6/19/2013 3:42:21 PM    9068 (0x236C)
Connected to \\SCCM.ad.example.com\root\sms\site_REV    Software Updates Patch Downloader   6/19/2013 3:42:21 PM    9068 (0x236C)
GetContentFileInfoForDownload() failed for ContentID 16821994. hRes = 0x80041013 .  Software Updates Patch Downloader   6/19/2013 3:42:21 PM    9068 (0x236C)
ERROR: DownloadContentFiles() failed with hr=0x80041013 Software Updates Patch Downloader   6/19/2013 3:42:21 PM    9068 (0x236C)

我可以将 PatchDownloader.log 中的内容 ID 协调回 ruleengine.log 中Error: 4115记录的条目，因此，如前所述，我很确定正在查看生成所有这些不同错误的同一事件，但如果有人知道得更好，请纠正我。

如果我使用 CMTrace 的错误查找工具，它会告诉我以下有关 hr= 的信息0x80041013。

Provider load failure

Source: Windows Management (WMI)
-----

如果我查看 Software Updates Patch Downloader 连接到的 WMI 命名空间，肯定会发现它看起来不太正确：

\SCCM.ad.example.com\root\sms\site_REV

我们的站点代码实际上很004有趣，我们组织的前三个字母以 REV 开头。如果你问我，这完全是巧合。此外，这不是这里存在的第一个 SCCM 安装，事实证明，以前的 SCCM 2007 将现有的边界、集合和包迁移到我们的新安装中。烟枪？不完全的。它也使用了不同的站点代码。也许 REV 站点代码用于 SCCM 2012 的临时测试安装？也许不是。机构知识没有任何关于REV它和我们在我被雇用之前执行的迁移的记录。

但是 - 我们来自 SCCM 2007 实例的旧 PatchDownloader.log 显示软件更新补丁下载器连接到site_$SITECODEWMI 命名空间。不幸的是，我没有从 5 月开始的当前 2012 安装的日志，我可以在其中确认引用了正确的 WMI 命名空间。

Trying to connect to the root\SMS namespace on the SCCM07.ad.example.com machine.   Software Updates Patch Downloader   8/3/2011 3:18:37 PM 25128 (0x6228)
Connected to \\SCCM07.ad.example.com\root\SMS   Software Updates Patch Downloader   8/3/2011 3:18:37 PM 25128 (0x6228)
Trying to connect to the \\SCCM07.ad.example.com\root\sms\site_DOR namespace on the  machine.   Software Updates Patch Downloader   8/3/2011 3:18:37 PM 25128 (0x6228)
Connected to \\SCCM07.ad.example.com\root\sms\site_DOR  Software Updates Patch Downloader   8/3/2011 3:18:37 PM 25128 (0x6228)
Download destination = \\SCCM07.ad.example.com\WSUSContent\be128fa4-0c6b-418a-893d-3450e38c658d.1\windows-kb890830-v3.21.exe .  Software Updates Patch Downloader   8/3/2011 3:18:37 PM 25128 (0x6228)
Contentsource = http://download.windowsupdate.com/msdownload/update/software/uprl/2011/07/windows-kb890830-v3.21_2aba440b72071ff17cad1ca2a39f0e40aa85c76e.exe . Software Updates Patch Downloader   8/3/2011 3:18:37 PM 25128 (0x6228)
Downloading content for ContentID = 31068,  FileName = windows-kb890830-v3.21.exe.  Software Updates Patch Downloader   8/3/2011 3:18:37 PM 25128 (0x6228)

好的。它确实看起来像 WMI 命名空间的问题。在 SCCM 深处的某个地方，有些东西告诉软件更新补丁下载器连接到\\SCCM.ad.example.com\root\sms\site_REV而不是\\SCCM.ad.example.com\root\sms\site_004.

在 WAG 上，我检查了 SQL 数据库中可能的表以查找引用REV无济于事..

SELECT * FROM SysResList WHERE SiteCode = 'REV';
SELECT * FROM SiteControl WHERE SiteCode = 'REV';
SELECT * FROM SiteControlNotification WHERE SiteCode = 'REV';
SELECT * FROM Sites WHERE SiteCode = 'REV';
SELECT * FROM Sites_DATA WHERE SiteCode = 'REV';
SELECT * FROM SiteWork WHERE SiteCode = 'REV';
SELECT * FROM PkgServers WHERE sitecode = 'REV';
SELECT * FROM PkgStatus WHERE sitecode = 'REV';

为了使事情更加复杂，我看到了对该0x80041013错误的多种解释。

WMI 故障排除提示说加载 WMI 提供程序失败：

WBEM_E_PROVIDER_LOAD_FAILURE - 0x80041013

提供者事件故障排除类是一个很好的资源，但可能有点让人不知所措。MSFT_WmiProvider_LoadOperationFailureEvent 类是我经常发现有用的类。我遇到的大多数提供程序加载失败都是由于错误的组件注册（在注册表或 WMI 中）或相关权限造成的。

而来自 MSDN 的 WMI 错误常量表示这是一个权限问题：

WBEM_E_ACCESS_DENIED 2147749891 (0x80041003) 当前用户无权执行该操作。

我能找到的关于0x80041013错误的唯一其他信息是一个在 TechNet 上发帖的人，他似乎和我有同样的问题，甚至可以追溯到他之前安装的 SCCM 其 WMI 命名空间被错误引用的问题（例如，site_REV而不是site_004）。他最终破坏了整个 WMI 命名空间以及 SMS_ProviderLocation 的部分。我不确定我想这样做。

在这一点上，这是漫长的一天，我们需要修补这些服务器，我的头很痛。有什么建议吗？

Answer 1

也许REV站点代码用于 SCCM 2012 的临时测试安装？也许不是。机构知识没有任何关于REV它和我们在我被雇用之前执行的迁移的记录。

这个预感是对的。我掌握了我的前任，显然，从 SCCM 2007 迁移到 SCCM 2010 的第一次但未成功的尝试使用了REV站点代码。它是如何在 WMI 中一直处于休眠状态的，以及它为什么被“激活”，这对我来说完全是个谜。

我非常仔细地重新阅读了这篇TechNet帖子中的解决方案，其中建议删除旧的命名空间并决定尝试一下。即使它确实解决了这个问题，我也有点犹豫是否将其标记为答案，这表明我暗中赞同它，特别是因为我无法让微软的任何“官方”人员确认这是否是一种安全的方法或者这样做的后果是什么。话虽如此，在继续之前，请确保您有完整的 SCCM 服务器备份或至少对 WMI 有更深入的了解。这样做可以很容易地破坏一切，特别是如果像我一样，您不熟悉 WMI 以及 SCCM 对它的利用程度。

我使用 wbemtest 连接到root\sms我们 SCCM 服务器上的命名空间。从那里我使用 [Enum_Instances...] 按钮并搜索__NAMESPACE作为超类。我删除了REV站点代码的条目。然后，我SMS_ProviderLocation为超类执行了相同的 Enum_Instances，并从该命名空间中删除了旧站点代码。重新运行自动部署规则并查看PatchDownloader.log显示每个 Windows 更新的成功下载。

如果有人有更详细的信息，我将非常感谢有关 SCCM 如何使用这些命名空间的更多信息，以及如何解决问题。