SCCM 2012 SP1 - DownloadContentFiles() 失敗,hr=0x80041013
我們注意到我們的軟體更新自動部署規則未能自動從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
- 從 SCCM 站點伺服器日誌$$ SCCMInstallationPath $$\Logs\ruleengine.log看起來我們無法下載這些更新。顯然,解決這類問題的地方是PatchDownloader.log。而且’lo那裡還記錄了另一個錯誤:
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_$SITECODE
WMI 命名空間的軟體更新更新檔下載器。不幸的是,我沒有從 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 的各個部分進行了核對。我不確定我想這樣做。在這一點上,這是漫長的一天,我們需要修補這些伺服器,我的頭很痛。有什麼建議嗎?
也許
REV
站點程式碼用於 SCCM 2012 的臨時測試安裝?也許不是。機構知識沒有任何關於REV
它和我們在我被錄用之前執行的遷移的記錄。這個預感是對的。我得到了我的前任,顯然第一次嘗試從 SCCM 2007 遷移到 SCCM 2010 使用了
REV
站點程式碼,但未成功。它是如何在 WMI 中一直處於休眠狀態的,以及為什麼它被“啟動”對我來說完全是個謎。我非常仔細地重新閱讀了這篇TechNet文章中的解決方案,該文章建議刪除舊的命名空間並決定嘗試一下。即使它確實解決了這個問題,我也有點猶豫是否將其標記為答案,這表明我暗中讚成它,特別是因為我無法讓微軟的任何“官方”人員確認這是否是一種安全的方法或者這樣做的後果是什麼。話雖如此,在繼續之前,請確保您擁有 SCCM 伺服器的完整備份,或者至少對 WMI 有更深入的了解。這樣做你可以很容易地破壞一切,特別是如果你像我一樣不熟悉 WMI 以及 SCCM 對它的利用程度。
我使用 wbemtest 連接到
root\sms
我們 SCCM 伺服器上的命名空間。從那裡我用$$ Enum_Instances… $$按鈕並蒐索為
__NAMESPACE
超類。我刪除了REV
站點程式碼的條目。然後,我為超類執行了相同的 Enum_Instances,SMS_ProviderLocation
並從該命名空間中刪除了舊站點程式碼。重新執行自動部署規則並查看PatchDownloader.log
顯示每個 Windows 更新的成功下載。如果有人有更詳細的資訊,我將非常感謝有關 SCCM 如何使用這些命名空間以及如何解決此問題的更多資訊。