Description de la messagerie d’état dans Configuration Manager
Cet article décrit le système de messagerie d’état dans Configuration Manager.
Version du produit d’origine : Configuration Manager (Current Branch)
Numéro de base de connaissances d’origine : 4459394
Présentation de la messagerie d’état
La messagerie d’état dans Configuration Manager est un mécanisme qui reflète une condition cliente à un moment donné. Les messages d’état, en revanche, fonctionnent pour aider les administrateurs à suivre le flux de travail des données via différents composants Configuration Manager.
Une visionneuse de messages d’état est intégrée directement à la console afin que les messages d’état puissent être affichés et suivis. Il n’existe aucune visionneuse équivalente pour les messages d’état. Le résultat des messages d’état est affiché dans :
- reports
- diverses données dans la console, telles que le nombre de systèmes devant être mis à jour
- journaux du client
Les messages d’état contiennent des informations concises sur les conditions sur place sur le client. Le système de messagerie d’état est utilisé par des composants spécifiques de Configuration Manager, notamment :
- mises à jour logicielles
- gestion de la configuration souhaitée
- protection de l’accès réseau
Les données de mise à jour logicielle critique s’appuient sur le système de messagerie d’état dans Configuration Manager. Comprendre la messagerie d’état deviendra encore plus importante dans les futures versions de Configuration Manager, car d’autres composants en tireront parti.
Le diagramme suivant fournit une bonne description du fonctionnement du système de messagerie d’état.
La zone verte représente le système de messagerie d’état. Les composants à l’intérieur de la zone sont des composants qui alimentent les informations sur le système.
Lorsque les messages d’état sont reçus, deux choses se produisent :
- Les messages d’état sont stockés dans le fournisseur WMI (Windows Management Instrumentation).
- Le système d’état récupère WMI sur un cycle de 15 minutes (par défaut) pour tous les messages d’état qui n’ont pas été envoyés, puis les transfère au point de gestion. La période de cycle peut être modifiée.
Dans le diagramme, l’élément d’installation du client s’affiche séparément pour plus de clarté. Pendant l’installation du client, le point de gestion se trouve et cible pour les messages d’état. Les messages d’état relatifs à l’installation du client sont transférés au point d’état de secours (FSP) (s’il est configuré) dans l’une des conditions suivantes :
- Le point de gestion n’est pas atteint.
- Le point de gestion est en panne pour une raison quelconque.
Pour tout le reste, le trafic passe directement au point de gestion.
Les messages d’état qui arrivent au point de gestion sont traités dans les .smx fichiers par le composant MP Relay et placés dans le auth\statesys.box\incoming dossier sur le serveur de site. Ensuite, ils sont traités dans la base de données pour terminer le flux de travail.
Approfondir
Nous devons nous assurer que la journalisation détaillée est activée pour :
- le client
- le point de gestion
- composants de messagerie d’état sur le serveur de site
Pour définir la journalisation détaillée ou déboguer sur un client ou un point de gestion Configuration Manager, modifiez ou créez les entrées de Registre suivantes :
| Sous-clé de Registre | Nom DWORD | Données de valeur |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global |
LogLevel | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
Activé(e) | Vrai |
Sur le serveur de site, modifiez l’entrée de Registre suivante pour activer la journalisation détaillée, puis redémarrez le SMS_Executive service (ou le composant système d’état) :
| Sous-clé de Registre | Nom DWORD | Données de valeur |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
Journalisation détaillée | 1 |
Les commandes SQL de suivi nécessitent que le suivi SQL soit activé pour les composants Configuration Manager. Mais pas beaucoup de données utiles peuvent être obtenues directement à partir du suivi. Il est vrai même si Profiler est activé. Nous allons donc examiner les fichiers Updatesdeployment.log et Statemessage.log sur le client. En interprétant les messages d’état dans ces journaux, nous pouvons obtenir une image claire de ce qui se produit aux différentes étapes du processus.
Avant d’examiner les exemples de code de journal, nous devons comprendre le format de message d’état. Le message d’état se compose de plusieurs parties, notamment le type de rubrique et l’ID de message d’état. À certains emplacements dans les journaux, le type de rubrique semble déjà être interprété pour vous.
Vous ne verrez pas toujours le type de rubrique et l’ID de message d’état ensemble dans le même journal. Un type de données sans l’autre ne vous aide pas vraiment à déterminer ce qui est nécessaire. Toutefois, même si vous avez à la fois le type de rubrique et l’ID de message d’état, les informations ne sont pas utiles, sauf si vous pouvez l’interpréter.
Le graphique suivant peut vous aider à interpréter la combinaison et TopicType StateID à obtenir des données significatives.
select * from v_StateNames
Note
Le graphique suivant inclut les codes de type de rubrique de la série 300, 400 et 500.
Données de messagerie d’état
| TopicType | StateID | StateName |
|---|---|---|
| 300 | 0 | État de conformité inconnu |
| 300 | 1 | Conforme |
| 300 | 2 | Non conforme |
| 300 | 3 | Conflit détecté |
| 301 | 0 | État d’application inconnu |
| 301 | 1 | Installation des mises à jour |
| 301 | 2 | En attente de redémarrage |
| 301 | 3 | Attente de la fin d’une autre installation |
| 301 | 4 | Mises à jour correctement installées |
| 301 | 5 | Redémarrage du système en attente |
| 301 | 6 | Échec de l’installation des mises à jour |
| 301 | 7 | Téléchargement des mises à jour |
| 301 | 8 | Mises à jour téléchargées |
| 301 | 9 | Échec du téléchargement des mises à jour |
| 301 | 10 | Fenêtre de maintenance en attente avant l’installation |
| 301 | 11 | En attendant que l’orchestrateur tiers lance l’installation |
| 302 | 0 | État d’évaluation inconnu |
| 302 | 1 | Évaluation activée |
| 302 | 2 | L’évaluation a réussi |
| 302 | 3 | Échec de l’évaluation |
| 400 | 0 | État de détection inconnu |
| 400 | 1 | Facultatif |
| 400 | 2 | Non détectée |
| 400 | 3 | Détectée |
| 401 | 0 | État de conformité inconnu |
| 401 | 1 | Conforme |
| 401 | 2 | Non conforme |
| 401 | 3 | Conflit détecté |
| 401 | 4 | Error |
| 401 | 5 | Non applicable |
| 401 | 6 | Non détectée |
| 401 | 7 | Appliquée |
| 402 | 0 | État d’application inconnu |
| 402 | 1 | Mise en œuvre démarrée |
| 402 | 2 | Application en attente de contenu |
| 402 | 3 | Attente de la fin d’une autre installation |
| 402 | 4 | Fenêtre de maintenance en attente avant l’installation |
| 402 | 5 | Redémarrer requis avant l’installation |
| 402 | 6 | Échec général |
| 402 | 7 | Installation en attente |
| 402 | 8 | Installation de la mise à jour |
| 402 | 9 | Redémarrage du système en attente |
| 402 | 10 | Mise à jour installée avec succès |
| 402 | 11 | Échec de l’installation de la mise à jour |
| 402 | 12 | Téléchargement de la mise à jour |
| 402 | 13 | Mise à jour téléchargée |
| 402 | 14 | Échec du téléchargement de la mise à jour |
| 500 | 0 | État de détection inconnu |
| 500 | 1 | La mise à jour n’est pas obligatoire |
| 500 | 2 | La mise à jour est requise |
| 500 | 3 | La mise à jour est installée |
| 501 | 0 | État d’analyse inconnu |
| 501 | 1 | L’analyse attend l’emplacement du catalogue |
| 501 | 2 | L’analyse est en cours d’exécution |
| 501 | 3 | Analyse terminée |
| 501 | 4 | L’analyse est en attente de nouvelle tentative |
| 501 | 5 | Échec de l’analyse |
| 501 | 6 | Analyse terminée avec des erreurs |
Pour plus d’informations, consultez Les messages d’état dans Configuration Manager.
L’exemple suivant aligne et compare les fichiers Updatesdeployment.log et Statemessage.log. Assurez-vous que les journaux font référence au même message d’état en alignant le même TopicID (texte vert). Il indique clairement que les deux journaux font référence au même message d’état. Le TopicType texte bleu clair s’affiche. Notez qu’un journal peut afficher le nombre réel qui peut être interprété à partir du graphique de données de messagerie d’état. L’autre peut afficher une valeur générique (déjà interprétée). L’ID du message d’état (StateId) s’affiche en texte violet.
En combinant l’ID du TopicType message d’état (StateId) à partir du graphique, vous pouvez suivre exactement ce qui se produit dans les journaux. Dans cet exemple, ces exemples de code montrent les informations suivantes :
- Mise à jour de l’évaluation
- Résultat de l’évaluation
- La mise à jour en cours de téléchargement
- Mise à jour installée
- Redémarrage du système en attente
Il s’agit simplement d’un exemple de la façon dont les messages d’état sont envoyés dans le système d’état.
Flux de données de messagerie d’état
L’image suivante est un exemple réel de la façon dont les données de messagerie d’état rendent son chemin vers le point de gestion et sont traitées dans la base de données.
Cet exemple utilise un client de test. Il commence par forcer le client à récupérer WMI pour toutes les informations de messagerie d’état, puis envoie ces informations au point de gestion lors de son prochain cycle d’interrogation.
Dans WMI, les messages d’état sont stockés dans l’espace root\ccm\statemsg de noms. Dans cet espace de noms, il existe deux classes d’intérêt : CCM_StateMsg_SerialNum et CCM_StateMsg.
La CCM_StateMsg_SerialNum classe est utilisée pour enregistrer le dernier numéro de série utilisé pour un message d’état. Chaque message d’état a un numéro de série unique, similaire à l’inventaire matériel. De cette façon, le serveur de site peut suivre s’il manque des messages d’état du système. Il est important, car les messages d’état manquants peuvent entraîner des rapports d’état incomplets ou incorrects.
La CCM_StateMsg classe contient les messages d’état eux-mêmes. Dans l’instance de classe, vous pouvez trouver tous les messages d’état enregistrés.
Si vous ouvrez l’un de ces messages, vous trouverez les détails du message d’état et certaines données que nous avons abordées précédemment, comme illustré dans l’exemple suivant.
Nous pouvons renvoyer les données au point de gestion et suivre sa progression à l’aide des scripts de resynchronisation suivants.
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()
Ce script se trouve sur le web à différents emplacements. Il utilise le Kit de développement logiciel (SDK) Configuration Manager pour que le client renvoie ses données au point de gestion.
En règle générale, un script Visual Basic (VBScript) est exécuté à l’aide cscriptde . Notez que le script peut échouer si vous essayez de l’exécuter vous-même. Le problème est que Configuration Manager est une application 32 bits qui s’exécute sur un serveur 64 bits. La version par défaut est cscript la version 64 bits et fonctionne généralement correctement avec n’importe quel VBScript. Toutefois, dans ce cas, l’appel effectué nécessite la version 32 bits du cscript dossier syswow64.
Lorsque le cycle d’interrogation des messages d’état suivant se produit, tous les messages d’état sont envoyés au point de gestion.
Dans le fichier Statemessage.log, vous pouvez voir que les informations de message d’état sont extraites, mises en forme en XML, puis envoyées au point de gestion. Les informations de message d’état doivent ressembler à l’exemple suivant :
<! [LOG[Corps StateMessage : <?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>>
<Date de date reportType Full/ReportType>><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/ReportBody><>
]LOG< ![ LOG[CStateMsgManager ::GetSignEncyptMode]LOG] !><time="time » date="date » component="StateMessage » context=" » type="1 » thread="3592 » file="statemsg.cpp :1820 »>
<! [LOG[Messages d’état transférés avec succès au point de gestion]LOG] !><time="time » date="date » component="StateMessage » context=" » type="1 » thread="3592 » file="statemsg.cpp :1527 »>
Note
Cet exemple est tronqué à un seul message d’état en raison de la taille du fichier XML.
Bien que le fichier Statemessage.log enregistre que les messages sont envoyés au point de gestion, le système de messagerie d’état ne déplace pas réellement les données vers le point de gestion. Dans l’exemple suivant, vous pouvez voir que CCMMessaging cette opération est effectuée. Il y a plus qui passent en arrière-plan à ce stade. Toutefois, il est suffisant de savoir que CCMMessaging les données sont envoyées au point de gestion (dans ce cas, le MP_Relay composant).
<! [LOG[OutgoingMessage(Queue='mp_mp_relayendpoint', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}) : remis avec succès à l’hôte ' host_name'.]LOG] !>
Lorsque les données arrivent à des fins de traitement MP_Relay, elles sont traitées et traduites au .smx format de fichier, puis placées dans le auth\statesys.box\incoming dossier.
Tâche Inv-Relay : traitement du corps du message
Relais : FileType= SMX
Relais : dir de boîte de réception : C :\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
Relais : 0 pièces jointes reçues
Relais : 0 sur 0 pièces jointes correctement traitées
Inv-Relay : tâche terminée avec succès
Dans le auth\statesys.box\incoming dossier, vous pouvez voir les .smx fichiers en cours de traitement. En règle générale, vous ne les verrez pas ici. Toutefois, si les fichiers restent dans ce dossier, vous devez examiner ce que sont les messages et pourquoi ils ne sont pas traités. Si vous trouvez un .smx fichier, vous pouvez l’ouvrir à l’aide d’un éditeur de texte tel que le Bloc-notes pour afficher les détails. Toutefois, la mise en forme du fichier peut être non lisible, comme dans l’exemple suivant :
Si vous renommez le .smx fichier en ajoutant l’extension .xml afin que le fichier soit nommé file_name.smx.xml, puis double-cliquez sur le nouveau nom de fichier, le fichier XML est ouvert dans Internet Explorer et est beaucoup plus facile à lire.
L’image suivante est un exemple de fichier XML ouvert dans Internet Explorer. Les détails de l’ordinateur et du message d’état sont mis en surbrillance. Il contient les informations que nous avons précédemment abordées, combinées à la valeur d’ID de message d’état unique.
Note
Si vous renommez ces fichiers, commencez par les copier dans un autre dossier afin de ne pas affecter le dossier Statesys.box .
Enfin, les messages d’état doivent être traités dans la base de données. Dans le fichier Statesys.log , vous pouvez voir ces messages similaires à l’exemple suivant :
Nouveaux messages d’état à traiter, en commençant le thread de traitement
Thread « State Message Processing Thread #0 » id :5076 démarré
CMessageProcessor - Site parent détecté « site_name »
CMessageProcessor - Fichier de traitement : mdlbp169. SMW
CMessageProcessor : 1 enregistrements traités avec 0 enregistrements non valides.
CMessageProcessor - Fichier répliqué avec succès « mdlbp169. SMW » vers le site parent site_name.
CMessageProcessor : 1 fichier de message traité dans ce lot, avec 0 fichiers incorrects.
Thread « State Message Processing Thread #0 » id :5076 terminé normalement
Le composant de traitement de base de données peut être rendu visible en activant le suivi SQL, mais cela n’aide pas beaucoup. Nous devons utiliser le profileur SQL à la place. Le profileur nous donne un aperçu de ce qui se passe en arrière-plan, mais pas complètement. Plusieurs procédures stockées SQL sont responsables du traitement des messages d’état. En outre, plusieurs tables de la base de données stockent les données de messagerie d’état. Les procédures stockées qui effectuent le traitement des messages d’état commencent généralement par le nom spProcess. Il y a beaucoup de procédures de ce genre.
Le serveur de site effectue le suivi des messages d’état à mesure qu’ils arrivent, afin qu’il puisse marquer les messages manquants et demander régulièrement une resynchronisation si nécessaire. Les messages d’état sont importants. Tu ne veux pas manquer.
À mesure que les messages d’état arrivent, l’ID unique est lu et stocké dans la base de données. À mesure que le traitement se poursuit, les données sont régulièrement mises à jour. Si un écart est détecté, ces données sont signalées et stockées en tant que messages d’état manquants dans la SR_MissingMessageRanges table. Dans l’idéal, cette table sera vide. Toutefois, en production, vous pouvez voir des données dans la table. Cette table permet de suivre les messages d’état qui nécessitent une resynchronisation.
Le fichier de contrôle de site se trouve dans la base de données. Pour obtenir les paramètres spécifiques pour STATE_MESSAGE_SYSTEM, exécutez la requête suivante sur un site principal 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))
paramètres de STATE_MESSAGE_SYSTEM
| Nom | Value1 | Value2 | Valeur3 |
|---|---|---|---|
| Intervalle de msg de pulsation de pulsation | 60 | ||
| Intervalle d’interrogation de boîte de réception | 900 | ||
| Taille du bloc du chargeur | 256 | ||
| Threads du chargeur | 4 | ||
| Nombre maximal de blocs récupérés | 100 | ||
| Min Missing Message Age | 2880 | ||
| Resync Point terval | 15 | ||
| Nouvelle tentative de configuration | REG_SZ | <Config><Retry PatternID="0 » RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Note
- La resynchronisation Point terval est définie sur 60 minutes. Il s’agit de la planification de la vérification des systèmes qui nécessitent une resynchronisation des messages d’état.
- L’âge minimal du message manquant est défini sur 2880. Il s’agit de la durée pendant laquelle un message doit être manquant avant qu’une resynchronisation soit demandée.