[SCCM 2012] Le contrôle d’usage logiciel (Software Metering) en détails !

J’ai été sollicité sur une mission visant à valider la fonctionnalité de contrôle d’usage logiciel ou Software Metering de System Center Configuration Manager. Cette dernière est relativement puissante et permet de compter l’usage fait d’une ou plusieurs applications. Habituellement le scénario mis en avant est l’optimisation des licences. Les utilisateurs ont tendance à demander de plus en plus de logiciels sans forcément les utiliser. On peut pousser le sujet un peu plus loin en mettant en place un processus de désinstallation automatique lorsque l’application n’a pas été utilisé depuis X jours. Le Software Metering est aujourd’hui peu utilisé pour différentes raisons dont notamment des raisons légales de respect de la vie privée. Les données collectées offrent une photographie complète de l’utilisation des logiciels et donc du travail fourni par l’utilisateur.

Passons aux choses sérieuses, j’ai été appelé car la fonctionnalité ne semblait pas renvoyer les bonnes informations. Les heures d’utilisation renvoyées ne correspondaient pas et l’usage sur les serveurs Remote Desktop non plus. Afin de trouver le problème, j’ai procédé de la manière suivante :

1. Valider la configuration de l’infrastructure
2. Valider que les données collectées localement étaient correctes
3. Valider que les données renvoyées et stockées dans la base correspondaient aux données collectées
4. Valider que les données agrégées correspondent aux données collectées
5. Valider le fonctionnement des rapports

Je vous propose au travers de cet article de voir le processus complet de cette fonctionnalité en mode Deep Dive.

Pour le premier point, je ne vais pas rentrer dans les détails. Je vous renvoie vers la documentation TechNet associée. J’ai vérifié :

• L’état de santé de l’infrastructure et notamment que le Management Point était fonctionnel
• L’installation correcte de l’agent et sa communication avec l’infrastructure
• L’activation de la fonctionnalité Software Metering (les données étaient déjà collectées)
• La création et l’activation d’une règle de Software Metering pour le logiciel qui va servir de cobaye.

Une fois ces points validés, j’ai pris un poste de travail type disposant des logiciels contrôlés. Le processus est simple. J’ouvre le fichier de journalisation associée à la fonctionnalité sur l’agent (mtrmgr.log) et je procède à l’ouverture de l’application cible :

Lors de l’ouverture de l’application, on observe l’élément suivant (mtrmgr.log) :

Process ID 19548 is for process C:\Program Files (x86)\<APPLICATION>\<APPLICATION>.exe                mtrmgr                16/03/2015 14:07:46      4596 (0x11F4)

Found match against RuleID XXX00038 mtrmgr                16/03/2015 14:07:46       532 (0x0214)

Tracked usage for process 19548             mtrmgr                16/03/2015 14:07:46       532 (0x0214)

On observe que le client ConfigMgr traque le lancement du processus <APPLICATION>.exe avec un identifiant donné. Il trouve une règle de collecte associée et démarre le contrôle.

Une fois démarré, le client ConfigMgr écrit un événement dans la base WMI pour marquer le démarrage de l’application. La classe utilisée est CCM_HistoricalMeteredData. Vous pouvez utiliser une requête WQL comme suit : Select * FROM CCM_HistoricalMeteredData WHERE Fileinfo like « %<APPLICATION>.exe% »

instance of CCM_HistoricalMeteredData

{

                Action = "Metered";

                FileInfo = "\\\\.\\root\\ccm\\SoftwareMeteringAgent:CCM_MeteredFileInfo.FileName=\"<APPLICATION>.exe\",FileVersion=\"< APPLICATIONVERSION>\",FileSize=367104,ProductName=\"<APPLICATION>\",ProductVersion=\"<APPLICATIONVERSION>\",CompanyName=\"<EDITEUR>\",ProductLanguage=0";

                MeteredDataID = "B9142052-EDDA-4676-89D6-ED55140D5955";

                StartTime = "20150316130746.000000+000";

                Status = 9;

                UserName = "<DOMAIN>\\<USER>";

};

On Remarque bien le stockage de l’heure en UTC pour normalisation et renvoie au serveur.

Après fermeture de l’application, on note l’élément suivant dans le log mtrmgr.log :

Termination event received for process 19548   mtrmgr                16/03/2015 14:12:22       4596 (0x11F4)

Dans la base WMI, la date de fin est mise à jour avec un nouvel événement (Status = 8) :

instance of CCM_HistoricalMeteredData

{

                Action = "Metered";

                EndTime = "20150316131222.000000+000";

                FileInfo = "\\\\.\\root\\ccm\\SoftwareMeteringAgent:CCM_MeteredFileInfo.FileName=\"<APPLICATION>.exe\",FileVersion=\"< APPLICATIONVERSION>\",FileSize=367104,ProductName=\"<APPLICATION>\",ProductVersion=\"<APPLICATIONVERSION>\",CompanyName=\"<EDITEUR>\",ProductLanguage=0";

                MeteredDataID = "B9142052-EDDA-4676-89D6-ED55140D5955";

                StartTime = "20150316130746.000000+000";

                Status = 8;

               UserName = "<DOMAIN>\\<USER>";

};

Même chose, la date est stockée en UTC pour normalisation.

Etape 2 : Maintenant que nous avons validé que l’information est collectée et correctement stockée côté client, nous allons voir côté serveur si les informations sont correctes dans la base de données. Après réception des données, la vue v_MeterData (exposant les données brutes) renvoie bien les bonnes heures :

Vous pouvez utiliser la requête suivante : SELECT * FROM v_MeterData Where netbios_name0 = ‘<COMPUTER>’ and username = ‘<USER>’ and StartTime = <DATE DE DEBUT DE CAPTURE> AND EndTime = <DATE DE FIN DE CAPTURE>

Comme vous pouvez le voir la date est stockée en UTC associée à un Offset correspondant à la TimeZone et à l’heure d’été.

Etape 3 : Une fois les données brutes stockées et conformes, j’ai vérifié la cohérence des données agrégées. En effet, la quantité de données collectées nécessite une agrégation afin de les utiliser dans les rapports. Ce processus est réalisé par des tâches de maintenance :

• Summarize Software Metering File Usage Data : Lors de l'utilisation du contrôle d'usage logiciel, les clients ConfigMgr renvoient des rapports d'utilisation. Cette tâche permet la compression de plusieurs données en un seul enregistrement. Ce dernier fournit des informations sur le programme, la version, la langue et le nombre d’utilisateurs distincts sur un intervalle de 15 minutes et une heure.
• Summarize Software Metering Monthly Usage Data : Cette opération prend les données précédemment agrégées pour donner un aperçu sur l'usage logiciel mensuel fait sur les machines. Ces informations agrégées sont stockées dans une table puis exposée via la vue v_MonthlyUsageSummary.

La dernière tâche de maintenance permet l’exploitation des données mensuelles dans les rapports. Pour un mois défini, les données deviennent disponibles le mois suivant. Il est possible de forcer l’agrégation via l’outil en ligne de commande Runmetersumm.exe <NOM DE LA BASE> disponible dans le dossier Tool.

Note : Il existe aussi deux autres tâches de maintenance qui font le travail de nettoyage des enregistrements arrivés à péremption.

Afin de vérifier la bonne agrégation, j’ai pris l’utilisation cumulée sur un mois défini pour des utilisateurs pris au hasard que j’ai comparé avec les données de la vue v_MeterData exposant les données brutes :

On retrouve sensiblement les mêmes valeurs à l’arrondi près. Ceci valide la bonne collecte et le stockage correct des données en base.

Etape 4 : On en déduit que le problème doit se situer au niveau des rapports. Pour valider ce problème de décalage d’heure et de nombre d’utilisation incohérente, j’ai choisi le rapport : Analyse de la tendance d'utilisation totale pour un logiciel contrôlé spécifique sur les serveurs Windows Terminal Server

Ce rapport combine le problème avec les serveurs TSE et le décalage. Par exemple, il renvoie plus de 1500 utilisateurs pour une application donnée sur un mois. L’entreprise ne comprend que quelques centaines d’utilisateurs.
Après analyse du rapport, Microsoft affiche le nombre d’utilisateurs des serveurs du service TSE. Le titre (et la traduction) peut être ambiguë mais le but est bien d’afficher la relation n utilisateurs pour n serveurs pour une application donnée. Comme un utilisateur peut se balader de serveurs en serveurs en fonction de la répartition faite par la ferme, on se retrouve avec des chiffres relativement peu fiables. Ainsi un utilisateur qui a utilisé une application TS proposée sur 7 serveurs, peut remonter jusqu’à 7 fois car le but est d’afficher les utilisateurs des serveurs Terminal Services.

Pour le décalage d’heure remontée, la date est stockée en UTC et l’offset vient en parallèle dans une autre colonne. Il en ressort que Microsoft a fait le choix d’utiliser le temps universel (UTC) dans ses rapports.  

Pour couvrir les besoins de reporting, j’ai créé deux rapports téléchargeables.

J’avais commencé à rédigé l’article il y a plusieurs mois, l’équipe ConfigMgr vient de publier un article sur son blog qui amène des éléments d’informations complémentaires sur certains points. Je vous invite à le lire : http://blogs.technet.com/b/configurationmgr/archive/2015/05/27/taking-a-look-at-the-software-metering-workflow-in-system-center-2012-configuration-manager.aspx