Condividi tramite


Descrizione della messaggistica di stato in Configuration Manager

Questo articolo descrive il sistema di messaggistica di stato in Configuration Manager.

Versione originale del prodotto: Configuration Manager (Current Branch)
Numero KB originale: 4459394

Informazioni sulla messaggistica di stato

La messaggistica di stato in Configuration Manager è un meccanismo che riflette una condizione client in un determinato momento. I messaggi di stato, al contrario, consentono agli amministratori di tenere traccia del flusso di lavoro dei dati tramite vari componenti di Configuration Manager.

Un visualizzatore messaggi di stato è integrato direttamente nella console in modo che i messaggi di stato possano essere visualizzati e monitorati. Non esiste un visualizzatore equivalente per i messaggi di stato. Il risultato dei messaggi di stato è visualizzato in:

  • report
  • vari dati nella console, ad esempio il numero di sistemi che devono essere aggiornati
  • log client

I messaggi di stato contengono informazioni concise sulle condizioni sul posto nel client. Il sistema di messaggistica di stato viene usato da componenti specifici di Configuration Manager, tra cui:

  • aggiornamenti software
  • gestione della configurazione desiderata
  • protezione dall'accesso alla rete

I dati di aggiornamento software critici si basano sul sistema di messaggistica di stato in Configuration Manager. La comprensione della messaggistica di stato diventerà ancora più importante nelle versioni future di Configuration Manager, poiché più componenti ne sfruttano i vantaggi.

Il diagramma seguente fornisce una buona descrizione del funzionamento del sistema di messaggistica di stato.

Diagramma che mostra il funzionamento del sistema di messaggistica di stato.

La casella verde rappresenta il sistema di messaggistica di stato. I componenti all'interno della casella sono componenti che alimentano le informazioni nel sistema.

Quando vengono ricevuti messaggi di stato, si verificano due elementi:

  1. I messaggi di stato vengono archiviati nel provider strumentazione gestione Windows (WMI).
  2. Il sistema di stato elimina WMI in un ciclo di 15 minuti (impostazione predefinita) per tutti i messaggi di stato che non sono stati inviati e quindi li inoltra al punto di gestione. Il periodo del ciclo può essere modificato.

Nel diagramma, la parte di installazione client viene visualizzata separatamente per maggiore chiarezza. Durante l'installazione del client, il punto di gestione viene individuato e destinato ai messaggi di stato. I messaggi di stato relativi all'installazione client vengono inoltrati al punto di stato di fallback (se configurato) in una delle condizioni seguenti:

  • Il punto di gestione non viene raggiunto.
  • Il punto di gestione è inattivo per qualche motivo.

Per tutto il resto, il traffico passa direttamente al punto di gestione.

I messaggi di stato che arrivano al punto di gestione vengono elaborati nei .smx file dal componente Inoltro MP e inseriti nella auth\statesys.box\incoming cartella nel server del sito. Vengono quindi elaborati nel database per completare il flusso di lavoro.

Eseguire un'analisi più approfondita

È necessario assicurarsi che la registrazione dettagliata sia abilitata per:

  • client
  • punto di gestione
  • componenti di messaggistica di stato nel server del sito

Per impostare la registrazione dettagliata o di debug in un client o in un punto di gestione di Configuration Manager, modificare o creare le voci del Registro di sistema seguenti:

Sottochiave del Registro di sistema Nome DWORD Dati valore
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global LogLevel 0
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging Attivata Vero

Nel server del sito modificare la voce del Registro di sistema seguente per abilitare la registrazione dettagliata e quindi riavviare il SMS_Executive servizio (o il componente del sistema di stato):

Sottochiave del Registro di sistema Nome DWORD Dati valore
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM Registrazione dettagliata 1

Per tracciare i comandi SQL è necessario che la traccia SQL sia abilitata per i componenti di Configuration Manager. Ma non molto utili dati possono essere ottenuti direttamente dalla traccia. È vero anche se Profiler è abilitato. Verranno quindi esaminati i file Updatesdeployment.log e Statemessage.log nel client. Interpretando i messaggi di stato in questi log, è possibile ottenere un'immagine chiara degli eventi che si verificano nei vari passaggi del processo.

Prima di esaminare gli esempi di codice di log, è necessario comprendere il formato del messaggio di stato. Il messaggio di stato è costituito da diverse parti, tra cui Tipo di argomento e ID messaggio di stato. In alcune posizioni nei log, il tipo di argomento sembra essere già interpretato per l'utente.

Il tipo di argomento e l'ID messaggio di stato non verranno sempre visualizzati insieme nello stesso log. Un tipo di dati senza l'altro non aiuta davvero a determinare le esigenze. Tuttavia, anche se si dispone sia del tipo di argomento che dell'ID messaggio di stato, le informazioni non sono utili a meno che non sia possibile interpretarlo.

Il grafico seguente consente di interpretare la combinazione di TopicType e StateID di ottenere dati significativi.

select * from v_StateNames  

Note

Il grafico seguente include i codici tipo di argomento serie 300, 400 e 500.

Dati di messaggistica di stato

TopicType StateID StateName
300 0 Stato di conformità sconosciuto
300 1 Conforme
300 2 Non conforme
300 3 Conflitto rilevato
301 0 Stato di imposizione sconosciuto
301 1 Installazione degli aggiornamenti
301 2 In attesa del riavvio
301 3 In attesa del completamento di un'altra installazione
301 4 Aggiornamenti installati correttamente
301 5 Riavvio del sistema in sospeso
301 6 Impossibile installare gli aggiornamenti
301 7 Download degli aggiornamenti
301 8 Aggiornamenti scaricati
301 9 Impossibile scaricare gli aggiornamenti
301 10 In attesa della finestra di manutenzione prima dell'installazione
301 11 In attesa che l'agente di orchestrazione di terze parti avvii l'installazione
302 0 Stato di valutazione sconosciuto
302 1 Valutazione attivata
302 2 Valutazione completata
302 3 Valutazione non riuscita
400 0 Stato di rilevamento sconosciuto
400 1 Non obbligatorio
400 2 Non rilevato
400 3 Rilevata
401 0 Stato di conformità sconosciuto
401 1 Conforme
401 2 Non conforme
401 3 Conflitto rilevato
401 4 Errore
401 5 Non applicabile
401 6 Non rilevato
401 7 Imposto
402 0 Stato di imposizione sconosciuto
402 1 Applicazione avviata
402 2 Imposizione in attesa del contenuto
402 3 In attesa del completamento di un'altra installazione
402 4 In attesa della finestra di manutenzione prima dell'installazione
402 5 Riavviare obbligatorio prima dell'installazione
402 6 Errore generale
402 7 Installazione in sospeso
402 8 Installazione dell'aggiornamento
402 9 Riavvio del sistema in sospeso
402 10 Aggiornamento installato correttamente
402 11 Impossibile installare l'aggiornamento
402 12 Download dell'aggiornamento
402 13 Aggiornamento scaricato
402 14 Impossibile scaricare l'aggiornamento
500 0 Stato di rilevamento sconosciuto
500 1 L'aggiornamento non è obbligatorio
500 2 L'aggiornamento è obbligatorio
500 3 L'aggiornamento è installato
501 0 Stato di analisi sconosciuto
501 1 L'analisi è in attesa della posizione del catalogo
501 2 L'analisi è in esecuzione
501 3 Analisi completata
501 4 L'analisi è in attesa di nuovi tentativi
501 5 Analisi non riuscita
501 6 Analisi completata con errori

Per altre informazioni, vedere Messaggi di stato in Configuration Manager.

Nell'esempio seguente vengono allineati e confrontati i file Updatesdeployment.log e Statemessage.log. Assicurarsi che i log facciano riferimento allo stesso messaggio di stato allineando lo stesso TopicID testo (testo verde). Indica chiaramente che i due log fanno riferimento allo stesso messaggio di stato. L'oggetto TopicType viene visualizzato in testo blu chiaro. Si noti che un log potrebbe mostrare il numero effettivo che può essere interpretato dal grafico dei dati di messaggistica di stato. L'altro potrebbe mostrare un valore generico (già interpretato). L'ID messaggio di stato (StateId) viene visualizzato nel testo viola.

Screenshot che mostra i dettagli dei messaggi di log.

Combinando l'ID messaggio di TopicType stato e (StateId) dal grafico, è possibile tenere traccia esattamente di ciò che si verifica nei log. In questo esempio, questi esempi di codice mostrano le informazioni seguenti:

  • Aggiornare la valutazione
  • Risultato della valutazione
  • Aggiornamento scaricato
  • Aggiornamento in fase di installazione
  • Riavvio del sistema in sospeso

È solo un esempio di come i messaggi di stato vengono inviati nel sistema di stato.

Flusso di dati di messaggistica stato

L'immagine seguente è un esempio effettivo del modo in cui i dati di messaggistica di stato consentono di raggiungere il punto di gestione e vengono elaborati nel database.

In questo esempio viene usato un client di test. Inizia forzando il client a raschiare WMI per tutte le informazioni di messaggistica di stato e quindi invia tali informazioni al punto di gestione nel ciclo di polling successivo.

In WMI i messaggi di stato vengono archiviati nello spazio dei root\ccm\statemsg nomi . In tale spazio dei nomi sono disponibili due classi di interesse: CCM_StateMsg_SerialNum e CCM_StateMsg.

La CCM_StateMsg_SerialNum classe viene usata per registrare l'ultimo numero di serie usato per un messaggio di stato. Ogni messaggio di stato ha un numero di serie univoco, simile all'inventario hardware. In questo modo, il server del sito può tenere traccia della mancanza di messaggi di stato dal sistema. È importante perché i messaggi di stato mancanti possono causare rapporti di stato incompleti o imprecisi.

Screenshot della classe CCM_StateMsg_SerialNum.

La CCM_StateMsg classe contiene i messaggi di stato stessi. Nell'istanza della classe è possibile trovare tutti i messaggi di stato registrati.

Screenshot dell'istanza di CCM_StateMsg.

Se si apre uno di questi messaggi, si troveranno i dettagli del messaggio di stato e alcuni dati illustrati in precedenza, come illustrato nell'esempio seguente.

Screenshot che mostra i dettagli del messaggio di stato.

È possibile inviare nuovamente i dati al punto di gestione e tenere traccia dello stato di avanzamento usando gli script di risincronizzazione seguenti.

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()

Questo script è disponibile sul Web in varie posizioni. Usa Configuration Manager SDK per fare in modo che il client restituisca nuovamente i dati al punto di gestione.

In genere, uno script di Visual Basic (VBScript) viene eseguito tramite cscript. Si noti che lo script potrebbe non riuscire se si tenta di eseguirlo manualmente. Il problema è che Configuration Manager è un'applicazione a 32 bit in esecuzione in un server a 64 bit. La versione predefinita di cscript è la versione a 64 bit e in genere funziona correttamente con qualsiasi VBScript. In questo caso, tuttavia, la chiamata effettuata richiede la versione a 32 bit di cscript che è necessario uscire dalla cartella syswow64.

Screenshot del prompt dei comandi dell'amministratore che esegue cscript.

Quando si verifica il ciclo di polling dei messaggi di stato successivo, tutti i messaggi di stato vengono inviati al punto di gestione.

Nel file Statemessage.log è possibile vedere che le informazioni sul messaggio di stato vengono estratte, formattate in XML e quindi inviate al punto di gestione. Le informazioni sul messaggio di stato dovrebbero essere simili all'esempio seguente:

<! [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</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[Messaggi di stato inoltrati correttamente al punto di gestione]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1527">

Note

In questo esempio viene troncato un singolo messaggio di stato a causa delle dimensioni del file XML.

Anche se il file Statemessage.log registra che i messaggi vengono inviati al punto di gestione, il sistema di messaggistica di stato non sposta effettivamente i dati nel punto di gestione. Nell'esempio seguente è possibile osservare che CCMMessaging esegue questa operazione. C'è di più che andare dietro le quinte a questo punto. Tuttavia, è sufficiente sapere che CCMMessaging invia i dati al punto di gestione (in questo caso, il MP_Relay componente).

<! [LOG[OutgoingMessage(Queue='mp_mp_relayendpoint', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): recapitato correttamente nell'host 'host_name'.]LOG]!>

Quando i dati arrivano per l'elaborazione in MP_Relay, vengono elaborati e convertiti nel .smx formato di file e quindi inseriti nella auth\statesys.box\incoming cartella .

Attività Inv-Relay: Elaborazione del corpo del messaggio
Inoltro: FileType= SMX
Inoltro: Outbox dir: C:\Programmi (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
Inoltro: 0 allegati ricevuti
Inoltro: 0 di 0 allegati elaborati correttamente
Inv-Relay: l'attività è stata completata correttamente

auth\statesys.box\incoming Nella cartella è possibile visualizzare i .smx file elaborati. In genere, non verranno visualizzati qui. Tuttavia, se i file rimangono in questa cartella, è necessario esaminare quali sono i messaggi e perché non vengono elaborati. Se si trova un .smx file, è possibile aprirlo usando un editor di testo come Blocco note per visualizzare i dettagli. Tuttavia, la formattazione del file può essere illeggibile, come nell'esempio seguente:

Screenshot di un file SMX di esempio nel Blocco note.

Se si rinomina il .smx file aggiungendo l'estensione .xml in modo che il file sia denominato file_name.smx.xml e quindi si fa doppio clic sul nuovo nome file, il file XML viene aperto in Internet Explorer ed è molto più facile da leggere.

L'immagine seguente è un esempio di file XML aperto in Internet Explorer. I dettagli del computer e del messaggio di stato sono evidenziati. Contiene le informazioni descritte in precedenza, combinate con il valore di ID messaggio di stato univoco.

Note

Se si rinominano questi file, copiarli prima in una cartella diversa in modo da non influire sulla cartella Statesys.box .

Screenshot di un file di esempio .smx.xml in Internet Explorer.

Infine, i messaggi di stato devono essere elaborati nel database. Nel file Statesys.log è possibile visualizzare tali messaggi simili all'esempio seguente:

Sono stati trovati nuovi messaggi di stato da elaborare, avviando il thread di elaborazione
Thread "State Message Processing Thread #0" id:5076 started
CMessageProcessor - Rilevato sito padre 'site_name'
CMessageProcessor - File di elaborazione: mdlbp169. SMW
CMessageProcessor: 1 record elaborati con 0 record non validi.
CMessageProcessor: file replicato correttamente "mdlbp169. SMW" al sito padre site_name.
CMessageProcessor: sono stati elaborati 1 file di messaggio in questo batch, con 0 file non valido.
Thread "State Message Processing Thread #0" id:5076 terminato normalmente

Il componente di elaborazione del database può essere reso visibile abilitando la traccia SQL, ma non è molto utile. È invece necessario usare il profiler SQL. Il profiler ci dà un suggerimento di ciò che si sta verificando dietro le quinte, ma non completamente. Diverse stored procedure SQL sono responsabili dell'elaborazione dei messaggi di stato. Inoltre, diverse tabelle nel database archiviano i dati di messaggistica di stato. Le stored procedure che eseguono l'elaborazione dei messaggi di stato iniziano in genere con il nome spProcess. Ci sono molte di queste procedure.

Il server del sito tiene traccia dei messaggi di stato quando arrivano, in modo che possa contrassegnare eventuali messaggi mancanti e richiedere periodicamente una risincronizzazione quando necessario. I messaggi di stato sono importanti. Non vuoi perderti niente.

Quando arrivano i messaggi di stato, l'ID univoco viene letto e archiviato nel database. Man mano che l'elaborazione continua, i dati vengono aggiornati regolarmente. Se viene rilevato un gap, i dati vengono contrassegnati e archiviati come messaggi di stato mancanti nella SR_MissingMessageRanges tabella. Idealmente, questa tabella sarà vuota. Tuttavia, nell'ambiente di produzione, è possibile che nella tabella vengano visualizzati i dati. Questa tabella consente di tenere traccia dei messaggi di stato che richiedono una risincronizzazione.

Il file di controllo del sito si trova nel database. Per ottenere le impostazioni specifiche per STATE_MESSAGE_SYSTEM, eseguire la query seguente in un sito primario 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))

impostazioni di STATE_MESSAGE_SYSTEM

Nome Value1 Value2 Value3
Intervallo messaggi heartbeat 60
Intervallo di polling posta in arrivo 900
Dimensioni blocco del caricatore 256
Thread del caricatore 4
Max Chunks Fetched 100
Min Missing Message Age 2880
Risincronizzazione dell'intervallo di controllo 15
Nuovo tentativo di configurazione REG_SZ <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> 0

Note

  • L'intervallo di controllo risincronizzazione è impostato su 60 minuti. Questa è la pianificazione per i sistemi di controllo che richiedono risincronizzazioni dei messaggi di stato.
  • Min Missing Message Age è impostato su 2880. Questo è il tempo per cui un messaggio deve essere mancante prima che venga richiesta una risincronizzazione.