Descrição do sistema de mensagens de estado no Configuration Manager
Este artigo descreve o sistema de mensagens de estado no Configuration Manager.
Versão original do produto: Configuration Manager (branch atual)
Número original do KB: 4459394
Noções básicas sobre mensagens de estado
As mensagens de estado no Configuration Manager são 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 rastrear o fluxo de trabalho de dados por meio de vários componentes do Configuration Manager.
Um visualizador de mensagens de status é integrado diretamente ao console para que as mensagens de status possam ser visualizadas 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
Os dados críticos de atualização de software dependem do sistema de mensagens de estado no Configuration Manager. Compreender as mensagens de estado se tornará ainda mais importante em versões futuras do Configuration Manager à medida que mais componentes aproveitarem isso.
O diagrama a seguir fornece uma boa descrição de como funciona o sistema de mensagens de estado.
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 extrai o WMI em um ciclo de 15 minutos (padrão) para todas as mensagens de estado que não foram enviadas e, em seguida, as encaminha para o ponto de gerenciamento. O período do ciclo pode ser alterado.
No diagrama, a peça de instalação do cliente é mostrada separadamente para maior 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 alcançado.
- 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 MP Relay 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.
Aprofundando-se
Temos que garantir que o log detalhado esteja habilitado para:
- O cliente
- O ponto de gerenciamento
- Os componentes de mensagens de estado no servidor do site
Para definir o log detalhado ou de depuração em um cliente ou ponto de gerenciamento do Configuration Manager, edite ou crie as seguintes entradas do Registro:
| Subchave do Registro | Nome DWORD | Dados do 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 do Registro para habilitar o log detalhado e reinicie o SMS_Executive serviço (ou o componente do sistema de estado):
| Subchave do Registro | Nome DWORD | Dados do valor |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
Registro detalhado | 1 |
O rastreamento de comandos SQL requer que o rastreamento SQL esteja habilitado para componentes do Configuration Manager. Mas não é possível obter muitos dados úteis diretamente do rastreamento. É verdade mesmo se o Profiler estiver 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 da mensagem de estado. A mensagem de estado em si consiste em várias partes, incluindo Tipo de Tópico e ID da Mensagem de Estado. Em alguns locais nos logs, o Tipo de Tópico parece já ter sido interpretado para você.
Você nem sempre verá o Tipo de Tópico e a ID da 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á-las.
O gráfico a seguir pode ajudá-lo a interpretar a combinação e TopicType StateID a 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
| Tipo de tópico | StateID | StateName |
|---|---|---|
| 300 | 0 | Estado de conformidade desconhecido |
| 300 | 1 | Em conformidade |
| 300 | 2 | Sem conformidade |
| 300 | 3 | Conflito detectado |
| 301 | 0 | Estado de aplicação desconhecido |
| 301 | 1 | Instalando atualizações(ões) |
| 301 | 2 | Aguardando reinicialização |
| 301 | 3 | Aguardando a conclusão de outra instalação |
| 301 | 4 | Atualizações(ões) instalada(s) com êxito |
| 301 | 5 | Reinicialização pendente do sistema |
| 301 | 6 | Falha ao instalar as atualizações |
| 301 | 7 | Baixando atualizações(ões) |
| 301 | 8 | Atualização(ões) baixada(s) |
| 301 | 9 | Falha ao baixar as atualizações |
| 301 | 10 | Aguardando a janela de manutenção antes de instalar |
| 301 | 11 | Aguardando que o orquestrador de terceiros inicie 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 | Detecção |
| 401 | 0 | Estado de conformidade desconhecido |
| 401 | 1 | Em conformidade |
| 401 | 2 | Sem conformidade |
| 401 | 3 | Conflito detectado |
| 401 | 4 | Erro |
| 401 | 5 | Não aplicável |
| 401 | 6 | Não Detectado |
| 401 | 7 | Imposto |
| 402 | 0 | Estado de aplicação desconhecido |
| 402 | 1 | Execução iniciada |
| 402 | 2 | Imposição aguardando conteúdo |
| 402 | 3 | Aguardando a conclusão de outra instalação |
| 402 | 4 | Aguardando a janela de manutenção antes de instalar |
| 402 | 5 | Reinicialização necessária 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 | Baixando 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 digitalizaçã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 nova tentativa |
| 501 | 5 | Falha na verificação |
| 501 | 6 | Verificação concluída com erros |
Para obter mais informações, consulte Mensagens de estado no Configuration Manager.
O exemplo a seguir alinha e compara os arquivos Updatesdeployment.log e Statemessage.log. Certifique-se de que os logs se refiram à mesma mensagem de estado alinhando a mesma 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 de estado. O outro pode mostrar um valor genérico (já interpretado). O ID da mensagem de estado (StateId) é mostrado em texto roxo.
Ao combinar o ID da mensagem de estado eStateId (TopicType) do gráfico, você pode acompanhar exatamente o que está ocorrendo nos logs. Neste exemplo, esses exemplos de código mostram as seguintes informações:
- Avaliação de atualizaçã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 chegam ao 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 extrair o 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 sondagem.
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 alguma mensagem 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 da classe, você pode encontrar todas as mensagens de estado que são registradas.
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 de ressincronização 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()
Este script pode ser encontrado na web em vários locais. Ele usa o SDK do Configuration Manager para fazer com que o cliente reenvie seus dados para o ponto de gerenciamento.
Normalmente, um script do Visual Basic (VBScript) é executado usando cscripto . Observe que o script pode falhar se você tentar executá-lo sozinho. O problema é que o Configuration Manager é um aplicativo de 32 bits em execução em um servidor de 64 bits. A versão padrão do 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 cscript de 32 bits que você deve executar na pasta syswow64.
Quando ocorre o próximo ciclo de sondagem de mensagens de estado, 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 extraídas, formatadas em XML e, em seguida, enviadas para o ponto de gerenciamento. As informações da mensagem de estado devem ser semelhantes ao exemplo a seguir:
<! [LOG[StateMessage body: <?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>
<ReportType>Full</ReportType><Data>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="hora" data="data" 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="hora" data="data" 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 expedidas 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 coisas acontecendo nos bastidores neste momento. No entanto, basta saber que CCMMessaging envia os dados para o ponto de gerenciamento (neste caso, o MP_Relay componente).
<! [LOG[OutgoingMessage(Queue='mp_mp_relayendpoint', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): Entregue com êxito ao host 'host_name'.]LOG]!>
Quando os dados chegam para processamento no MP_Relay, eles são processados e traduzidos para o .smx formato de arquivo e, em seguida, colocados na auth\statesys.box\incoming pasta.
Tarefa Inv-Relay: Processando o corpo da mensagem
Retransmissão: FileType= SMX
Retransmissão: Diretório da caixa de saída: C: \ Arquivos de programas (x86) \ Microsoft Configuration Manager \ inboxes \ auth \ statesys.box \ incoming
Relé: Recebeu 0 anexos
Retransmissão: 0 de 0 anexos processados com sucesso
Inv-Relay: Tarefa concluída com sucesso
auth\statesys.box\incoming Na pasta, você pode ver os .smx arquivos que estão sendo processados. Normalmente, você não os verá aqui. Mas se os arquivos permanecerem nessa 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 nome do arquivo seja file_name.smx.xml e, em seguida, clicar duas vezes no novo nome do arquivo, o arquivo XML será aberto no Internet Explorer e será muito mais fácil de ler.
A imagem a seguir é um exemplo de um arquivo XML aberto no 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 não afetar 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 exemplo a seguir:
Encontradas novas mensagens de estado para processar, iniciando o thread de processamento
Thread "Tópico de processamento de mensagens de estado #0" id:5076 iniciado
CMessageProcessor - Site pai detectado 'site_name'
CMessageProcessor - Arquivo de processamento: mdlbp169. SMW
CMessageProcessor - Processou 1 registros com 0 registros inválidos.
CMessageProcessor - Arquivo replicado com sucesso "mdlbp169. SMW" para o site pai site_name.
CMessageProcessor - Processou 1 arquivo de mensagem neste lote, com 0 arquivos inválidos.
Thread "Thread de processamento de mensagens de estado #0" id:5076 encerrado normalmente
O componente de processamento do banco de dados pode ser tornado visível habilitando o rastreamento SQL, mas isso 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 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. Existem muitos desses procedimentos.
O servidor do site rastreia as mensagens de estado à medida que elas chegam, para que possa sinalizar quaisquer mensagens ausentes e solicitar periodicamente uma nova sincronização quando necessário. As 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 ausente na SR_MissingMessageRanges tabela. Idealmente, esta tabela estará vazia. No entanto, na produção, você pode ver dados na tabela. Esta tabela ajuda a rastrear mensagens de estado que exigem uma ressincronização.
O arquivo de controle do site está localizado no banco de dados. Para obter as configurações específicas do 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))
Configurações STATE_MESSAGE_SYSTEM
| Nome | Value1 | Value2 | Valor3 |
|---|---|---|---|
| Intervalo de Mensagem de Pulsação | 60 | ||
| Intervalo de sondagem da caixa de entrada | 900 | ||
| Tamanho do bloco do carregador | 256 | ||
| Roscas do carregador | 4 | ||
| Máximo de pedaços buscados | 100 | ||
| Idade mínima da mensagem ausente | 2880 | ||
| Intervalo de verificação de ressincronização | 15 | ||
| Repetir configuraçã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. Este é o agendamento para verificar sistemas que exigem ressincronizações de mensagens de estado.
- A Idade Mínima da Mensagem Ausente é definida como 2880. Este é o tempo que uma mensagem deve estar ausente antes que uma ressincronização seja solicitada.