我们注意到我们的软件更新自动部署规则未能自动从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日志的日志文件），并协调自动部署规则应将这些更新放置在I中的相关部署程序包的程序包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-在SCCM站点服务器上，来自[SCCMInstallationPath] \ Logs \ ruleengine.log的日志
看来我们无法下载这些更新。显然，解决此类问题的地方是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中的Content ID协调回到ruleengine.log中Error: 4115记录的条目，因此，如前所述，我敢肯定，我正在查看同一事件，它会产生所有这些不同的错误，但是如果有人知道的更好，请纠正我。
如果我使用CMTrace的错误查找工具，它将告诉我有关hr =的以下信息0x80041013。
Provider load failure
Source: Windows Management (WMI)
-----
可以肯定的是，如果我查看软件更新补丁下载器正在连接的WMI名称空间，它看起来并不正确：
\ SCCM.ad.example.com \ root \ sms \ site_REV
我们的站点代码实际上004和有趣的是，我们组织的前三个字母以REV开头。如果你问我，很巧合。此外，这不是这里的第一个SCCM安装，事实证明以前的SCCM 2007已有现有的边界，集合和程序包迁移到了我们的新安装中。抽烟的枪？不完全的。它也使用了不同的站点代码。也许REV站点代码用于SCCM 2012的临时测试安装？也许不是。机构知识没有关于REV它以及我们被雇用之前进行的迁移的任何记录。
但是，我们来自SCCM 2007实例的旧PatchDownloader.log显示了连接到site_$SITECODEWMI名称空间的软件更新补丁下载器。不幸的是，我没有从五月份开始的当前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深入的某个地方，有些事情告诉Software Updates Patch Downloader要连接\\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的各个部分。我不确定要这么做。
至此，已经漫长的一天了，我们需要修补这些服务器，并且头疼。有什么建议吗？
