Configuration Manager – Enfin temps reel ?

Tous les utilisateurs de Configuration Manager le savent, SCCM n’est pas un produit temps reel. Il existe des moyens d’optimiser les délais, cependant, les données seront toujours tributaires de paramètres tel que les client settings, les découvertes, les updates de collections,etc…Avec l’arrivée de CMPivot, la donne serait-elle en train de changer?

Comme je le disais en introduction, les données des clients SCCM ne sont pas des données temps reel. En effet, lors de l’exécution d’une requête (par exemple tous les postes avec plus de 20 GB de disque disponible sur la partition « C:\ »), cette query est exécutée sur la base de donnée de notre serveur. Le résultat renvoyé correspond donc a tous les postes qui avait plus de 20 GB de disque disponible au moment ou ces postes ont envoyés leur inventaire. Par défaut, cet inventaire est envoyé tous les 7 jours. Nous avons donc un résultat avec un delta de jusqu’à 7 jours dans le cas d’un paramètre par défaut. Non pas qu’il soit nécessaire d’avoir dans tous les cas des données à jour à la minute, cependant, un grand nombre de use case impose des données temps reel, notamment concernant la sécurité par exemple.

Il semble que Microsoft ait bien compris ce manque dans SCCM et le besoin grandissant d’avoir des données temps reel. En effet, depuis la build TP 1805, un nouvel outil intégré dans la console fait son apparition, CMPivot. Pour le voir apparaître dans le ruban, il est nécessaire de sélectionner une collection. Une fois fait, l’outil devient visible:

Alors CMPivot c’est quoi ?
CMPivot est un outil qui permet un accés temps reel sur les machines (démarrées bien entendu). Entendez par la que vous pouvez exécutez des requêtes directement sur les postes pour retourner, par exemple, la taille des disques sur les devices de la collection. Le langage utilisé est le même que pour Azure Log Analytics.

CMPivot, comment cela fonctionne?
Tout d’abord, comme je le disais au début, il faut sélectionner une collection pour faire apparaître l’outil:

Lorsque vous cliquez sur le bouton « Start CMPivot », l’outil apparaît:

Microsoft a plutôt bien fait les choses puisque la page d’accueil donne pas mal d’information sur l’utilisation de l’outil. Nous avons des explications sur la syntaxe de requêtes:

Les objets qui peuvent être requêtés (Notez que tous les objets sont disponibles dans la colonne de gauche):

Les opérateurs:

Les fonctions d’aggrégation:

Et les fonctions scalaires:

Notez le message pour chaque catégorie:« Currently the following XXX are supported ». Cela nous laisse supposer l’arrivée de nouvelles fonctions dans l’avenir.

L’espace « Query » est quand à lui coupé en 2 parties. L’espace requête et l’espace résultat:

Testons notre première query. Nous allons récupérer tous les modèles virtuels. Pour se faire, nous avons l’objet (entities) à requêter « Device » puis l’opérateur « where ». La requête donne donc "Device | Where (Model like 'Virtual%')"

Notez, sous la fenêtre de résultat les informations supplémentaires. 1 client offline et 0 erreur pour mon 2ème objet. La requête me renvoie donc un objet, le device « CMTP ». A partir de la, si vous cliquez sur un objet dans le résultat, vous avez un nouveau menu intéressant. Vous pouvez

  • « Pivot To »: exécuter une nouvelle requête
  • « Run Script »: depuis votre librairie (Plus d’infos ICI)
  • « Remote Control »: Prise en main à distance
  • « Resource Explorer »: L’explorateur de ressources
  • Si nous « pivotons » sur « SoftwareUpdate », la requête remplit automatiquement le champs de requête, puis nous renvoie le résultat:

    Tout ceci est donc un résultat bien temps réel. Attention toutefois à ce type de query (Where Device == ‘Nom’), car cette query sera bien exécutée localement sur tous les devices de la collection. Pour une requête sur un seul poste, il n’est donc pas souhaitable de l’exécuter sur une collection avec beaucoup de devices.

    Et côté client?

    Le fonctionnement côté client est relativement simple, il utilise la fonctionnalité de déploiement des scripts que je vous détaillais dans ce post.
    SCCM distribue au client un script PowerShell, capable de gérer toutes les requêtes de l’outil. D’ailleurs, si on regarde un peu le script:

    Remarquez que l’on y voit les conditions gérant tous les objets requêtables.
    Mais revenons côté client, le script est donc poussé dans le ScriptSore (« C:\Windows\CCM\ScriptStore ») et est ensuite exécuté localement. En regardant le log scripts.log pour ma première requête:

    Puis la deuxième:

    Monitoring:
    On retrouve l’exécution des requêtes dans la console SCCM, à l’emplacement « \Monitoring\Overview\Client Operations ». Elles apparaissent sous le libellé « Run Script »:

    Ce nouvel outil nous ouvre donc des possibilités immenses, qui plus est couplé à la librairie de scripts. Plus qu’à scripter :)

    Please follow and like us:

    Laisser un commentaire

    Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

    Social media & sharing icons powered by UltimatelySocial