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.
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:
- I messaggi di stato vengono archiviati nel provider strumentazione gestione Windows (WMI).
- 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.
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.
La CCM_StateMsg
classe contiene i messaggi di stato stessi. Nell'istanza della classe è possibile trovare tutti i messaggi di stato registrati.
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.
È 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.
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:
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 .
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.