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 la 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, aident les administrateurs à suivre le flux de travail des données via différents composants Configuration Manager.
Une visionneuse de messages status est intégrée directement à la console afin que status messages 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 :
- Rapports
- diverses données dans la console, telles que le nombre de systèmes qui doivent être mis à jour
- journaux du client
Les messages d’état contiennent des informations concises sur les conditions en 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 critiques s’appuient sur le système de messagerie d’état dans Configuration Manager. La compréhension de la messagerie d’état deviendra encore plus importante dans les futures versions de Configuration Manager à mesure que 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 du système.
Lorsque des 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, la pièce d’installation du client est présentée séparément pour plus de clarté. Pendant l’installation du client, le point de gestion est localisé et ciblé pour les messages d’état. Les messages d’état relatifs à l’installation du client sont transférés au point de status 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 est directement dirigé vers le point de gestion.
Les messages d’état qui arrivent au point de gestion sont traités dans les .smx fichiers par le composant Relais MP 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.
Creuser plus en profondeur
Nous devons nous assurer que la journalisation détaillée est activée pour :
- le client
- le point de gestion
- les composants de messagerie d’état sur le serveur de site
Pour définir la journalisation détaillée ou déboguer sur un client Configuration Manager ou un point de gestion, modifiez ou créez les entrées de Registre suivantes :
| Sous-clé de Registre | Nom DWORD | Données de la valeur |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global |
Loglevel | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
Activé | 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 la valeur |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
Journalisation détaillée | 1 |
Le suivi des commandes SQL nécessite que le suivi SQL soit activé pour les composants Configuration Manager. Mais peu de données utiles peuvent être obtenues directement à partir du traçage. C’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 passe 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 lui-même 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 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 les interpréter.
Le graphique suivant peut vous aider à interpréter la combinaison de et StateID à obtenir des TopicType données significatives.
select * from v_StateNames
Remarque
Le graphique suivant inclut les codes de type de rubrique des séries 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 de l’application inconnu |
| 301 | 1 | Installation de la ou des mises à jour |
| 301 | 2 | En attente de redémarrage |
| 301 | 3 | En attente de la fin d’une autre installation |
| 301 | 4 | Mise à jour(s) installée(s) correctement installée(s) |
| 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 de la ou des mises à jour |
| 301 | 10 | En attente de la fenêtre de maintenance avant l’installation |
| 301 | 11 | Attendre que l’orchestrateur tiers lance l’installation |
| 302 | 0 | État de l’évaluation inconnu |
| 302 | 1 | Évaluation activée |
| 302 | 2 | Évaluation réussie |
| 302 | 3 | Échec de l’évaluation |
| 400 | 0 | État de détection inconnu |
| 400 | 1 | Non obligatoire |
| 400 | 2 | Non détecté |
| 400 | 3 | Détecté |
| 401 | 0 | État de conformité inconnu |
| 401 | 1 | Conforme |
| 401 | 2 | Non conforme |
| 401 | 3 | Conflit détecté |
| 401 | 4 | Erreur |
| 401 | 5 | Non applicable |
| 401 | 6 | Non détecté |
| 401 | 7 | Enforced |
| 402 | 0 | État de l’application inconnu |
| 402 | 1 | Mise en application démarrée |
| 402 | 2 | Application en attente de contenu |
| 402 | 3 | En attente de la fin d’une autre installation |
| 402 | 4 | En attente de la fenêtre de maintenance avant l’installation |
| 402 | 5 | Redémarrage nécessaire 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 requise |
| 500 | 2 | La mise à jour est requise |
| 500 | 3 | La mise à jour est installée |
| 501 | 0 | État de l’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 | Nouvelle tentative d’analyse en attente |
| 501 | 5 | Échec de l’analyse |
| 501 | 6 | Analyse terminée avec des erreurs |
Pour plus d’informations, consultez 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 est affiché en texte bleu clair. 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) est affiché en texte violet.
En combinant et l’ID TopicType de message d’état (StateId) du graphique, vous pouvez suivre exactement ce qui se passe dans les journaux. Dans cet exemple, ces exemples de code affichent les informations suivantes :
- Mettre à jour l’évaluation
- Résultat de l’évaluation
- Mise à jour en cours de téléchargement
- Mise à jour en cours d’installation
- Redémarrage du système en attente
Il ne s’agit que 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 se rendent au 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 de root\ccm\statemsg 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 vérifier s’il manque des messages d’état du système. C’est important, car les messages d’état manquants peuvent entraîner des rapports d’état incomplets ou inexacts.
La CCM_StateMsg classe contient les messages d’état eux-mêmes. Dans la classe instance, 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 leur 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 amener le client à renvoyer ses données au point de gestion.
En règle générale, un script Visual Basic (VBScript) est exécuté à l’aide de cscript. 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 de cscript est 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 de cscript dont vous devez être à court du 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 au format XML, puis envoyées au point de gestion. Les informations de message d’état doivent ressembler à l’exemple suivant :
<! [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-4a6 1-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[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 »>
Remarque
Cet exemple est tronqué dans un message d’état unique en raison de la taille du fichier XML.
Bien que le fichier Statemessage.log enregistre que les messages sont distribué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 effectue cette opération. Il y a d’autres éléments qui se passent en arrière-plan à ce stade. Toutefois, il suffit 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}) : remise avec succès à l’hôte « host_name ».] LOG] !>
Lorsque les données arrivent pour traitement à MP_Relay, elles sont traitées et traduites au format de .smx fichier, puis placées dans le auth\statesys.box\incoming dossier.
tâche Inv-Relay : traitement du corps du message
Relay : FileType= SMX
Relais : Rép de la boîte d’envoi : C :\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
Relais : Reçu 0 pièces jointes
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 illisible, 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 que vous 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 abordées précédemment, combinées avec la valeur unique d’ID de message d’état .
Remarque
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, début du traitement du thread
Id du thread « State Message Processing Thread #0 » : 5076 démarré
CMessageProcessor : site parent « site_name » détecté
CMessageProcessor - Fichier de traitement : mdlbp169. SMW
CMessageProcessor : 1 enregistrement traité avec 0 enregistrement non valide.
CMessageProcessor : fichier répliqué « mdlbp169. SMW » au site parent site_name.
CMessageProcessor : 1 fichier de message traité dans ce lot, avec 0 fichier incorrect.
Id du thread « State Message Processing Thread #0 » : 5076 s’est 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 indice 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 traitent les messages d’état commencent généralement par le nom spProcess. Il existe de nombreuses procédures de ce type.
Le serveur de site suit les messages d’état à mesure qu’ils arrivent, de sorte qu’il peut marquer tous les messages manquants et demander régulièrement une resynchronisation si nécessaire. Les messages d’état sont importants. Tu ne veux pas en 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 marqué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. Ce tableau 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))
STATE_MESSAGE_SYSTEM paramètres
| Nom | valeur1 | Value2 | Valeur3 |
|---|---|---|---|
| Intervalle de msg de pulsation | 60 | ||
| Intervalle d’interrogation de la boîte de réception | 900 | ||
| Taille du bloc du chargeur | 256 | ||
| Threads de chargeur | 4 | ||
| Nombre maximal de blocs récupérés | 100 | ||
| Âge minimal du message manquant | 2880 | ||
| Resynchroniser l’intervalle de vérification | 15 | ||
| Nouvelle tentative de configuration | REG_SZ | <Config><Retry PatternID="0 » RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
Remarque
- L’intervalle de vérification de resynchronisation est défini 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.
- Min Missing Message Age 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.