Descripción de la mensajería de estado en Configuration Manager
En este artículo se describe el sistema de mensajería de estado de Configuration Manager.
Versión original del producto: Configuration Manager (rama actual)
Número de KB original: 4459394
Descripción de la mensajería de estado
La mensajería de estado en Configuration Manager es un mecanismo que refleja una condición de cliente en un momento dado. Los mensajes de estado, por el contrario, funcionan para ayudar a los administradores a realizar un seguimiento del flujo de trabajo de datos a través de varios componentes de Configuration Manager.
Un visor de mensajes de estado está integrado directamente en la consola para que se puedan ver y realizar un seguimiento de los mensajes de estado. No hay ningún visor equivalente para los mensajes de estado. El resultado de los mensajes de estado se ve en:
- reports
- varios datos de la consola, como el número de sistemas que se deben actualizar
- registros de cliente
Los mensajes de estado contienen información concisa sobre las condiciones en contexto en el cliente. El sistema de mensajería de estado lo usan componentes específicos de Configuration Manager, entre los que se incluyen:
- actualizaciones de software
- administración de configuración deseada
- protección de acceso a la red
Los datos críticos de actualización de software se basan en el sistema de mensajería de estado de Configuration Manager. Comprender la mensajería de estado será aún más importante en versiones futuras de Configuration Manager a medida que más componentes lo aprovechen.
En el diagrama siguiente se proporciona una buena descripción de cómo funciona el sistema de mensajería de estado.
El cuadro verde representa el sistema de mensajería de estado. Los componentes dentro del cuadro son componentes que alimentan información al sistema.
Cuando se reciben mensajes de estado, se producen dos cosas:
- Los mensajes de estado se almacenan en el proveedor de Instrumental de administración de Windows (WMI).
- El sistema de estado extrae WMI en un ciclo de 15 minutos (valor predeterminado) para los mensajes de estado que no se han enviado y, a continuación, los reenvía al punto de administración. Se puede cambiar el período de ciclo.
En el diagrama, la parte de instalación del cliente se muestra por separado para mayor claridad. Durante la instalación del cliente, el punto de administración se encuentra y se dirige a los mensajes de estado. Los mensajes de estado sobre la instalación del cliente se reenvieron al punto de estado de reserva (FSP) (si está configurado) en una de las condiciones siguientes:
- No se alcanza el punto de administración.
- El punto de administración está inactivo por alguna razón.
Para todo lo demás, el tráfico va directamente al punto de administración.
Los mensajes de estado que llegan al punto de administración se procesan en los .smx archivos mediante el componente mp Relay y se colocan en la auth\statesys.box\incoming carpeta del servidor de sitio. A continuación, se procesan en la base de datos para completar el flujo de trabajo.
Mayor profundidad
Tenemos que asegurarnos de que el registro detallado está habilitado para:
- el cliente
- el punto de administración
- componentes de mensajería de estado en el servidor de sitio
Para establecer el registro detallado o de depuración en un cliente o punto de administración de Configuration Manager, edite o cree las siguientes entradas del Registro:
| Subclave del Registro | Nombre DWORD | Datos del valor |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global |
LogLevel | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
Habilitado | Verdadero |
En el servidor de sitio, edite la siguiente entrada del Registro para habilitar el registro detallado y, a continuación, reinicie el SMS_Executive servicio (o el componente del sistema de estado):
| Subclave del Registro | Nombre DWORD | Datos del valor |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
Registro detallado | 1 |
El seguimiento de comandos SQL requiere que el seguimiento de SQL esté habilitado para los componentes de Configuration Manager. Pero no se pueden obtener datos muy útiles directamente desde el seguimiento. Es true incluso si Profiler está habilitado. Por lo tanto, examinaremos los archivos Updatesdeployment.log y Statemessage.log en el cliente. Al interpretar los mensajes de estado de estos registros, podemos obtener una imagen clara de lo que ocurre en los distintos pasos del proceso.
Antes de examinar los ejemplos de código de registro, tenemos que comprender el formato del mensaje de estado. El propio mensaje de estado consta de varias partes, incluidos el tipo de tema y el identificador de mensaje de estado. En algunas ubicaciones de los registros, el tipo de tema parece que ya se interpreta por usted.
No siempre verá el tipo de tema y el identificador de mensaje de estado juntos en el mismo registro. Un tipo de datos sin el otro no le ayuda a determinar lo que se necesita. Sin embargo, aunque tenga el tipo de tema y el identificador de mensaje de estado, la información no es útil a menos que pueda interpretarla.
El siguiente gráfico puede ayudarle a interpretar la combinación de TopicType y StateID para obtener datos significativos.
select * from v_StateNames
Nota:
El siguiente gráfico incluye los códigos de tipo de tema de la serie 300, 400 y 500.
Datos de mensajería de estado
| TopicType | StateID | StateName |
|---|---|---|
| 300 | 0 | Estado de cumplimiento desconocido |
| 300 | 1 | Compatible |
| 300 | 2 | Incompatible |
| 300 | 3 | Conflicto detectado |
| 301 | 0 | Estado de cumplimiento desconocido |
| 301 | 1 | Instalación de actualizaciones |
| 301 | 2 | Esperar al reinicio |
| 301 | 3 | Nota: Espera a que termine la instalación |
| 301 | 4 | Actualizaciones instaladas correctamente |
| 301 | 5 | Reinicio del sistema pendiente |
| 301 | 6 | No se pudieron instalar las actualizaciones |
| 301 | 7 | Descarga de actualizaciones |
| 301 | 8 | Actualizaciones descargadas |
| 301 | 9 | No se pudieron descargar las actualizaciones |
| 301 | 10 | Esperar a la ventana de mantenimiento antes de instalar |
| 301 | 11 | Esperar a que el orquestador de terceros inicie la instalación |
| 302 | 0 | Estado de evaluación desconocido |
| 302 | 1 | Evaluación activada |
| 302 | 2 | Evaluación correcta |
| 302 | 3 | Error de evaluación |
| 400 | 0 | Estado de detección desconocido |
| 400 | 1 | No necesario |
| 400 | 2 | No detectada |
| 400 | 3 | Detección |
| 401 | 0 | Estado de cumplimiento desconocido |
| 401 | 1 | Compatible |
| 401 | 2 | No compatible |
| 401 | 3 | Conflicto detectado |
| 401 | 4 | Error |
| 401 | 5 | No es aplicable |
| 401 | 6 | No detectada |
| 401 | 7 | Aplicado |
| 402 | 0 | Estado de cumplimiento desconocido |
| 402 | 1 | Aplicación iniciada |
| 402 | 2 | Aplicación de la espera de contenido |
| 402 | 3 | Nota: Espera a que termine la instalación |
| 402 | 4 | Esperar a la ventana de mantenimiento antes de instalar |
| 402 | 5 | Reinicio necesario antes de instalar |
| 402 | 6 | Error general |
| 402 | 7 | Instalación pendiente |
| 402 | 8 | Instalando actualización |
| 402 | 9 | Reinicio del sistema pendiente |
| 402 | 10 | Actualización instalada correctamente |
| 402 | 11 | Error al instalar las actualizaciones |
| 402 | 12 | Descarga de una actualización |
| 402 | 13 | Se ha descargado la actualización |
| 402 | 14 | No se pudo descargar la actualización |
| 500 | 0 | Estado de detección desconocido |
| 500 | 1 | La actualización no es necesaria |
| 500 | 2 | Se requiere la actualización |
| 500 | 3 | La actualización está instalada |
| 501 | 0 | Estado de examen desconocido |
| 501 | 1 | El examen está esperando la ubicación del catálogo |
| 501 | 2 | El examen se está ejecutando |
| 501 | 3 | Examen completado |
| 501 | 4 | El examen está pendiente de reintento |
| 501 | 5 | Error en el examen |
| 501 | 6 | Examen completado con errores |
Para obtener más información, consulte Mensajes de estado en Configuration Manager.
En el ejemplo siguiente se alinean y comparan los archivos Updatesdeployment.log y Statemessage.log. Asegúrese de que los registros hacen referencia al mismo mensaje de estado alineando el mismo TopicID (texto verde). Indica claramente que los dos registros hacen referencia al mismo mensaje de estado. TopicType se muestra en texto azul claro. Observe que un registro puede mostrar el número real que se puede interpretar en el gráfico de datos de mensajería de estado . El otro podría mostrar un valor genérico (ya interpretado). El identificador de mensaje de estado (StateId) se muestra en texto púrpura.
Al combinar el TopicType identificador de mensaje de estado (StateId) del gráfico, puede realizar un seguimiento de lo que ocurre exactamente en los registros. En este ejemplo, estos ejemplos de código muestran la siguiente información:
- Evaluación de actualizaciones
- Resultado de la evaluación
- La actualización que se está descargando
- Actualización que se va a instalar
- Reinicio pendiente del sistema
Es solo un ejemplo de cómo se envían los mensajes de estado al sistema de estado.
Flujo de datos de mensajería de estado
La imagen siguiente es un ejemplo real de cómo los datos de mensajería de estado hacen su camino al punto de administración y se procesan en la base de datos.
En este ejemplo se usa un cliente de prueba. Comienza obligando al cliente a extraer WMI para toda la información de mensajería de estado y, a continuación, envía esa información al punto de administración en su siguiente ciclo de sondeo.
En WMI, los mensajes de estado se almacenan en el root\ccm\statemsg espacio de nombres . En ese espacio de nombres, hay dos clases de interés: CCM_StateMsg_SerialNum y CCM_StateMsg.
La CCM_StateMsg_SerialNum clase se usa para registrar el último número de serie que se usa para un mensaje de estado. Cada mensaje de estado tiene un número de serie único, similar al inventario de hardware. De esta manera, el servidor de sitio puede realizar un seguimiento de si falta algún mensaje de estado del sistema. Es importante porque los mensajes de estado que faltan pueden provocar informes de estado incompletos o inexactos.
La CCM_StateMsg clase contiene los propios mensajes de estado. En la instancia de clase, puede encontrar todos los mensajes de estado que se registran.
Si abre uno de estos mensajes, encontrará los detalles del mensaje de estado y algunos datos que hemos descrito anteriormente, como se muestra en el ejemplo siguiente.
Podemos reenviar los datos al punto de administración y realizar un seguimiento de su progreso mediante los siguientes scripts de resincronización.
RefreshServerComplianceState()
Sub RefreshServerComplianceState()
dim newCCMUpdatesStore
set newCCMUpdatesStore = CreateObject ("Microsoft.CCM.UpdatesStore")
newCCMUpdatesStore.RefreshServerComplianceState
wscript.echo "Ran RefreshServerComplianceState."
End Sub
$UpdatesStore = New-Object -ComObject Microsoft.CCM.UpdatesStore
$UpdatesStore.RefreshServerComplianceState()
Este script se puede encontrar en la web en varias ubicaciones. Usa el SDK de Configuration Manager para hacer que el cliente vuelva a enviar sus datos al punto de administración.
Normalmente, un script de Visual Basic (VBScript) se ejecuta mediante cscript. Tenga en cuenta que el script puede producir un error si intenta ejecutarlo usted mismo. El problema es que Configuration Manager es una aplicación de 32 bits que se ejecuta en un servidor de 64 bits. La versión predeterminada de es la versión de cscript 64 bits y, por lo general, funciona bien con cualquier VBScript. Sin embargo, en este caso, la llamada que se realiza requiere la versión de 32 bits de cscript que debe ejecutarse fuera de la carpeta syswow64.
Cuando se produce el siguiente ciclo de sondeo de mensajes de estado, todos los mensajes de estado se envían al punto de administración.
En el archivo Statemessage.log, puede ver que la información del mensaje de estado se extrae, da formato a XML y, a continuación, se envía al punto de administración. La información del mensaje de estado debe ser similar al ejemplo siguiente:
<! [LOG[StateMessage body: <?xml version="1.0" encoding="UTF-16"?>
<Report><ReportHeader><Identification><Machine><ClientInstalled>1</ClientInstalled><ClientType>1</ClientType><ClientID>GUID:GUID</ClientID>
<ClientVersion>client_version_number</ClientVersion><NetBIOSName>name</NetBIOSName><CodePage>437</CodePage>
<SystemDefaultLCID>1033</SystemDefaultLCID></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent>
<ReportType Full</ReportType><>Date</Date><Version>>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="time" SerialNumber="serial_number"><Topic ID="21e49ac6-a273-4a61-9794-eb675bc743e5" Type="500" IDType="3"/><State ID="2" Criticality="0"/><UserParameters Flags="0" Count="1"><Param>102</Param></UserParameters></StateMessageserParameters></StateMessage></ReportBody></Report>
]LOG<![ LOG[CStateMsgManager::GetSignEncyptMode]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1820">
<! [LOG[Mensajes de estado reenviados correctamente al punto de administración]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1527">
Nota:
Este ejemplo se trunca en un único mensaje de estado debido al tamaño del archivo XML.
Aunque el Statemessage.log los registros de archivos que los mensajes se envían al punto de administración, el sistema de mensajería de estado no mueve realmente los datos al punto de administración. En el ejemplo siguiente, puede ver que CCMMessaging realiza esta operación. Hay más que pasar en segundo plano en este momento. Sin embargo, es suficiente saber que CCMMessaging envía los datos al punto de administración (en este caso, el MP_Relay componente).
<! [LOG[OutgoingMessage(Queue='mp_mp_relayendpoint', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): entregado correctamente para hospedar "host_name".]LOG]!>
Cuando llegan los datos para su procesamiento en MP_Relay, se procesan y traducen al .smx formato de archivo y, a continuación, se colocan en la auth\statesys.box\incoming carpeta .
Tarea Inv-Relay: Procesamiento del cuerpo del mensaje
Relay: FileType= SMX
Relay: dir de la bandeja de salida: C:\Archivos de programa (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
Retransmisión: se han recibido 0 datos adjuntos
Retransmisión: 0 de 0 datos adjuntos procesados correctamente
Inv-Relay: tarea completada correctamente
En la auth\statesys.box\incoming carpeta , puede ver los .smx archivos que se están procesando. Normalmente, no los verá aquí. Pero si los archivos permanecen en esta carpeta, debe investigar cuáles son los mensajes y por qué no se están procesando. Si encuentra un .smx archivo, puede abrirlo mediante un editor de texto como el Bloc de notas para ver los detalles. Sin embargo, el formato del archivo puede ser ilegible, como en el ejemplo siguiente:
Si cambia el nombre del .smx archivo agregando la .xml extensión para que el archivo se llame file_name.smx.xml y, a continuación, haga doble clic en el nuevo nombre de archivo, el archivo XML se abre en Internet Explorer y es mucho más fácil de leer.
La imagen siguiente es un ejemplo de un archivo XML abierto en Internet Explorer. Los detalles del equipo y el mensaje de estado están resaltados. Contiene la información que hemos descrito anteriormente, combinada con el valor de identificador de mensaje de estado único.
Nota:
Si cambia el nombre de estos archivos, cópielos primero en otra carpeta para que no afecte a la carpeta Statesys.box .
Por último, los mensajes de estado deben procesarse en la base de datos. En el archivo Statesys.log , puede ver estos mensajes similares al ejemplo siguiente:
Se encontraron nuevos mensajes de estado para procesar, iniciando el subproceso de procesamiento
Subproceso "Subproceso de procesamiento de mensajes de estado #0" id:5076 iniciado
CMessageProcessor: sitio primario detectado "site_name"
CMessageProcessor - Archivo de procesamiento: mdlbp169. SMW
CMessageProcessor: 1 registros procesados con 0 registros no válidos.
CMessageProcessor: archivo replicado correctamente "mdlbp169. SMW" al sitio primario site_name.
CMessageProcessor: se procesaron 1 archivos de mensaje en este lote, con 0 archivos incorrectos.
Subproceso "Subproceso de procesamiento de mensajes de estado #0" id:5076 terminado normalmente
El componente de procesamiento de la base de datos se puede hacer visible habilitando el seguimiento de SQL, pero no ayuda mucho. En su lugar, debemos usar el generador de perfiles de SQL. El generador de perfiles nos da una sugerencia de lo que ocurre en segundo plano, pero no por completo. Varios procedimientos almacenados de SQL son responsables del procesamiento de mensajes de estado. Además, varias tablas de la base de datos almacenan los datos de mensajería de estado. Los procedimientos almacenados que realizan el procesamiento de mensajes de estado generalmente comienzan por el nombre spProcess. Hay muchos de estos procedimientos.
El servidor de sitio realiza un seguimiento de los mensajes de estado a medida que llegan, por lo que puede marcar los mensajes que faltan y solicitar periódicamente una resincronización cuando sea necesario. Los mensajes de estado son importantes. No quieres perderte nada.
A medida que llegan los mensajes de estado, el identificador único se lee y almacena en la base de datos. A medida que continúa el procesamiento, los datos se actualizan periódicamente. Si se detecta una brecha, esos datos se marcan y almacenan como mensajes de estado que faltan en la SR_MissingMessageRanges tabla. Idealmente, esta tabla estará vacía. Sin embargo, en producción, es posible que vea datos en la tabla. Esta tabla ayuda a realizar un seguimiento de los mensajes de estado que requieren una resincronización.
El archivo de control de sitio se encuentra en la base de datos. Para obtener la configuración específica de STATE_MESSAGE_SYSTEM, ejecute la consulta siguiente en un sitio principal o CAS:
select * from SC_Component_Property where ComponentID in (select ID from SC_Component where ComponentName like 'SMS_STATE_SYSTEM') and sitenumber in (select SiteNumber from SC_SiteDefinition where Sitecode = (Select ThisSiteCode from SMSData))
configuración de STATE_MESSAGE_SYSTEM
| Nombre | Valor1 | Valor2 | Value3 |
|---|---|---|---|
| Intervalo de mensajes de latido | 60 | ||
| Intervalo de sondeo de bandeja de entrada | 900 | ||
| Tamaño del fragmento del cargador | 256 | ||
| Subprocesos del cargador | 4 | ||
| Número máximo de fragmentos capturados | 100 | ||
| Antigüedad mínima de mensajes que faltan | 2880 | ||
| Intervalo de comprobación de resincronización | 15 | ||
| Configuración de reintento | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Nota:
- El intervalo de comprobación de resincronización se establece en 60 minutos. Esta es la programación para comprobar los sistemas que requieren resincronizaciones de mensajes de estado.
- La antigüedad mínima del mensaje que falta se establece en 2880. Esto es cuánto tiempo debe faltar un mensaje antes de que se solicite una resincronización.