L’inventaire matériel de ConfigMgr repose sur WMI4. WMI est l’implémentation sur les systèmes Windows de la norme WBEM et permet d’exposer des propriétés comme la taille mémoire, le nom NETBIOS, etc. dans l’équivalent d’une base de données.
Une fois exposées, il est possible d’interroger ces propriétés
au moyen d’un langage comparable à SQL, le WQL. Chaque machine Windows contient des applications associées à WMI, dont la plus fréquemment utilisée est probablement WBEMTEST. WMI est organisé en espaces de noms, et chaque application peut définir son propre espace de noms, y créer des classes et des instances.
ConfigMgr utilise principalement deux espaces de noms : – ROOT\CIMv2 et – ROOT\CIMv2\SMS Ajouter une information et l’associer à un poste Plusieurs mécanismes permettent d’ajouter des informations dans les classes WMI d’une machine, comme : -Création manuelle ou scriptée d’une classe et d’instances – Fichier MIF – Extension de configuration MOF Ajouter une information dans l’espace WMI Configuration.MOF (les classes sont créées, pas de collecte)
Le fichier configuration.mof définit les informations de classes que les clients doivent utiliser, et indique comment trouver la valeur associée au moyen de « provider ». Sur un serveur ConfigMgr installé en utilisant les répertoires par défaut, ce fichier se trouve dans « C :\Program Files\Microsoft Configuration Manager\inboxes\clifiles.src \hinv ». L’exemple ci-dessous utilise le provider de registry, qui lit une clef de registre et l’expose dans WMI. Voir listing 3.
Avant de modifier le fichier sur le serveur, c’est une bonne idée de vérifier qu’il n’y a pas d’erreur de syntaxe. Pour cela, lancer depuis la ligne de commande : C:\MOFCOMP -CHECK C:\MonBoulot\ConfigMOFModifie.MOF Le résultat en cas d’erreur n’est hélas pas très explicite. Dès que le fichier est enregistré dans …\inboxes\clifiles.src\ hinv – la compilation (MOFCOMP) se fait automatiquement sur le serveur – si la syntaxe est correcte, le fichier est sauvegardé dans ..\data\hinvarchive\configuration.mof.bak – si ce n’est pas le cas, le fichier est déplacé dans ..\data\hinvarchive\configuration.mof.bad.bak et la dernière version correcte est recopiée à sa place dans …\inboxes\clifiles.src\hinv
Si la syntaxe est correcte, ConfigMgr effectue les actions décrites dans le fichier qu’il faut considérer comme un script lu de haut en bas. Par défaut, les classes pour ConfigMgr se trouvent dans ROOT\CIMv2. ⇒ Toutes les opérations décrites dans l’extrait de MOF cidessus se font dans le namespace ROOT\CIMv2 (c’est le sens du #pragma namespace) ⇒ TSi une ancienne définition de la classe existe, elle est détruite (#pragma deleteclass). Cela permet d’éviter que des éléments d’une ancienne définition ne se mélangent à la nouvelle ⇒ TLa classe « Ma_Classe » est créée dans l’espace du serveur.
Pour le vérifier, exécuter WBEMTEST, se connecter à ROOT\CIMV2 et exécuter la query « select * from ma_classe ». Il est également possible de suivre la progression dans DATALDR.LOG. A ce stade, ConfigMgr n’a aucune connaissance du contenu de ces classes, ni de ce à quoi elles doivent correspondre dans l’inventaire. Le fichier configuration.mof est attaché à l’envoi de policy aux clients qui le compilent automatiquement. Ils créent alors la même classe et wbemtest permet de le vérifier.
Attention : dans certaines conditions, si la syntaxe est correcte mais qu’une erreur de logique s’est glissée dans le texte, l’agent désactive temporairement la fonction d’inventaire matériel. Dans ce cas la ligne « cycle d’inventaire matériel » disparaît de la liste des actions possibles dans l’onglet « Actions » de l’élément ConfigMgr du panneau de contrôle du client qui a reçu un configuration.mof qu’il ne peut interpréter.
Votre meilleur ami dans ce cas de figure est policyspy qui vous montrera quelle est la policy fautive. Toutefois là encore il y a peu de détails. Le plus simple est de remettre la version précédente sur le serveur et de troubleshooter le fichier mof… au calme. Demander à l’agent de collecter une information qui existe dans WMI mais n’est pas remontée SMS_DEF.MOF (collecte pour envoi à SMS)
Le fichier sms_def.mof définit les informations de classes que l’agent d’inventaire matériel doit renvoyer à ConfigMgr. Sur un serveur ConfigMgr installé en utilisant les répertoires par défaut, ce fichier se trouve comme configuration.mof dans « C:\Pro gram Files\Microsoft Configuration Manager\ inboxes\clifiles.src\hinv ». L’exemple ci-dessous utilise la classe définie dans le chapitre précédent l’expose dans WMI. Voir listing 4. Tout comme configuration.mof, sms_ def.mof est surveillé par le serveur.
De la même façon, dès qu’une modification y est apportée dans …\inboxes\clifiles.src\hinv – la compilation (MOFCOMP) se fait automatiquement sur le serveur – lsi la syntaxe est correcte, le fichier est sauvegardé dans ..\data\hinvarchive\sms_def.mof.bak – lsi ce n’est pas le cas, le fichier est déplacé dans ..\data\hinvarchive\sms_def.mof.bad.bak et la dernière version correcte est recopiée à sa place dans …\inboxes\ clifiles. src\hinv ⇒ La classe WMI de reporting est créée dans ROOT\CIMV2\SMS (le #pragma namespace ici est inutile si la classe précédente n’en a pas spécifié un autre, ça évite juste de vérifier et en tout cas ça ne fait pas de mal). ⇒ Ajout d’un enregistrement InventoryDataItem dans Root\CCM\Policy\Machine – lItemClass= « Ma_Classe » – lNamespace = « ROOT\Cimv2 » (SMS_Class_Template a été spécifié et il n’est pas spécifié de NameSpace différent), les valeurs à remonter à ConfigMgr sont récupérées dans ROOT\Cimv2 – lProperties = maclef, unchamp…
Comment ConfigMgr sait-il que le contenu à remonter dans root\cimv2\sms est à aller chercher dans root\cimv2 ? C’est la définition SMS_Class_Template (dont dérive Ma_Classe) qui le lui indique. Maintenant que le fichier a été modifié, suivons ce qui se passe avec DATALDR.LOG (et SMSTrace). A ce stade, ConfigMgr sait qu’il doit envoyer le nouveau SMS_DEF.MOF aux clients ; ConfigMgr convertit SMS_DEF.MOF en policy Au prochain cycle de récupération des policy, l’agent reçoit les policy reflétant ce SMS_DEF.MOF.
Il crée alors les classes. Au prochain cycle d’inventaire matériel, il collectera les informations afin de les renvoyer au serveur. Au passage, l’agent ConfigMgr renseignera le fichier du client “Inventor yagent.log » en notant une ligne "Inventory : Query =". A réception du premier inventaire contenant ces classes, ConfigMgr effectue les actions suivantes :
⇒ Création de la vue Dbo.v_GS_Ma_Classe0 ⇒ Création de la vue Dbo.v_HS_Ma_Classe0 ⇒ Création d’une entrée dans dbo.GroupMap – ArchitectureKey = 5 (si classe System ; voir dbo.ArchitectureMap) – GroupKey = (lu dans dbo.ArchitectureMap.NextGroupKey qui est incrémenté) – SpecificTableName = « Ma_Classe » – GroupName= « Ma_Classe » – GroupClass = « Mon_Groupe|Ma_Classe|Version » – HistoryTableName=Ma_Classe_HIST et quasiment la même dans dbo.PropertyDisplayNode (qui sera affichée dans ResourceExplorer) – KeyString=Hardware\Mon_Groupe\Ma_Classe – ClassDisplayName=Ma_Classe (le folder à cliquer dans ResourceExplorer pour voir les champs). ⇒ Création d’une entrée dans dbo.AttributeMap (la liste des champs affichés dans Resource Explorer pour le Folder « Group Key ») – ArchitectureKey = – GroupKey = – AttributeName = – ColumnName = ConfigMgr ajoute également un enregistrement dans Inventory Class, DataITem, DataItemCon text, sp_AddInven toryClassCon text, InventoryClassConetxt, Inven toryClass Property, MP_GetIn ventoryClassProperties, MP_Get AllIn ven toryClasses
Remarque: en réalité, ConfigMgr procèdera à bien d’autres ajouts dans la base, comme celui d’un enregistrement dans SMSProcedures ou d’un autre dans StatusMessage Instrs : insStrValue pour l’affichage des propriétés.
Toutefois, ces informations sont moins utiles à notre examen de ce jour. Le détail apparait dans DATALDR.LOG, et en particulier le message « Defining Group Class Mon_Groupe|Ma_Classe| 1.0» Une fois que tout cela est fait (ce qui ne prend que quelques secondes, le plus long est d’attendre le prochain cycle de policy et d’inventaire), un message ID=2717 est posté dans le status de l’INVENTORY_DATA_LOADER.
Conclusion
Nous avons entrevu quels mécanismes peuvent être utilisés pour ajouter des informations dans l’inventaire de ConfigMgr. Dans un prochain article, nous creuserons certains de ces aspects pour remonter par exemple les détails sur l’écran des postes, comment tatouer une machine, comment scripter un import massif, etc. Mark Cochrane – markc@exakis.com Mark travaille depuis près de vingt ans sur les plateformes Microsoft. MVP sur ConfigMgr, il est architecte senior sur les projets SMS/ConfigMgr et est également viceprésident du groupe d’utilisateurs français de System Center.
Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.
