Un point sur PowerShell v2.0

Quoi qu’il en soit, cette nouvelle version apporte un grand nombre de nouvelles fonctionnalités, dont voici les plus importantes (dans le désordre) :

Exécution de scripts à distance (Remoting)

Il est maintenant possible de faire exécuter un script sur une ou plusieurs machines distantes. On peut aussi ouvrir une console PowerShell à distance sur une machine en particulier et exécuter des commandes sur cette dernière comme sur une machine locale.

Cette fonctionnalité (Remoting) repose sur la brique logicielle appelée WinRM qui signifie Windows Remote Management. WinRM est l’implémentation de Microsoft du protocole standard WS-Management qui repose sur le couple SOAP / XML. Il s’agit donc d’un protocole dit « firewall friendly » car il permet de franchir facilement les routeurs et pare-feux.

Jobs en arrière plan

Les « jobs » sont des commandes qui sont lancées de façon asynchrone (en arrière plan). Lorsque qu’un job s’exécute, la main est instantanément rendue à l’utilisateur sans attendre la fin d’exécution du script. Les jobs peuvent être lancés localement ou sur des machines distantes.

Editeur de scripts (Integrated Scripting Environment – ISE)

Un éditeur de scripts est maintenant de la partie, ce qui est vraiment très pratique ! Grâce à lui, exit le bon vieux Bloc Notes et vive la coloration syntaxique, l’affichage des numéros de lignes, le débogueur intégré, et l’aide en ligne en mode graphique. On a également la possibilité d’ouvrir une console PowerShell sur une machine distance directement dans l’éditeur. On peut cependant lui reprocher le manque de la fonctionnalité « Intelli Sense » comme dans l’éditeur de Visual Studio. Ceci étant, si cette fonctionnalité vous est chère, sachez qu’elle est apportée gratuitement par PowerGUI Script Editor de la société Quest Software. Voir Figure 1.

Modules

Un module est une sorte de conteneur qui permet de regrouper des scripts PowerShell. L’avantage est de pouvoir créer des scripts qui s’appuieront sur d’autres scripts présents dans vos modules ; ce qui évitera par exemple d’avoir à inclure le contenu d’un script dans le script en cours de développement. Cela permet de faciliter la maintenance des scripts, et permet également le partage de modules entre utilisateurs de PowerShell.

Meilleur support de WMI

L’interaction avec les classes WMI a été facilitée grâce à l’apport de commandes supplémentaires ainsi qu’à de nouveaux paramètres relatifs à la sécurité. • Notification des évènements Un utilisateur peut désormais souscrire ou s’abonner aux évènements systèmes. Ces derniers peuvent provenir de PowerShell, de WMI ou bien encore du Framework .Net. Par conséquent, il devient possible de faire des scripts qui réagissent à certains évènements comme, par exemple, l’insertion d’une clé USB, la création de fichiers dans un dossier, ou le dépassement de quotas disque.

Internationalisation

Dans la version 1, l’édition de scripts destinés à un public constitué de personnes de nationalités différentes n’était pas chose évidente, l’éditeur se devait de traduire manuellement tout le contenu textuel de ses scripts. Dans PowerShell v2, apparait ce que l’on appelle « l’internationalisation de script ». Le principe est de permettre l’écriture de scripts en différentes langues sans pour autant modifier le code contenu dans le script. Par exemple si vous créez un script et que celui-ci doit être exécuté par plusieurs personnes, chacune utilisant une version de PowerShell différente en termes de langage. Et bien le fait d’utiliser l’internationalisation, permettra aux utilisateurs d’obtenir toute la partie textuelle du script dans leur langue, et ce, sans aucune configuration de leur part.

Débogage

On peut désormais créer des points d’arrêts et faire de l’exécution pas à pas.