Descrição das mensagens de estado no Configuration Manager
Este artigo descreve o sistema de mensagens de estado em Configuration Manager.
Versão original do produto: Configuration Manager (branch atual)
Número de KB original: 4459394
Entender mensagens de estado
O estado das mensagens no Configuration Manager é um mecanismo que reflete uma condição do cliente em um determinado momento. As mensagens de status, por outro lado, funcionam para ajudar os administradores a controlar o fluxo de trabalho de dados por meio de vários componentes Configuration Manager.
Um visualizador de mensagens status é inserido diretamente no console para que status mensagens possam ser exibidas e rastreadas. Não há visualizador equivalente para mensagens de estado. O resultado das mensagens de estado é visto em:
- Relatórios
- vários dados no console, como o número de sistemas que precisam ser atualizados
- logs do cliente
As mensagens de estado contêm informações concisas sobre as condições in loco no cliente. O sistema de mensagens de estado é usado por componentes específicos do Configuration Manager, incluindo:
- atualizações de software
- gerenciamento de configuração desejado
- proteção de acesso à rede
Dados críticos de atualização de software dependem do sistema de mensagens de estado em Configuration Manager. Entender as mensagens de estado se tornará ainda mais importante em versões futuras de Configuration Manager à medida que mais componentes se aproveitam dela.
O diagrama a seguir fornece uma boa descrição de como o sistema de mensagens de estado funciona.
A caixa verde representa o sistema de mensagens de estado. Os componentes dentro da caixa são componentes que alimentam informações para o sistema.
Quando as mensagens de estado são recebidas, duas coisas ocorrem:
- As mensagens de estado são armazenadas no provedor WMI (Instrumentação de Gerenciamento do Windows).
- O sistema de estado raspa o WMI em um ciclo de 15 minutos (padrão) para quaisquer mensagens de estado que não foram enviadas e, em seguida, encaminha-as para o ponto de gerenciamento. O período de ciclo pode ser alterado.
No diagrama, a peça de instalação do cliente é mostrada separadamente para obter clareza. Durante a instalação do cliente, o ponto de gerenciamento é localizado e direcionado para mensagens de estado. As mensagens de estado sobre a instalação do cliente são encaminhadas para o FSP (ponto de status de fallback) (se estiver configurado) em uma das seguintes condições:
- O ponto de gerenciamento não foi atingido.
- O ponto de gerenciamento está inativo por algum motivo.
Para todo o resto, o tráfego vai diretamente para o ponto de gerenciamento.
As mensagens de estado que chegam ao ponto de gerenciamento são processadas nos .smx arquivos pelo componente de Retransmissão de MP e colocadas na auth\statesys.box\incoming pasta no servidor do site. Em seguida, eles são processados no banco de dados para concluir o fluxo de trabalho.
Cavando mais fundo
Temos que garantir que o log verboso esteja habilitado para:
- o cliente
- o ponto de gerenciamento
- os componentes de mensagens de estado no servidor do site
Para definir o log verboso ou depurado em um Configuration Manager cliente ou ponto de gerenciamento, edite ou crie as seguintes entradas de registro:
| Subchave do Registro | Nome DWORD | Dados de valor |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global |
Loglevel | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
Habilitado | Verdadeiro |
No servidor do site, edite a seguinte entrada de registro para habilitar o log verboso e reinicie o SMS_Executive serviço (ou o componente do sistema de estado):
| Subchave do Registro | Nome DWORD | Dados de valor |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
Log verboso | 1 |
O rastreamento de comandos SQL exige que o rastreamento de SQL esteja habilitado para Configuration Manager componentes. Mas poucos dados úteis podem ser obtidos diretamente do rastreamento. É verdade mesmo que o Profiler esteja habilitado. Portanto, examinaremos os arquivos Updatesdeployment.log e Statemessage.log no cliente. Ao interpretar as mensagens de estado nesses logs, podemos obter uma imagem clara do que está ocorrendo nas várias etapas do processo.
Antes de examinarmos exemplos de código de log, precisamos entender o formato de mensagem de estado. A mensagem de estado em si consiste em várias partes, incluindo Tipo de Tópico e ID de Mensagem de Estado. Em alguns locais nos logs, o Tipo de Tópico parece já ter sido interpretado para você.
Nem sempre você verá o Tipo de Tópico e a ID de Mensagem de Estado juntos no mesmo log. Um tipo de dados sem o outro realmente não ajuda a determinar o que é necessário. No entanto, mesmo que você tenha o Tipo de Tópico e a ID da Mensagem de Estado, as informações não serão úteis, a menos que você possa interpretá-la.
O gráfico a seguir pode ajudá-lo a interpretar a combinação de TopicType e StateID para obter dados significativos.
select * from v_StateNames
Observação
O gráfico a seguir inclui os códigos de tipo de tópico das séries 300, 400 e 500.
Dados de mensagens de estado
| TopicType | StateID | StateName |
|---|---|---|
| 300 | 0 | Estado de conformidade desconhecido |
| 300 | 1 | Compatível com |
| 300 | 2 | Não compatível |
| 300 | 3 | Conflito detectado |
| 301 | 0 | Estado de imposição desconhecido |
| 301 | 1 | Instalando atualizações |
| 301 | 2 | Aguardando reinicialização |
| 301 | 3 | Aguardando a conclusão de outra instalação |
| 301 | 4 | Atualizações instaladas com êxito |
| 301 | 5 | Reinicialização pendente do sistema |
| 301 | 6 | Falha ao instalar atualizações |
| 301 | 7 | Baixar atualizações |
| 301 | 8 | Atualizações baixadas |
| 301 | 9 | Falha ao baixar atualizações |
| 301 | 10 | Aguardando janela de manutenção antes de instalar |
| 301 | 11 | Aguardando o orquestrador de terceiros para iniciar a instalação |
| 302 | 0 | Estado de avaliação desconhecido |
| 302 | 1 | Avaliação ativada |
| 302 | 2 | Avaliação bem-sucedida |
| 302 | 3 | Falha na avaliação |
| 400 | 0 | Estado de detecção desconhecido |
| 400 | 1 | Não obrigatório |
| 400 | 2 | Não detectado |
| 400 | 3 | Detectado |
| 401 | 0 | Estado de conformidade desconhecido |
| 401 | 1 | Compatível com |
| 401 | 2 | Não compatível |
| 401 | 3 | Conflito detectado |
| 401 | 4 | Erro |
| 401 | 5 | Não aplicável |
| 401 | 6 | Não detectado |
| 401 | 7 | Enforced |
| 402 | 0 | Estado de imposição desconhecido |
| 402 | 1 | A imposição iniciada |
| 402 | 2 | Aplicação da aplicação aguardando conteúdo |
| 402 | 3 | Aguardando a conclusão de outra instalação |
| 402 | 4 | Aguardando janela de manutenção antes de instalar |
| 402 | 5 | Reiniciar necessário antes de instalar |
| 402 | 6 | Falha geral |
| 402 | 7 | Instalação pendente |
| 402 | 8 | Instalando atualização |
| 402 | 9 | Reinicialização pendente do sistema |
| 402 | 10 | Atualização instalada com êxito |
| 402 | 11 | Falha ao instalar a atualização |
| 402 | 12 | Baixar atualização |
| 402 | 13 | Atualização baixada |
| 402 | 14 | Falha ao baixar a atualização |
| 500 | 0 | Estado de detecção desconhecido |
| 500 | 1 | A atualização não é necessária |
| 500 | 2 | A atualização é necessária |
| 500 | 3 | A atualização está instalada |
| 501 | 0 | Estado de verificação desconhecido |
| 501 | 1 | A verificação está aguardando o local do catálogo |
| 501 | 2 | A verificação está em execução |
| 501 | 3 | Verificação concluída |
| 501 | 4 | A verificação está pendente de repetição |
| 501 | 5 | Falha na verificação |
| 501 | 6 | Verificação concluída com erros |
Para obter mais informações, consulte Mensagens de estado em Configuration Manager.
O exemplo a seguir alinha e compara os arquivos Updatesdeployment.log e Statemessage.log. Verifique se os logs se referem à mesma mensagem de estado alinhando o mesmo TopicID (texto verde). Isso indica claramente que os dois logs estão se referindo à mesma mensagem de estado. O TopicType é mostrado em texto azul claro. Observe que um log pode mostrar o número real que pode ser interpretado no gráfico de dados de mensagens do Estado . O outro pode mostrar um valor genérico (já interpretado). A ID da Mensagem de Estado (StateId) é mostrada em texto roxo.
Combinando a TopicTypeID da Mensagem de Estado (StateId) do gráfico, você pode rastrear exatamente o que está ocorrendo nos logs. Neste exemplo, esses exemplos de código mostram as seguintes informações:
- Atualizar avaliação
- O resultado da avaliação
- A atualização que está sendo baixada
- A atualização que está sendo instalada
- Uma reinicialização pendente do sistema
É apenas um exemplo de como as mensagens de estado são enviadas para o sistema de estado.
Fluxo de dados de mensagens de estado
A imagem a seguir é um exemplo real de como os dados de mensagens de estado avançam para o ponto de gerenciamento e são processados no banco de dados.
Este exemplo usa um cliente de teste. Ele começa forçando o cliente a raspar a WMI para todas as informações de mensagens de estado e, em seguida, envia essas informações para o ponto de gerenciamento em seu próximo ciclo de votação.
No WMI, as mensagens de estado são armazenadas no root\ccm\statemsg namespace. Nesse namespace, há duas classes de interesse: CCM_StateMsg_SerialNum e CCM_StateMsg.
A CCM_StateMsg_SerialNum classe é usada para registrar o último número de série usado para uma mensagem de estado. Cada mensagem de estado tem um número de série exclusivo, semelhante ao inventário de hardware. Dessa forma, o servidor do site pode acompanhar se está faltando mensagens de estado do sistema. É importante porque mensagens de estado ausentes podem causar relatórios de estado incompletos ou imprecisos.
A CCM_StateMsg classe contém as próprias mensagens de estado. Na instância de classe, você pode encontrar todas as mensagens de estado gravadas.
Se você abrir uma dessas mensagens, encontrará os detalhes da mensagem de estado e alguns dados que discutimos anteriormente, conforme mostrado no exemplo a seguir.
Podemos reenviar os dados para o ponto de gerenciamento e acompanhar seu progresso usando os scripts ressíncronos a seguir.
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()
Esse script pode ser encontrado na Web em vários locais. Ele usa o SDK Configuration Manager para fazer com que o cliente reenvia seus dados para o ponto de gerenciamento.
Normalmente, um script do Visual Basic (VBScript) é executado usando cscript. Observe que o script pode falhar se você tentar executá-lo sozinho. O problema é que Configuration Manager é um aplicativo de 32 bits que está em execução em um servidor de 64 bits. A versão padrão de cscript é a versão de 64 bits e geralmente funciona bem com qualquer VBScript. No entanto, nesse caso, a chamada que está sendo feita requer a versão de 32 bits da cscript qual você deve ficar sem a pasta syswow64.
Quando o próximo ciclo de sondagem de mensagem de estado ocorrer, todas as mensagens de estado são enviadas para o ponto de gerenciamento.
No arquivo Statemessage.log, você pode ver que as informações da mensagem de estado são puxadas, formatadas em XML e enviadas para o ponto de gerenciamento. As informações de mensagem de estado devem se assemelhar ao seguinte exemplo:
<! [LOG[Corpo do StateMessage: <?xml version="1.0" encoding="UTF-16"?>
<Relatório><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>
<Data dadata<>/data do ReportType>Full</ReportType></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[Mensagens de Estado encaminhadas com êxito para o ponto de gerenciamento]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1527">
Observação
Este exemplo é truncado para uma única mensagem de estado devido ao tamanho do arquivo XML.
Embora o arquivo Statemessage.log registre que as mensagens são enviadas para o ponto de gerenciamento, o sistema de mensagens de estado não move dados para o ponto de gerenciamento. No exemplo a seguir, você pode ver que CCMMessaging faz essa operação. Há mais que acontecendo nos bastidores neste momento. No entanto, é suficiente saber que CCMMessaging envia os dados para o ponto de gerenciamento (nesse caso, o MP_Relay componente).
<! [LOG[OutgoingMessage(Queue='mp_mp_relayponto de extremidade', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): Entregue com êxito para hospedar 'host_name'.] LOG]!>
Quando os dados chegam para processamento em MP_Relay, eles são processados e traduzidos para o formato de .smx arquivo e, em seguida, colocados na auth\statesys.box\incoming pasta.
Tarefa Inv-Relay: Processamento do corpo da mensagem
Retransmissão: FileType= SMX
Retransmissão: dir outbox: C:\Arquivos de Programa (x86)\Microsoft Configuration Manager\caixas de entrada\auth\statesys.box\entrada
Retransmissão: Anexos recebidos 0
Retransmissão: 0 dos 0 anexos processados com êxito
Inv-Relay: Tarefa concluída com êxito
auth\statesys.box\incoming Na pasta, você pode ver os .smx arquivos sendo processados. Normalmente, você não os verá aqui. Mas se os arquivos permanecerem nesta pasta, você precisará investigar quais são as mensagens e por que elas não estão sendo processadas. Se você encontrar um .smx arquivo, poderá abri-lo usando um editor de texto, como o Bloco de Notas, para ver os detalhes. No entanto, a formatação do arquivo pode ser ilegível, como no exemplo a seguir:
Se você renomear o .smx arquivo adicionando a .xml extensão para que o arquivo seja nomeado file_name.smx.xml e clique duas vezes no novo nome do arquivo, o arquivo XML será aberto na Internet Explorer e é muito mais fácil de ler.
A imagem a seguir é um exemplo de um arquivo XML aberto na Internet Explorer. Os detalhes do computador e da mensagem de estado são realçados. Ele contém as informações que discutimos anteriormente, combinadas com o valor exclusivo da ID da Mensagem de Estado .
Observação
Se você renomear esses arquivos, primeiro copie-os para uma pasta diferente para que você não afete a pasta Statesys.box .
Por fim, as mensagens de estado devem ser processadas no banco de dados. No arquivo Statesys.log , você pode ver essas mensagens semelhantes ao seguinte exemplo:
Encontrou novas mensagens de estado a serem processadas, iniciando o processamento do thread
Thread "State Message Processing Thread #0" id:5076 started
CMessageProcessor – Site pai detectado 'site_name'
CMessageProcessor – Arquivo de processamento: mdlbp169. SMW
CMessageProcessor – Processado 1 registros com 0 registros inválidos.
CMessageProcessor – arquivo replicado com êxito "mdlbp169. SMW" para o site pai site_name.
CMessageProcessor – Processou 1 arquivos de mensagens neste lote, com 0 arquivos ruins.
Thread "State Message Processing Thread #0" id:5076 encerrado normalmente
O componente de processamento de banco de dados pode ficar visível habilitando o rastreamento de SQL, mas não ajuda muito. Em vez disso, devemos usar o criador de perfil SQL. O criador de perfil nos dá uma dica do que está ocorrendo nos bastidores, mas não completamente. Vários procedimentos armazenados do SQL são responsáveis pelo processamento de mensagens de estado. Além disso, várias tabelas no banco de dados armazenam os dados de mensagens de estado. Os procedimentos armazenados que fazem o processamento de mensagens de estado geralmente começam com o nome spProcess. Há muitos desses procedimentos.
O servidor do site rastreia mensagens de estado à medida que chegam, para que ele possa sinalizar qualquer mensagem ausente e solicitar periodicamente uma ressincronização quando necessário. Mensagens de estado são importantes. Você não quer perder nenhum.
À medida que as mensagens de estado chegam, a ID exclusiva é lida e armazenada no banco de dados. À medida que o processamento continua, os dados são atualizados regularmente. Se uma lacuna for detectada, esses dados serão sinalizados e armazenados como mensagens de estado ausentes na SR_MissingMessageRanges tabela. O ideal é que essa tabela fique vazia. No entanto, na produção, você pode ver dados na tabela. Esta tabela ajuda a controlar as mensagens de estado que exigem um ressincronização.
O arquivo de controle do site está localizado no banco de dados. Para obter as configurações específicas para STATE_MESSAGE_SYSTEM, execute a seguinte consulta em um site primário ou 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))
STATE_MESSAGE_SYSTEM configurações
| Nome | Valor1 | Value2 | Value3 |
|---|---|---|---|
| Intervalo de msg de pulsação | 60 | ||
| Intervalo de sondagem da caixa de entrada | 900 | ||
| Tamanho da parte do carregador | 256 | ||
| Threads do Carregador | 4 | ||
| Partes máximas buscadas | 100 | ||
| Min Missing Message Age | 2880 | ||
| Intervalo de verificação ressincronização | 15 | ||
| Configuração de repetição | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Observação
- O intervalo de verificação de ressincronização é definido como 60 minutos. Essa é a agenda para verificar sistemas que exigem ressincronizações de mensagem de estado.
- Min Missing Message Age está definido como 2880. Isso é quanto tempo uma mensagem deve estar ausente antes que um ressíncrono seja solicitado.