Notamos que nuestras Reglas de implementación automática para actualizaciones de software no pudieron descargar y aplicar automáticamente los parches de este mes de Microsoft, aunque están correctamente enumerados en el Catálogo.
Las Reglas de implementación automática enumeran su Código de último error como 0X87D20417
y la Descripción del último error como "Error en la descarga de la regla de implementación automática". Volver a ejecutar las reglas reproduce manualmente este error. Eliminar y volver a crear las Reglas de implementación automática también reproduce el mismo error.
Al mirar el registro de SMS_RULE_ENGINE se muestran los siguientes errores:
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.
Si miro a través de ruleengine.log (que presumiblemente es el archivo de registro desde el que se genera el registro de SMS_RULE_ENGINE de nivel superior dentro de SCCM) y coordino el ID de paquete para los paquetes de implementación relevantes en los que se supone que las Reglas de implementación automática colocan estas actualizaciones en I encuentra el siguiente:
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)
En este punto, tengo tres errores diferentes que creo que todos son generados por el mismo evento. Por supuesto, pueden no serlo, por eso están todos incluidos aquí. Coordiné los tiempos en los archivos de registro y estoy razonablemente seguro de que todos están relacionados con el problema con las Reglas de implementación automática.
0X87D20417
- De las reglas de implementación automática de la consola SCCM8706
- Desde el registro de SMS_RULE_ENGINE de monitoreo de la consola de SCCMError code = 4115
- Desde los registros del servidor del sitio SCCM desde [SCCMInstallationPath] \ Logs \ ruleengine.log
Parece que no podemos descargar esas actualizaciones. Aparentemente, el lugar para solucionar este tipo de cosas es PatchDownloader.log . Y 'lo que hay todavía otro error registrado allí:
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)
Puedo coordinar las ID de contenido en PatchDownloader.log de nuevo a las Error: 4115
entradas registradas en ruleengine.log, así que, como se mencionó anteriormente, estoy bastante seguro de que estábamos viendo el mismo evento que genera todos estos errores diferentes, pero si alguien sabe mejor, por favor corrígeme.
Si uso la herramienta de búsqueda de errores de CMTrace, me dice lo siguiente sobre hr = 0x80041013
.
Provider load failure
Source: Windows Management (WMI)
-----
Y, efectivamente, si miro el espacio de nombres WMI al que se está conectando el Actualizador de actualizaciones de software, no se ve muy bien:
\ SCCM.ad.example.com \ root \ sms \ site_REV
Nuestro Código de sitio es en realidad 004
y curiosamente las primeras tres letras de nuestra organización comienzan con REV. Poderosa coincidencia si me preguntas. Además, esta no es la primera instalación de SCCM que existió aquí y resulta que el SCCM 2007 anterior tenía los límites, colecciones y paquetes existentes migrados a nuestra nueva instalación. ¿Pistola humeante? No exactamente. También utilizó un código de sitio diferente. ¿Quizás el código del sitio REV se utilizó para una instalación de prueba temporal de SCCM 2012? Talvez no. El conocimiento institucional no tiene ningún registro de REV
ello y de la migración que realizamos antes de que me contrataran.
Sin embargo, nuestro antiguo PatchDownloader.log de la instancia de SCCM 2007 muestra el Descargador de parches de actualizaciones de software que se conecta al site_$SITECODE
espacio de nombres WMI. Desafortunadamente, no tengo registros de nuestra instalación actual de 2012 desde mayo, donde podría confirmar que se hace referencia al espacio de nombres WMI correcto.
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)
OKAY. Realmente parece un problema con los espacios de nombres WMI. En algún lugar en las profundidades de SCCM, algo le está diciendo al Software Updates Patch Downloader que se conecte en \\SCCM.ad.example.com\root\sms\site_REV
lugar de \\SCCM.ad.example.com\root\sms\site_004
.
En un WAG, verifiqué las tablas probables en la base de datos SQL en busca de referencias en REV
vano.
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 aún más las cosas, estoy viendo múltiples explicaciones del 0x80041013
error.
Los consejos de solución de problemas de WMI dicen que es un error cargar un proveedor de WMI:
WBEM_E_PROVIDER_LOAD_FAILURE - 0x80041013
Las clases de resolución de problemas de eventos de proveedores son un gran recurso, pero pueden ser un poco abrumadoras. La clase MSFT_WmiProvider_LoadOperationFailureEvent es una que he encontrado útil con bastante frecuencia. La mayoría de las fallas de carga de proveedores que he encontrado han sido el resultado de un registro de componentes incorrecto (ya sea en el registro o WMI), o permisos relacionados.
Mientras que las constantes de error de WMI de MSDN dicen que es un problema de permisos:
WBEM_E_ACCESS_DENIED 2147749891 (0x80041003) El usuario actual no tiene permiso para realizar la acción.
La única otra información que pude encontrar sobre el 0x80041013
error fue un compañero que publicó en TechNet que parece haber tenido el mismo problema que yo, incluso hasta el problema en el que tenía una instalación previa de SCCM a cuyo espacio de nombres WMI se estaba haciendo referencia erróneamente ( por ejemplo, en site_REV
lugar de site_004
). Terminó destruyendo todo el espacio de nombres WMI, así como las partes de SMS_ProviderLocation. No estoy seguro de querer hacer eso.
En este punto, ha sido un día largo, necesitamos reparar estos servidores y me duele la cabeza. ¿Algún consejo?
Respuestas:
Esta corazonada era correcta. Conocí a mi predecesor y aparentemente el primer intento fallido de migrar de SCCM 2007 a SCCM 2010 utilizó el
REV
código del sitio. Cómo logró permanecer inactivo en WMI todo este tiempo y por qué se "activó" es un completo misterio para mí.Muy cuidadosamente volví a leer la solución en esta publicación de TechNet que aconsejaba eliminar los espacios de nombres antiguos y decidí intentarlo. Dudo en marcar esto como una respuesta a pesar de que resolvió este problema, indica que implícitamente lo apruebo, especialmente porque no pude conseguir que nadie "oficial" en Microsoft confirmara si este era un enfoque seguro o no. o cuáles fueron las consecuencias de hacer esto. Dicho esto, asegúrese de tener copias de seguridad completas de su servidor SCCM o al menos un conocimiento mucho más íntimo de WMI antes de continuar. Podrías romper todo fácilmente haciendo esto, especialmente si, como yo, no estás familiarizado con WMI y con qué profundidad lo aprovecha SCCM.
Utilicé wbemtest para conectarme al
root\sms
espacio de nombres en nuestro servidor SCCM. Desde allí utilicé el botón [Enum_Instances ...] y busqué__NAMESPACE
como la superclase. Eliminé la entrada para elREV
código del sitio. Luego hice las mismas Enum_Instances para laSMS_ProviderLocation
superclase y eliminé el antiguo código del sitio de ese espacio de nombres. Volver a ejecutar las Reglas de implementación automáticas y revisarlasPatchDownloader.log
mostró la descarga exitosa de cada Actualización de Windows.Agradecería mucho más información sobre cómo SCCM utiliza estos espacios de nombres y cómo esto solucionó el problema si alguien tiene información más detallada.
fuente