Wmi

SCCM 2012 SP1 - DownloadContentFiles() 失敗,hr=0x80041013

  • March 12, 2014

我們注意到我們的軟體更新自動部署規則未能自動從Microsoft下載和應用本月的更新檔,儘管它們已正確列在目錄中。

目錄中列出的 SCCM 軟體更新

自動部署規則將其最後一個錯誤程式碼列為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_$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 的各個部分進行了核對。我不確定我想這樣做。

在這一點上,這是漫長的一天,我們需要修補這些伺服器,我的頭很痛。有什麼建議嗎?

也許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 更新的成功下載。 WBEMTEST __命名空間

WBEMTEST SMS_ProviderLocation

如果有人有更詳細的資訊,我將非常感謝有關 SCCM 如何使用這些命名空間以及如何解決此問題的更多資訊。

引用自:https://serverfault.com/questions/517138