Назад | Перейти на главную страницу

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 (который предположительно является файлом журнала, из которого создается журнал 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 показывает, что загрузчик исправлений обновлений программного обеспечения подключается к 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 что-то говорит загрузчику обновлений программного обеспечения подключиться к \\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. Я не уверен, что хочу это сделать.

На данный момент это был долгий день, нам нужно починить эти серверы, а у меня болит голова. Любой совет?

Возможно REV код сайта использовался для временной тестовой установки SCCM 2012? Возможно нет. Институциональные знания не содержат записей о REV это и миграция, которую мы выполнили до того, как меня наняли.

Это предположение было правильным. Я взял своего предшественника, и, по-видимому, первая и неудачная попытка перехода с SCCM 2007 на SCCM 2010 использовала REV код сайта. Как ему удавалось бездействовать в WMI все это время и почему он «активировался» - для меня полная загадка.

Я очень внимательно перечитал решение в этом TechNet сообщение, которое советовало удалить старые пространства имен и решил попробовать это. Я как бы не решаюсь отметить это как ответ, даже если он действительно решил эту проблему, это означает, что я безоговорочно одобряю его, тем более что я не мог попросить кого-либо «официального» в Microsoft подтвердить, является ли это безопасным подходом. или каковы были последствия этого. При этом убедитесь, что у вас есть полные резервные копии вашего SCCM-сервера или, по крайней мере, вы хорошо знакомы с WMI, прежде чем продолжить. Вы можете очень легко сломать все, делая это, особенно если вы, как и я, не знакомы с WMI и насколько глубоко SCCM его использует.

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

Я был бы очень признателен за дополнительную информацию о том, как эти пространства имен используются SCCM и как именно это решило проблему, если у кого-то есть более подробная информация.