Powershell, une ligne de commande qui a su se faire désirer

Ce Shell a été conçu pour être :
• Aussi interactif et modulable que le Korn Shell ou le BASH
• Orienté production comme le sont VMS –DCL ou AS400 CL
• Plus aisé à programmer que le PERL ou RUBY

L’environnement de ligne de commande ou Shell de Microsoft nécessite le Framework .NET 2 et est disponible pour Windows XP SP2, Windows 2003 SP1/SP2 et bien en-tendu Vista et Windows Server 2008. PowerShell vient combler les manques que nous avons tous ressentis sur les environnements Microsoft après avoir utilisé un Shell Unix.

Au nombre de ses atouts PowerShell nous offre :
• De nombreuses commandes et utilitaires
• Une interface orientée objet
• Une utilisation simple en ligne de commande, des objets COM et du scripting .NET.

Ce point est particulièrement intéressant : si une fonctionnalité n’est pas nativement disponible dans PowerShell, elle peut être supplée aisément depuis un appel aux fonctionnalités du Framework .NET.

• Les Reg Ex ou Expression régulière simple à mettre en oeuvre.
• Le bénéfice des « Pipe » ou redirections de sortie d’une commande comme paramètre d’entrée d’une autre commande
• La redirection de sortie d’une commande exécutée. Par exemple rediriger le résultat de la commande DIR dans un fichier.
• Des « Provider data » ou lecteurs navigables pour accéder au travers d’un point de montage type système de fichiers à la base de registre, aux magasins de certificats et etc.

PowerShell apporte un gain de productivité évident à toutes personnes l’utilisant que ce soit pour l’administration de serveur ou tout simplement pour gérer son propre poste de travail en tant qu’utilisateur avancé. Néanmoins le temps d’apprentissage du Shell de Microsoft se trouve ralenti par rapport aux premières versions béta :

Dans les versions Béta de PowerShell v1 la syntaxe reprenait les noms de commandes de shells Unix ; suite au lancement de la version finale les noms de commandes ont été pour la plupart changés. Les fonctionnalités des commandes restent identiques à celles d’un shell UNIX mais ces commandes s’appellent sous des noms différents. L’expérience dont on dispose sous un Shell UNIX est donc transposable directement sous PowerShell à l’exception de l’apprentissage du nouveau nom des commandes ; à moins de créer des alias pour ces commandes.

Au demeurant ce point ne doit pas être considéré comme un prétexte pour ralentir son intérêt ; peu d’arguments peuvent s’opposer à adopter cette ligne de commande… Avec l’arrivée prochaine de PowerShell version 2, de nouvelles fonctionnalités apparaissent ; la plus intéressante étant la possibilité d’utiliser la majeure partie des fonctionnalités de PowerShell à distance via le remoting.

Fini les « bidouilles » à l’aide de PSEXEC, de script de démarrage ou de se connecter via le bureau à distance sur de nombreux serveurs pour y exécuter la même commande. Le remoting permet sans problème d’effectuer une exécution de commande sur un ensemble d’ordinateurs et d’en récupérer le résultat à distance.

PowerShell en action
 L’utilisateur Windows s’est quelque peu éloigné de l’environnement en ligne de commande : Entre la marge de manoeuvre fort étroite du batch et la complexité pour interagir avec le système du Vbscript, le recours au Shell ne se faisait plus qu’accessoirement pour les scripts de démarrage et autres ping réseau. Mais, assez paradoxalement, alors que le monde Linux vante de plus en plus son intégration des interfaces graphiques, voila que Microsoft nous met entre les mains une interface en ligne de commande dotée d’un puissant langage de script.

Cette puissance, tout utilisateur qui s’est essayé à PowerShell la perçoit immédiatement de même que la facilité avec laquelle elle peut être déployée. L’icône de raccourci vers PowerShell trouve rapidement sa place sur le bureau de tout administrateur ! Pour présenter plus concrètement PowerShell et montrer avec quelle facilité il s’interface avec le système, nous prendrons comme exemple l’écriture d’un Test de validation du système (en anglais, BVT : Build Vérification Test).

Ces types de test, habituellement réservés aux projets de développement de code ont pour but de valider la stabilité d’un environnement en examinant divers éléments clés du système. Les BVT automatisés sont particulièrement utiles pour de projets itératifs lors desquels l’environnement évolue constamment et doit être revalidé régulièrement. En gardant comme fil blanc l’exécution de notre test de vérification du système (BVT), nous verrons comment de simples commandes PowerShell permettent de vérifier les journaux du système, la base de registre, les process qui tournent et les services installés. Comme exemple de test, nous allons effectuer une batterie de tests validant l’installation de Microsoft Word 2007.

Étape 1. Préparation de l’environnement
Passons rapidement sur l’installation et la configuration de PowerShell. PowerShell est compatible avec toutes les versions de Windows qui supportent la version 2.0 de .NET (Windows XP SP2, Windows Server 2003, Windows Vista, Windows Server 2008). Pour Windows Server 2008, il suffit de repérer Power- Shell parmi la liste des features et de l’installer.

Pour les autres environnements, les sources de PowerShell sont disponibles ici :
http://www.microsoft.com/windowsserver2003/ technologies/management/powershell/download.mspx

Une fois PowerShell installé, 2 éléments sont à configurer :

 1) Configuration de la stratégie d’exécution de l’environnement de ligne de commande
Pour autoriser PowerShell à exécuter les scripts locaux sans qu’ils doivent être approuvés, nous définirons la sécurité “Remote-Signed” qui permet une plus grande maniabilité dans un environnement de test, tout en maintenant un certain niveau de sécurité pour les scripts téléchargés sur internet. (Ils devront être approuvés avant de pouvoir être exécutés). Pour ce faire, dans PowerShell, tapez la commande Set-ExecutionPolicy RemoteSigned Pour vérifier quelle stratégie d’exécution est actuellement configurée pour votre PowerShell, utilisez la commande Get-ExecutionPolicy

2) Préparation du répertoire de sauvegarde des scripts
Les scripts PowerShell se sauvegardent dans des fichiers au format .ps1. Les scripts décrits dans cet article peuvent être exécutés directement dans le Shell ou bien être sauvegardés dans des fichiers. PowerShell s’ouvre par défaut dans le répertoire PS C:\Users\[Utilisateur]> Commencez donc par créer un dossier dans lequel sauvegarder les scripts et naviguez-y.

Étape 2. Création du script PowerShell
Maintenant que PowerShell est installé et correctement configuré, nous pouvons commencer à écrire notre script PowerShell qui effectuera un BVT de l’application Microsoft Word.

1. Vérification des journaux
Commençons par vérifier l’élément qu’un administrateur irait examiner manuellement en premier : les journaux système. Avec PowerShell, il est très simple d’accéder et de manipuler les informations contenues dans les journaux avec la commande Get-Eventlog. Cette commande permet tant d’obtenir des informations sur les journaux eux-mêmes (taille, type d’écriture, nombre d’évènements) que de les examiner à la recherche d’évènements spécifiques. Pour lister les journaux accessibles par PowerShell, utilisez la commande Get-EventLog –list En fonction de votre Système d’exploitation et des éléments installés sur votre système, les journaux accessibles peuvent différer.

Mais ces éléments seront toujours listés :

• Application
• Security
• System
• Hardware Events
• Windows PowerShell

Un des éléments permettant de valider l’installation de Microsoft Word est la présence de l’évènement MsiInstaller avec l’id 11707 dans les journaux Application. Nous pouvons chercher cet évènement dans le journal Application avec la commande suivante :

Get-EventLog Application |
Where-Object {$_.EventID -eq 11707}

Cette commande renverra un listing de tous les évènements du journal des applications dont l’ID est 403 Pour effectuer notre BVT, nous ne nous intéressons qu’à un champ particulier du journal d’évènement : le message de retour.

Get-EventLog Application |
Where-Object {$_.EventID -eq 11707} |
Where- Object {($_.message -eq "Product: Microsoft Office Enterprise 2007
–Installation operation completed successfully")}

Cette commande renverra l’entrée recherchée et ne donnera pas de résultats si l’installation ne s’est pas bien déroulée. Nous voyons avec cette commande que nous recherchons une propriété particulière (‘message’) de l’objet contenu dans le journal. Voyons plus en détail avec le test suivant comment ces propriétés peuvent être manipulées.

2. Vérification des Process
La commande Get-Process permet de facilement lister les Process qui tournent sur un système et de récupérer des informations supplémentaires les concernant en attaquant les nombreuses propriétés de ces objets. Pour vérifier si Office Word tourne bien sur le système, on peut utiliser la commande Get-Process winword Cette commande nous renverra des informations sur le Process Winword en affichant les valeurs des propriétés par défaut : voir listing 1.

PowerShell permet d’aller bien plus loin que ce simple listing en nous donnant la possibilité d’explorer les dizaines de propriétés et méthodes supplémentaires liées à cet objet. Ainsi, pour notre BVT, nous voudrons également vérifier que c’est bien la bonne version d’Office Word qui est installée.

En ‘pipant’ notre commande vers la commande selectobject, nous pourrons spécifier la propriété « Product Version » de cette commande :

get-process winword |
select-object ProductVersion

 Cette commande nous renverra le numéro de version du Process : voir listing 2. Pour lister l’ensemble des propriétés et méthodes liées à un objet, utilisez la commande get-member. Nous nous contenterons de vérifier le numéro de version d’Office Word dans cet exemple, mais des dizaines d’autres propriétés sont disponibles pour chaque objet. Pour en avoir la liste, piper la commande de l’objet vers la commande ‘Get-Member’‘.

Par exemple :

Get-process |
get-member

La commande get-member est extrêmement pratique car elle peut être utilisée avec n’importe quel objet et listera les propriétés et méthodes liées. L’alias de la commande : « gm » est donc une des premières dont l’utilisateur PowerShell se souviendra.

3. Vérification des Services
Une grande série de verbes sont associables à l’objet Service et permettent de les lister, de les gérer et même de les créer : Get-Service New-Service Restart-Service Resume-Service Set-Service Start-Service Stop-Service Suspend-Service

Pour notre BVT, nous allons utiliser la possibilité offerte par PowerShell d’aller récupérer des propriétés avancées de l’objet service. Vérifions d’abord la présence du service que nous voulons tester. Nous allons vérifier que le service Office Diagnostics est correctement installé.

La commande Get- Service couplée avec le paramètre « DisplayName » permet d’effectuer une recherche par nom de service : Get-Service -DisplayName "Microsoft Office Diagnostics Service"

PowerShell renverra les propriétés de base du service : voir listing 3.

Pour effectuer notre BVT, vérifions que ce service est bien présent mais arrêté (Status = Stopped) et qu’il pourra bien être lancé par le contrôleur de service et qu’il obéit au protocole du contrôleur.

(Service-Type =Win32OwnProcess) Get-Service -DisplayName
"Microsoft Office Diagnostics Service"|
select-object Status, ServiceType

Cette commande renverra le statut des 2 propriétés du service : voir listing 4.

4. Vérification de la base de registre
Attaquer la base de registre est très simple avec PowerShell. Il est capable d’énumérer tout objet présent dans un lecteur du système. Un lecteur, peut être un disque logique ou quelque chose de complètement différent en fonction du provider utilisé. La commande Get-Psdrive permet de lister tous les lecteurs présents sur un système : voir listing 5.

Comme on peut le voir, les lecteurs habituels (C :, D :, etc…) sont listés mais nous avons également accès à HKCU, HKLM ou à Env ! Avec la même facilité que pour naviguer dans le lecteur C:\, PowerShell offre la possibilité d’explorer le ‘lecteur’ de la base de registre. Pour explorer son contenu, il faut utiliser la commande get-env et fournir le chemin complet vers la clé. Pour notre test, vérifions simplement que le chemin d’installation d’Office est bien le bon.

Avec cette commande, nous naviguons dans la base de registre jusqu’à la clé qui nous intéresse : voir listing 6. Notez que lorsque l’on utilise la commande « get-item ‘HKLM:\ » L’on peut utiliser la touche TAB et que le chemin dans l’arborescence de la base de registre sera complété. La valeur qui nous intéresse est contenue dans le string « Path » situé dans cette clé, nous pourrons donc la récupérer avec la commande Get-ItemProperty :

Get-Item ‘HKLM:\SOFTWARE\Microsoft\Office\12.0 \Word\InstallRoot’|
select-Object {Get-ItemProperty $_.pspath}

Ceci nous renverra le chemin d’installation d’Office Word:

Get-ItemProperty $_.pspath ————————– @
{Path=C:\Program Files\Microsoft Office\Office12\}

5. Groupement des tests et rendu du résultat
L’objectif de cet exemple était de montrer à quel point il est facile d’interagir avec des éléments de base de l’environnement avec PowerShell et non d’effectuer un BVT exhaustif d’Office Word. Bien d’autres éléments pourraient être vérifiés pour étoffer ce test, mais complétons l’exercice pour encore découvrir quelques fonctions intéressantes de PowerShell.

Tout d’abord, pour rendre les tests plus lisibles, les scripts peuvent être intégrés dans une petite fonction qui renverra simplement un statut ‘Pass’ ou ‘Fail’ de nos tests.
Par exemple, pour le premier test de vérification des logs, nous pourrions faire ceci :

$TestLogs = Get-EventLog Applica-tion |
Where-Object {$_.EventID -eq 11707} |
Where-Object {($_.message -eq "Product: Microsoft Office Enterprise 2007 –Installation operation completed successfully")}
if ($TestLogs.length -gt 1) {return "Test Logs: Fail"}
else {return "Test Logs: Pass"}

En plaçant chaque test dans ce type de structure, nous obtiendrons une suite de test renvoyant les résultats Fail ou Pass. En sauvegardant chaque script dans un fichier .ps1, nous pouvons ensuite créer une fonction qui lancerait tous les tests l’un après l’autre et affiche-rait un rapport. Sauvegardez ce script dans un fichier .ps1 et placez tous les scripts des tests dans un sous-dossier nommé « BvtTests ».

$report ="" $list = Get-ChildItem ./BvtTests/ -recurse -name -Include
*.ps1 foreach ($_ in $list ){ $count = $count +1} "Number of Tests "
+$count foreach ($file in $list) { "Running Test " + $file Invoke-Expression .\BvtTests\$file }

 Ce script lancera tous les tests contenus dans le dossier bvtTests et affichera un rapport d’exécution : voir listing 7.

Conclusion

 Ce rapide exemple de test de vérification du système ne nous aura fait qu’entrevoir la puissance du langage de script PowerShell mais aura surtout montré à quel point PowerShell est intégré au système. Ce n’est pas un langage qui a été développé indépendamment de l’environnement et qui s’interface avec lui par le biais de fonction, mais on a plutôt l’impression que l’environnement lui-même tourne sous PowerShell et que cet outil nous permet de voir l’envers du décor !

Et les nouveaux produits de Microsoft renforcent cette impression. Par exemple, sous Exchange 2007, toutes les fonctionnalités administratives sont construites sous forme de cmdlets PowerShell et l’interface de la console MMC fait effectivement appel à ces fonctions ! Ainsi, l’utilisateur peut visualiser l’équivalent en code PowerShell de n’importe quelle action qu’il effectue dans la GUI… et réutiliser ce code sur un autre système !

À l’heure où tant de produits Micro-soft apparaissent ou subissent des mises à jour (Vista, W2K8, SCCM, Ex-change, SQL, …), la sortie de PowerShell s’est faite assez discrètement mais il est pourtant bien présent et lié intimement à chacun de ces produits ! La question de ‘se mettre’ ou pas à PowerShell ne se pose donc même pas : les produits Microsoft que nous utilisons tous les jours l’intègrent déjà intensivement.