Descrizione della messaggistica di stato in Configuration Manager
Questo articolo descrive il sistema di messaggistica dello 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, invece, consentono agli amministratori di tenere traccia del flusso di lavoro dei dati tramite vari componenti Configuration Manager.
Un visualizzatore di messaggi di stato viene incorporato direttamente nella console in modo che i messaggi di stato possano essere visualizzati e registrati. Non esiste un visualizzatore equivalente per i messaggi di stato. Il risultato dei messaggi di stato è visibile in:
- Rapporti
- diversi 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 dell'accesso alla rete
I dati di aggiornamento software critici si basano sul sistema di messaggistica dello stato in Configuration Manager. La comprensione della messaggistica di stato diventerà ancora più importante nelle versioni future di Configuration Manager man mano che 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 al sistema.
Quando vengono ricevuti i messaggi di stato, si verificano due cose:
- 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 si trova e ha come destinazione i messaggi di stato. I messaggi di stato relativi all'installazione client vengono inoltrati al punto di stato di fallback (FSP) (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 Mp Relay e inseriti nella auth\statesys.box\incoming cartella nel server del sito. Vengono quindi elaborati nel database per completare il flusso di lavoro.
Scavare più a fondo
È necessario assicurarsi che la registrazione dettagliata sia abilitata per:
- il client
- punto di gestione
- i componenti di messaggistica dello stato nel server del sito
Per impostare la registrazione dettagliata o di debug in un client o un punto di gestione 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 |
Abilitato | 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 la traccia dei comandi SQL è necessario che la traccia SQL sia abilitata per Configuration Manager componenti. Ma non è possibile ottenere dati molto utili 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 quadro chiaro di ciò che si verifica 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 dei log, il tipo di argomento sembra essere già stato interpretato.
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 consente di determinare cosa è necessario. 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 interpretarle.
Il grafico seguente consente di interpretare la combinazione di TopicType e StateID di ottenere dati significativi.
select * from v_StateNames
Nota
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 | Rilevato conflitto |
| 301 | 0 | Stato di imposizione sconosciuto |
| 301 | 1 | Installazione di 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 di aggiornamenti |
| 301 | 8 | Aggiornamenti scaricati |
| 301 | 9 | Impossibile scaricare gli aggiornamenti |
| 301 | 10 | 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 | Rilevato |
| 401 | 0 | Stato di conformità sconosciuto |
| 401 | 1 | Conforme |
| 401 | 2 | Non conforme |
| 401 | 3 | Rilevato conflitto |
| 401 | 4 | Error |
| 401 | 5 | Non applicabile |
| 401 | 6 | Non rilevato |
| 401 | 7 | Enforced |
| 402 | 0 | Stato di imposizione sconosciuto |
| 402 | 1 | Imposizione avviata |
| 402 | 2 | Imposizione in attesa di contenuto |
| 402 | 3 | In attesa del completamento di un'altra installazione |
| 402 | 4 | Attesa della finestra di manutenzione prima dell'installazione |
| 402 | 5 | Riavvio necessario 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 | 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 sospeso |
| 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 verde). Indica chiaramente che i due log fanno riferimento allo stesso messaggio di stato. L'oggetto TopicType viene visualizzato in testo azzurro. Si noti che un log potrebbe mostrare il numero effettivo che può essere interpretato dal grafico dati di messaggistica dello stato . L'altro potrebbe mostrare un valore generico (già interpretato).
L'ID messaggio di stato (StateId) viene visualizzato in testo viola.
Combinando l'ID TopicType messaggio di stato e (StateId) del 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
- Il risultato della valutazione
- Aggiornamento da scaricare
- Aggiornamento in corso di installazione
- Riavvio del sistema in sospeso
Si tratta solo di un esempio di come i messaggi di stato vengono inviati nel sistema di stato.
Flusso di dati di messaggistica dello stato
L'immagine seguente è un esempio effettivo di come i dati di messaggistica di stato si distongano verso il punto di gestione e vengano elaborati nel database.
Questo esempio usa 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 presenti 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 di eventuali messaggi di stato mancanti dal sistema. È importante perché i messaggi di stato mancanti possono causare report sullo stato incompleti o non accurati.
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, verranno visualizzati 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 monitorarne lo stato 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 diverse posizioni. Usa l'SDK Configuration Manager per fare in modo che il client invii 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 eseguita richiede la versione a 32 bit di cscript che deve essere esaurita dalla cartella syswow64.
Quando si verifica il successivo ciclo di polling dei messaggi di stato, tutti i messaggi di stato vengono inviati al punto di gestione.
Nel file Statemessage.log è possibile notare 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 devono essere simili all'esempio seguente:
<! [LOG[StateMessage body: <?xml version="1.0" encoding="UTF-16"?>
<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 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[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">
Nota
Questo esempio viene troncato in 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 vedere che CCMMessaging esegue questa operazione. C'è di più che vanno avanti 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 all'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: corpo del messaggio di elaborazione
Inoltro: FileType= SMX
Inoltro: casella di posta in uscita: C:\Programmi (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
Inoltro: 0 allegati ricevuti
Inoltro: 0 di 0 allegati elaborati correttamente
Inv-Relay: attività 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, ad esempio blocco note, per visualizzare i dettagli. Tuttavia, la formattazione del file potrebbe 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, in combinazione con il valore univoco di ID messaggio di stato .
Nota
Se si rinominano questi file, copiarli in un'altra cartella 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 in modo simile all'esempio seguente:
Sono stati trovati nuovi messaggi di stato da elaborare, avvio del 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. da SMW" a site_name del sito padre.
CMessageProcessor : 1 file di messaggi elaborati in questo batch, con 0 file non validi.
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 fornisce un suggerimento su ciò che accade dietro le quinte, ma non completamente. Diverse stored procedure SQL sono responsabili dell'elaborazione dei messaggi di stato. Inoltre, diverse tabelle nel database archivia i dati di messaggistica dello stato. Le stored procedure che eseminano messaggi di stato iniziano in genere con il nome spProcess. Esistono molte di queste procedure.
Il server del sito tiene traccia dei messaggi di stato all'arrivo, in modo che possa contrassegnare eventuali messaggi mancanti e richiedere periodicamente una risincronizzazione quando necessario. I messaggi di stato sono importanti. Non vuoi perderne nessuna.
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, tali 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 i dati vengano visualizzati nella tabella . 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 STATE_MESSAGE_SYSTEM
| Nome | Valore1 | Valore2 | Valore3 |
|---|---|---|---|
| Intervallo msg heartbeat | 60 | ||
| Intervallo di polling della posta in arrivo | 900 | ||
| Dimensioni blocco caricatore | 256 | ||
| Thread del caricatore | 4 | ||
| Max Chunks Fetched | 100 | ||
| Età minima del messaggio mancante | 2880 | ||
| Risincronizzazione intervallo controllo | 15 | ||
| Rieseguire la configurazione | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Nota
- Risincronizzazione intervallo controllo è impostato su 60 minuti. Questa è la pianificazione per il controllo dei sistemi che richiedono la risincronizzazione dei messaggi di stato.
- La durata minima dei messaggi mancanti è impostata su 2880. Per quanto tempo un messaggio deve essere mancante prima che venga richiesta una risincronizzazione.