Configuration Manager – Execution de scripts PowerShell

PowerShell étant la boîte à outils à tout faire de Microsoft, il était donc normal de voir arriver l’exécution de scripts directement intégré dans la console Configuration Manager. Si vous utilisez les fonctionnalités en Pre-release, vous l’avez sûrement aperçu, puisqu’elle est disponible depuis la version 1706. Depuis la version 1802, elle est maintenant officiellement en production.

Avant de rentrer dans le vif du sujet, et si vous voulez voir les fonctionnalités en production et / ou en pré-release, cela se trouve dans la console d’administration sous le nœud « \Administration\Overview\Updates and Servicing\Features »:

Concernant l’exécution de scripts (PowerShell seulement), cela se passe dans la partie « Software Library »:

Comment cela fonctionne t’il?
Creation du script
Pour se faire, rendez-vous dans la console à lemplacement « \Software Library\Overview\Scripts », puis, dans le ruban, cliquez sur « Create script »:

Dans notre exemple, nous utiliserons le code suivant:

$drive = Get-WmiObject -class Win32_LogicalDisk | where-object {$_.DeviceID -eq "C:"}
$freeGB = ($drive.FreeSpace/1024/1024/1024)
$freeGB = [math]::Round($freeGB,2)
"C:\ = " +$freeGB + " GB"

Ce code nous renverra l’espace disque disponible sur le disque « C: » et formaté en GB.

Après avoir cliqué sur « Create script », un nouvel assistant s’ouvre. Vous pouvez nommer votre script et coller votre code (ou importer du code). Notez la section « Script language ». Seul PowerShell est disponible, mais cette section laisse néanmoins entrevoir la possibilité d’avoir d’autres languages disponible. une fois le code collé, cliquez sur « Next »

Vérifiez le résumé puis cliquez sur « Next »

Enfin, cliquez sur « Close »

Notre script est maintenant intégré à notre bibliothèque de scripts.

Approbation du script
En effet, Microsoft à intégrer un système d’approbation pour les scripts créés. Par défaut, le créateur d’un script ne peut l’approuver. Ceci est tout à fait compréhensible quand on connait la force de PowerShell, et donc, le pouvoir de nuisance pour quelqu’un de mal intentionné. Cependant, il est possible de désactiver le fait qu’un rédacteur de script ne puisse approuver. Pour désactiver cette fonctionnalité, rendez vous dans les « Hierarchy settings » à l’emplacement « \Administration\Overview\Site Configuration\Sites ». Puis décochez la case « Script authors require additional script approver »:

Nous sommes maintenant en mesure d’approuver nos propres scripts. Pour se faire, sélectionnez le script et, dans le ruban, cliquez sur le bouton « Approve / deny »:

Dans le nouvel assistant, vérifiez le script, puis cliquez sur « Next »

Sélectionnez l’approbation (ou déclinez), renseignez un commentaire si nécessire, puis cliquez sur « Next »

Vérifiez les détails, puis cliquez sur « Next »

Enfin, fermez l’assistant en cliquant sur « Close »

Lancement du script
Nous sommes maintenant en mesure d’exécuter notre script sur une collection ou un device.
Ici, nous allons exécuter sur un device. Faites un clic droit sur l’objet et sélectionnez « Run Script »

Dans le nouvel assistant, trouvez le script à lancer puis cliquez sur « Next »

Vérifiez le résumé, puis cliquez sur « Next »

SCCM créé le job d’exécution

Puis renvoie le résultat:

Monitoring d’exécution des scripts
Il est tout à fait possible de monitorer et récupérer les résultats des scripts déjà exécutés. Pour se faire, rendez vous à l’emplacement « Monitoring\Overview\Script Status »:

Pour retrouver le résultat, dans le ruban, cliquez sur « Show Status ». Notez la possibilité de mettre en forme le résultat sous forme de tableau, de camenbert ou de barres:

Coté client
Que se passe t’il côté client?
Dés que le client SCCM reçoit la notification d’exécution, il télécharge le script PowerShell dans le répertoire « ScriptStore » situé lui même dans le répertoire d’installation du client SCCM (généralement « C:\Windows\CCM »). Le script se retrouve dans ce cache avec le nom du GUID du script:

Toutes les actions liés à l’exécution du script sont bien entendu logguées. On retrouve tout ça dans le log « Scripts.log »:

Au vu des possibilités offertes par cette fonctionnalité, il n’y a plus de limites pour la remontée et / ou l’automatisation des tâches sur les postes de travail.

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