Percebemos que nossas Regras de Implantação Automática para Atualizações de Software falharam ao baixar e aplicar automaticamente os patches deste mês da Microsoft, embora estejam listados corretamente no Catálogo.
As regras de implantação automática listam seu último código de erro como 0X87D20417e a descrição do último erro como "Falha no download automático da regra de implantação". Voltar a executar as regras manualmente reproduz esse erro. Excluir e recriar as Regras de implantação automática também reproduz o mesmo erro.
Examinar o log SMS_RULE_ENGINE mostra os seguintes erros:
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.
Se eu examinar o ruleengine.log (que é presumivelmente o arquivo de log do qual o log SMS_RULE_ENGINE de nível superior no SCCM é gerado) e coordenar a identificação do pacote para os pacotes de implantação relevantes nos quais as regras de implantação automática devem colocar essas atualizações em I encontre o seguinte:
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)
Neste ponto, tenho três erros diferentes que, acredito, são todos gerados pelo mesmo evento. Claro, eles podem não ser, e é por isso que estão todos incluídos aqui. Coordenei os horários nos arquivos de log e estou razoavelmente confiante de que todos estão relacionados ao problema com as Regras de implantação automática.
0X87D20417- Das regras de implantação automática do console SCCM8706- No registro SMS_RULE_ENGINE de monitoramento do console do SCCMError code = 4115- Nos logs do servidor do site SCCM, em [SCCMInstallationPath] \ Logs \ ruleengine.log
Parece que não podemos baixar essas atualizações. Aparentemente, o local para solucionar esse tipo de coisa é o PatchDownloader.log . E 'lo há ainda outro erro gravado lá:
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)
Posso coordenar os IDs de conteúdo no PatchDownloader.log para as Error: 4115entradas registradas no ruleengine.log, portanto, como mencionado anteriormente, tenho certeza de que estávamos olhando para o mesmo evento gerando todos esses erros diferentes, mas se alguém souber melhor, por favor Me corrija.
Se eu usar a ferramenta de pesquisa de erro do CMTrace, ele me informa o seguinte sobre hr = 0x80041013.
Provider load failure
Source: Windows Management (WMI)
-----
E com certeza, se eu olhar para o espaço de nome WMI ao qual o Software Updates Patch Downloader está se conectando, ele não parece muito correto:
\ SCCM.ad.example.com \ root \ sms \ site_REV
Nosso Código do Site é realmente 004e engraçado o suficiente para as três primeiras letras de nossa organização começarem com REV. Poderosa coincidência se você me perguntar. Além disso, esta não é a primeira instalação do SCCM que existe aqui e, no final, o SCCM 2007 anterior tinha os limites, coleções e pacotes existentes migrados para a nova instalação. Arma de fumar? Não é bem assim. Ele também usava um código de site diferente. Talvez o código do site REV tenha sido usado para uma instalação de teste temporária do SCCM 2012? Talvez não. O conhecimento institucional não tem nenhum registro REVdisso e da migração que realizamos antes de eu ser contratado.
No entanto - nosso antigo PatchDownloader.log da instância do SCCM 2007 mostra o Software Updates Patch Downloader conectado ao site_$SITECODEespaço para nome WMI. Infelizmente, não tenho logs da nossa instalação atual de 2012 a partir de maio, onde posso confirmar que o espaço para nome WMI correto está sendo referenciado.
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)
ESTÁ BEM. Realmente parece um problema com os namespaces WMI. Em algum lugar profundo do SCCM, algo está dizendo ao Software Updates Patch Downloader para conectar-se ao \\SCCM.ad.example.com\root\sms\site_REVinvés de \\SCCM.ad.example.com\root\sms\site_004.
Em um WAG, verifiquei as tabelas prováveis no banco de dados SQL para obter referências REVsem sucesso.
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';
Para complicar ainda mais as coisas, estou vendo várias explicações do 0x80041013erro.
As dicas de solução de problemas do WMI dizem que é uma falha ao carregar um provedor WMI:
WBEM_E_PROVIDER_LOAD_FAILURE - 0x80041013
As Classes de solução de problemas de eventos do provedor são um excelente recurso, mas podem ser um pouco esmagadoras. A classe MSFT_WmiProvider_LoadOperationFailureEvent é uma que eu achei útil com bastante frequência. A maioria das falhas de carregamento do provedor que encontrei foram resultado de um registro incorreto de componentes (no registro ou no WMI) ou de permissões relacionadas.
Considerando que as constantes de erro WMI do MSDN dizem que é um problema de permissão:
WBEM_E_ACCESS_DENIED 2147749891 (0x80041003) O usuário atual não tem permissão para executar a ação.
As únicas outras informações que pude encontrar sobre o 0x80041013erro foram um colega que postou no TechNet que parece ter o mesmo problema que eu, até o problema em que ele tinha uma instalação anterior do SCCM e cujo espaço de nome WMI estava sendo referenciado por engano ( por exemplo, em site_REVvez de site_004). Ele acabou destruindo todo o espaço para nome WMI, bem como as partes do SMS_ProviderLocation. Não tenho certeza se quero fazer isso.
Neste ponto, já faz um longo dia, precisamos corrigir esses servidores e minha cabeça dói. Algum conselho?
Respostas:
Este palpite estava correto. Entrei em contato com meu antecessor e, aparentemente, a primeira tentativa sem êxito de migrar do SCCM 2007 para o SCCM 2010 usou o
REVcódigo do site. Como ele conseguiu permanecer inativo no WMI esse tempo todo e por que foi "ativado" é um mistério completo para mim.Reli com muita atenção a solução nesta postagem do TechNet, que recomendava a exclusão dos namespaces antigos e decidi tentar isso. Eu meio que hesito em marcar isso como uma resposta, mesmo que ele tenha resolvido esse problema. Isso indica que eu o aprovo implicitamente, principalmente porque não consegui que ninguém "oficial" da Microsoft confirmasse se essa era uma abordagem segura. ou quais foram as consequências para isso. Dito isto, verifique se você possui backups completos do servidor SCCM ou pelo menos um conhecimento muito mais íntimo do WMI antes de continuar. Você poderia facilmente quebrar tudo isso, principalmente se, como eu, não estiver familiarizado com o WMI e com que profundidade o SCCM o alavanca.
Usei o wbemtest para conectar-se ao
root\smsespaço para nome em nosso servidor SCCM. A partir daí, usei o botão [Enum_Instances ...] e procurei__NAMESPACEcomo a superclasse. Eu apaguei a entrada para oREVcódigo do site. Em seguida, fiz o mesmo Enum_Instances para aSMS_ProviderLocationsuperclasse e excluí o código do site antigo desse namespace. A nova execução das Regras de Implantação Automática e a revisão doPatchDownloader.logmostrou o download bem-sucedido de cada Windows Update.Apreciaria muito mais informações sobre como esses namespaces são usados pelo SCCM e exatamente como isso corrigiu o problema se alguém tiver informações mais detalhadas.
fonte