Descripción de la mensajería de estado en Configuration Manager
En este artículo se describe el sistema de mensajería de estado en 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. Por el contrario, los mensajes de estado funcionan para ayudar a los administradores a realizar un seguimiento del flujo de trabajo de los datos a través de varios componentes de Configuration Manager.
Un visor de mensajes de estado se integra 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:
- Informes
- varios datos de la consola, como el número de sistemas que deben actualizarse
- registros de cliente
Los mensajes de estado contienen información concisa sobre las condiciones en contexto en el cliente. Los componentes específicos de Configuration Manager usan el sistema de mensajería de estado, 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 en Configuration Manager. Comprender la mensajería de estado será aún más importante en futuras versiones de Configuration Manager a medida que más componentes se aprovechen de ella.
En el diagrama siguiente se proporciona una buena descripción del funcionamiento del 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. El período del ciclo se puede cambiar.
En el diagrama, la pieza 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 reenvía al punto de estado de reserva (FSP) (si está configurado) en una de las condiciones siguientes:
- No se ha alcanzado 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.
El componente MP Relay procesa los mensajes de estado que llegan al punto de administración en los .smx archivos 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.
Cavar más profundo
Debemos asegurarnos de que el registro detallado está habilitado para:
- el cliente
- el punto de administración
- los 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 Configuration Manager componentes. 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 en 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, debemos 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 interpretará 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 realmente no le ayuda a determinar lo que se necesita. Sin embargo, incluso si tiene 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 a obtener datos significativos.
select * from v_StateNames
Nota:
El siguiente gráfico incluye los códigos de tipo de tema de las series 300, 400 y 500.
Datos de mensajería de estado
| TopicType | StateID | StateName |
|---|---|---|
| 300 | 0 | Estado de cumplimiento desconocido |
| 300 | 1 | Compliant |
| 300 | 2 | No compatible |
| 300 | 3 | Conflicto detectado |
| 301 | 0 | Estado de cumplimiento desconocido |
| 301 | 1 | Instalación de actualizaciones |
| 301 | 2 | Esperando reinicio |
| 301 | 3 | Esperando a que se complete otra 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 | Esperando la ventana de mantenimiento antes de instalar |
| 301 | 11 | Esperando 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 detectado |
| 400 | 3 | Detectados |
| 401 | 0 | Estado de cumplimiento desconocido |
| 401 | 1 | Compliant |
| 401 | 2 | No compatible |
| 401 | 3 | Conflicto detectado |
| 401 | 4 | Error |
| 401 | 5 | No aplicable |
| 401 | 6 | No detectado |
| 401 | 7 | Enforced |
| 402 | 0 | Estado de cumplimiento desconocido |
| 402 | 1 | Cumplimiento iniciado |
| 402 | 2 | Cumplimiento en espera de contenido |
| 402 | 3 | Esperando a que se complete otra instalación |
| 402 | 4 | Esperando la ventana de mantenimiento antes de instalar |
| 402 | 5 | Reinicio necesario antes de la instalación |
| 402 | 6 | Error general |
| 402 | 7 | Instalación pendiente |
| 402 | 8 | Instalación de la actualización |
| 402 | 9 | Reinicio del sistema pendiente |
| 402 | 10 | Actualización instalada correctamente |
| 402 | 11 | No se pudo instalar la actualización |
| 402 | 12 | Descarga de la actualización |
| 402 | 13 | Actualización descargada |
| 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á a la espera de la ubicación del catálogo |
| 501 | 2 | Examen en ejecución |
| 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, vea 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. Se TopicType muestra en texto azul claro. Observe que un registro podría mostrar el número real que se puede interpretar desde el gráfico de datos de mensajería de estado . El otro puede 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:
- Actualización de la evaluación
- Resultado de la evaluación
- La actualización que se está descargando
- La actualización que se está instalando
- Un reinicio del sistema pendiente
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 se dirige 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 de 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 espacio de root\ccm\statemsg 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 la falta de mensajes de estado puede 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 se trataron anteriormente, como se muestra en el ejemplo siguiente.
Podemos volver a enviar 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 quedar sin 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, se 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-4a 61-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 archivo Statemessage.log registra 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 pasan en segundo plano en este momento. Sin embargo, basta con 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}): Se entrega correctamente para hospedar 'host_name'.] ¡LOG]!>
Cuando los datos llegan para su procesamiento en MP_Relay, se procesan y traducen al formato de .smx 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: Directorio de 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 procesan. 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 siguiente imagen es un ejemplo de un archivo XML abierto en Internet Explorer. Se resaltan los detalles del equipo y el mensaje de estado. 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 se deben procesar en la base de datos. En el archivo Statesys.log , puede ver mensajes similares al ejemplo siguiente:
Se encontraron nuevos mensajes de estado que procesar, iniciando el subproceso de procesamiento
Subproceso "Subproceso de procesamiento de mensajes de estado #0" id:5076 iniciado
CMessageProcessor: sitio primario "site_name" detectado
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.
El subproceso "State Message Processing Thread #0" id:5076 finalizó normalmente
El componente de procesamiento de 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 pista 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 con 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, los 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 siguiente consulta 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 | Value1 | Value2 | 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 | ||
| Min Missing Message Age | 2880 | ||
| Resincronización del intervalo de comprobación | 15 | ||
| Reintentar configuración | 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. Este es el tiempo que debe faltar un mensaje antes de solicitar una resincronización.