SCCM 2012 SP1 - не вдалося завантажитиContentFiles () з hr = 0x80041013


15

Ми помітили, що наші Правила автоматичної розгортання оновлень програмного забезпечення не вдалося автоматично завантажити та застосувати виправлення цього місяця від 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 (імовірно, файл журналу, з якого отримується журнал SMS_RULE_ENGINE вищого рівня в SCCM), і координую ідентифікатор пакета для відповідних пакетів розгортання, згідно з якими правила автоматичної розгортання повинні розміщувати ці оновлення в I знайдіть наступне:

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 - з журналу моніторингу SMS_RULE_ENGINE консолі SCCM
  • 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 назад до Error: 4115записів, записаних у ruleengine.log, тому, як було сказано раніше, я майже впевнений, що дивився на ту саму подію, що генерує всі ці різні помилки, але якщо хтось знає краще, будь ласка виправте мене.

Якщо я використовую інструмент пошуку помилок 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це та міграцію, яку ми проводили до того, як мене прийняли на роботу.

Однак наш старий PatchDownloader.log з екземпляра SCCM 2007 показує Software Updates Patch Downloader, що підключається до site_$SITECODEпростору імен WMI. На жаль, у мене немає журналів з нашої поточної інсталяції 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) або пов'язаних з ними дозволів.

Тоді як константи помилок WMI від MSDN кажуть, що це проблема дозволів:

WBEM_E_ACCESS_DENIED 2147749891 (0x80041003) Поточний користувач не має дозволу на виконання дії.

Єдиною іншою інформацією, яку я міг знайти про 0x80041013помилку, був співробітник, який опублікував у TechNet, який, схоже, мав той самий випуск, як і я, навіть до того, де у нього була попередня установка SCCM, на чий простір імен WMI помилково посилався ( наприклад, site_REVзамість site_004). Він занурив весь простір імен WMI, а також частини SMS_ProviderLocation. Я не впевнений, що хочу це зробити.


На даний момент минув довгий день, нам потрібно зафіксувати ці сервери, і мені болить голова. Будь-яка порада?


1
Ви спробували завантажити / розгортати оновлення вручну (пропустити ADR)? І ... можливо, видалити та заново створити ADR?
Джейсон Сипкенс

@JasonSypkens - Видалення ADR та відтворення їх відтворює помилку, і я б дійсно краще виправити основну проблему з SCCM, а не завантажувати оновлення вручну - ми ще не такі відчайдушні.

Чи існує на вашому основному сервері сайту кореневий простір імен WMI \ sms \ site_REV? чи існує root \ sms \ site_004? Також це може бути дещо різким, але ... ви намагалися видалити та повторно додати роль SUP та / або перевстановити WSUS? Я переглянув консоль управління, і я не бачу очевидного моменту, коли SUP може бути налаштований на неправильний код сайту.
Джейсон Сипкенс

Відповіді:


5

Можливо, REVкод сайту був використаний для тимчасової тестової установки SCCM 2012? Можливо, ні. Інституційні знання не мають жодного запису про REVце та міграцію, яку ми проводили до того, як мене прийняли на роботу.

Цей хит був правильним. Я влаштував свого попередника, і, мабуть, перша і невдала спроба переходу з SCCM 2007 на SCCM 2010 використала REVкод сайту. Як мені вдалося весь цей час сидіти в режимі спокою у WMI і чому він активізувався - для мене повна загадка.

Я дуже уважно перечитав рішення в цій публікації TechNet, яка порадила видалити старі простори імен і вирішила спробувати це. Я якось вагаюся відзначити це як відповідь, хоча він вирішив цю проблему, це вказує на те, що я неявно схвалюю її, тим більше, що я не міг отримати когось "офіційного" в Microsoft, щоб підтвердити, чи це безпечний підхід чи ні. або які наслідки були для цього. Зважаючи на це, перед тим, як продовжувати, переконайтесь, що у вас є цілі резервні копії сервера SCCM або принаймні набагато більш інтимні знання WMI. Ви можете дуже легко зламати все, роблячи це, особливо якщо, як я, ви не знайомі з WMI і наскільки глибоко це використовує SCCM.


Я використовував wbemtest для підключення до root\smsпростору імен на нашому сервері SCCM. Звідти я використовував кнопку [Enum_Insances ...] і шукав __NAMESPACEяк суперклас. Я видалив запис для REVкоду сайту. Потім я зробив те саме Enum_Insances для SMS_ProviderLocationсуперкласу і видалив старий код сайту з цього простору імен. Повторне запуск Правил автоматичної розгортання та перегляд PatchDownloader.logпоказали успішне завантаження кожного оновлення Windows.

WBEMTEST __NAMESPACE

WBEMTEST SMS_ProviderLocation

Я дуже вдячний більше інформації про те, як SCCM використовує ці простори імен і як саме це вирішило проблему, якщо хтось має більш детальну інформацію.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.