PI Services

Le blog des collaborateurs de PI Services

MECM (SCCM) : Remettre à zéro l'indicateur d'installation

Une des bonne pratiques SCCM est d'activer la tâche de maintenance "Remettre à zéro l'indicateur d'installation".

Cette tâche permet d'effacer les indicateurs d'installation lorsque la découverte par pulsations d'inventaire ne découvre aucun client au cours de la période de redécouverte.

L'avantage d'avoir activé cette tâche de maintenance est de garder les indicateurs d'installation des agents MECM à jour et de détecter les agents qui ne sont plus en bonne santé et les réinstaller.

Pour activer cette tâche, sur la console MECM, cliquer sur Administration > Configuration de site > Sites > Cliquer sur le site primaire puis sur Maintenance de site.

Chercher la tâche avec le nom "Remettre à zéro l'indicateur d'installation" et cliquer sur activer. il est possible également de définir la planification pour contrôler la fréquence d'exécution de la tâche.

Dans la capture d'écran ci-dessus, la tâche de maintenance a été activée pour détecter les agents qui n'ont pas contacté le site primaire MECM depuis 40 jours par pulsation d'inventaire, si c'est le cas, l'indicateur d'installation passera de "Oui" à "Non".

- Si l'agent n'existe plus, l'indicateur reste "Non" jusqu'au nettoyage des objets obsolètes

- Si l'agent existe toujours mais était déconnectée pendant plus de 40 jours, à la prochaine connexion l'indicateur passera à "Oui"

- Si l'agent existe toujours mais ne communique pas avec MECM car il n'est plus en bonne santé, il sera réinstallé puisque l'indicateur d'installation est passé à "Non" mais la machine est connectée pour recevoir un nouveau push du client

 

Power BI – Afficher les infos de rafraichissement d’un dashboard


Dans Power BI, l’info du dernier rafraichissement d’un dashboard ne fait pas l’objet d’une fonctionnalité directe identifiée comme telle.

Il s’agit d’une info bien sur importante. Pour l’implémenter, la procédure n’est pas très compliquée.


image

Dans l’editeur de requete, creer une nouvelle requete vide.


image

Renommer la requête avec un nom explicite.


image


image

Cliquer sur Advanced Editor pour éditer la nouvelle requête.


image

Ecrire la requete comme ci-dessus (Source = #table(type table[Date Last Refreshed=datetime], {{DateTime.LocalNow()}})


image

La valeur de la date et heure actuelle s’affiche.


image

Valider en cliquant Close & Apply


image

Sur la page du dashboard dans la liste des champs (Fields) Faite un clic droit et selectionner New measure


image


image

Dans la barre éditeur de la mesure, tapez le texte ci-dessus (Last Refreshed = VALUES(‘Date Last Refreshed’[Date Last Refreshed])


image

la mesure est crée et va pouvoir etre utilisé dans une visualization.


image

Selectionner une Visualization de type Card


image

Associer a cette visualization la mesure crée.


image

Voila. Vous pouvez bien sur changer l’apparence de la visualization (par ex la couleur de fond) dans ses propriétés.

SCOM - Analyser un managed module

Débutons par un bref rappel sémantique : dans SCOM, le terme workflow désigne l’ensemble des éléments qui constituent un moniteur, une règle, une découverte ou une tache. Un workflow peut donc être constitué d’une data source, d’une ou plusieurs probes, de condition detections, de writeactions…

La grande majorité des Management Packs contient des workflows consistant en un assemblage de modules préexistants, par exemple :

  • Une datasource basée sur le module “scheduler” pour déclencher le workflow à intervalle régulier
  • Une probe basée sur le module “powershell script” pour exécuter un script. C’est ce dernier qui ira effectuer des tests et en renverra le résultat dans le workflow
  • Une ou plusieurs condion detections basées sur le module “Filter”, afin de détecter si le résultat du script indique un problème ou non
  • Une writeaction pour déclencher l’alerte si le filtre indique un problème.

Ces modules préexistants sont la vraie fondation de tout workflow SCOM, et leur code est en général du C# contenu dans une dll : c’est ce que l’on appelle des Modules Natifs (“native modules”).

Certains Management Packs poussent ce principe encore plus loin, en intégrant des modules créés de toutes pièces et dédiés à leur utilisation au lieu d’intégrer les modules natifs dans leurs workflows : on les appelle des modules managés (managed modules).

Les raisons de ce choix sont le plus souvent :

  • L’ajout de fonctionnalités irréalisables autrement
  • La réutilisation de code compilé préexistant
  • L’optimisation des performances des workflows : en effet, un workflow powershell tel que décrit ci-dessus permet de découvrir l’immense majorité des cas rencontrés. Cependant, il nécessite une exécution du script complète à chaque fois : chargement de powershell, chargement des modules powershell, authentification sur l’application à interroger, collecte des données puis déconnexion, déchargement de powershell etc. Un managed module reste lui en mémoire indéfiniment et peut ainsi ne boucler que sur la partie “collecte des données”, ce qui allège grandement le traitement.

Malheureusement cette technique impacte aussi fortement la lisibilité du code et la possibilité de le débugger par n’importe qui, puisque tout ou partie du workflow est maintenant “caché” dans une dll.

Prenons un exemple concret : les dernières versions du Management Pack pour SQL Server intègrent des managed modules, et il arrive parfois que l’alerte suivante se déclenche : MSSQL on Windows: Database is in offline/recovery pending/suspect/emergency state.

Pourtant, le détail de l’alerte n’est pas toujours probant puisqu’il peut n’indiquer que les informations suivantes :

  • MonitoringStatus : Bad
  • DatabaseState : ONLINE
  • IsAccessible : false
  • IsMirroringMirror : false
  • IsAlwaysOnReplica : true
  • ErrorCode : 0
  • ErrorDescription : <vide>

Très insuffisant pour comprendre d’où vient le problème… Dans ce genre de cas, il est donc nécessaire d’aller voir comment fonctionne le moniteur d’où provient l’alerte pour tenter de comprendre son passage en échec. En remontant le fil du workflow, on constate que les tests à proprement parler sont réalisés dans une Probe nommée MSSQL on Windows: Database Status Probe Action, dont il n’est pas possible de voir le fonctionnement directement dans le code du Management Pack puisqu’elle repose sur un Managed Module :

image

Nous avons cependant deux informations utiles :

  • Assembly : c’est le nom de la dll qui contient le code compilé du module
  • Type : c’est le nom de la fonction qui produit les données utilisées par le moniteur.

La dll peut être récupérée sur n’importe quel serveur SQL disposant d’un agent SCOM dans le dossier Health Service State, ou en l’extrayant du fichier .mpb du management pack avec l’outil MPBUtil de Silect.

Elle peut ensuite être ouverte à l’aide de l’outil gratuit JetBrains dotPeek.

Une fois ouverte, on retrouve la fonction DBStatusMonitoring en suivant l’arborescence :

 image

Un clic-droit > go to implementation permet de retrouver le code exécuté par cette fonction à proprement parler et, en particulier, une zone que l’on interprète facilement comme étant l’exécution d’une requête SQL résultant en plusieurs champs qui correspondent complètement aux détails de notre alerte d’origine :

image

Cependant, la requête SQL a proprement parler n’est pas visible ici. Elle est en réalité contenue dans une “Ressource”  (un champ texte annexe de la dll) nommée GetDBStatuses :

image

Retournons donc dans l’explorateur de la dll pour ouvrir les ressources, dans laquelle nous allons rechercher GetDBStatuses. Et voilà notre requête SQL :

image


Vous pouvez désormais copier cette requête et l’analyser et l’exécuter manuellement pour comprendre d’où provient l’alerte!

D’autres modules managés auront un fonctionnement différent, mais le principe d’analyse restera identique… A vous de jouer!