我们注意到，我们的软件更新自动部署规则未能自动下载并应用本月的补丁微软尽管它们在目录中被正确列出。
自动部署规则列出其最后错误代码为，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 站点服务器日志
看起来我们无法下载这些更新。显然，解决此类问题的地方是补丁下载器.瞧，然而那里记录了另一个错误：
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 与Error: 4115ruleengine.log 中记录的条目进行协调，因此，如前所述，我很确定正在查看生成所有这些不同错误的同一事件，但如果有人知道得更多，请纠正我。
如果我使用 CMTrace 的错误查找工具，它会告诉我有关 hr= 的以下信息0x80041013。
Provider load failure
Source: Windows Management (WMI)
-----
果然，如果我查看软件更新补丁下载程序所连接的 WMI 命名空间，它看起来不太正确：
\SCCM.ad.example.com\root\sms\site_REV
我们的站点代码实际上是004REV，而且有趣的是，我们组织的前三个字母以 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 的部分。我不确定我想这样做。
到目前为止，这已经是漫长的一天了，我们需要修补这些服务器，我的头很痛。有什么建议吗？
答案1
也许
REV站点代码用于 SCCM 2012 的临时测试安装？也许不是。机构知识没有任何关于它REV和我在受雇之前执行的迁移的记录。
这个猜测是正确的。我联系了我的前任，显然第一次从 SCCM 2007 迁移到 SCCM 2010 的失败尝试使用了REV站点代码。它是如何一直处于 WMI 休眠状态以及为什么它被“激活”对我来说完全是个谜。
我非常仔细地重读了这篇文章中的解决方案科技网帖子建议删除旧的命名空间，我决定尝试一下。虽然它确实解决了这个问题，但我还是有点犹豫是否将其标记为答案，这表明我暗中赞同它，特别是因为我无法让微软的任何“官方”人员确认这是否是一种安全的方法，或者这样做的后果是什么。话虽如此，在继续操作之前，请确保您有 SCCM 服务器的完整备份，或者至少对 WMI 有更深入的了解。这样做很容易破坏一切，特别是如果像我一样，您不熟悉 WMI 以及 SCCM 对它的利用程度。
我使用 wbemtest 连接到root\sms我们 SCCM 服务器上的命名空间。然后我使用 [Enum_Instances...] 按钮并搜索__NAMESPACE作为超类。我删除了站点代码的条目REV。然后，我对作为超类执行了相同的 Enum_Instances 操作SMS_ProviderLocation，并从该命名空间中删除了旧站点代码。重新运行自动部署规则并查看显示PatchDownloader.log每个 Windows 更新都已成功下载。
如果有人有更详细的信息，我将非常感激有关 SCCM 如何使用这些命名空间以及如何解决问题的更多信息。