Premiers pas avec PowerShell 3.0

Bonjour à tous, je devance l’ouverture de mon blog car un évènement à chamboulé tout mon planning. Et oui, avec la sortie de la « developer preview » de Windows 8, on a eu le droit à une mise à jour (et pas une petite) de PowerShell. Ce dernier passe donc en version 3 !

Tout d’abord, qu’est-ce que PowerShell ? PowerShell est un outil en ligne de commande qui a été introduit à l’époque de Vista. Ce projet avait été présenté sous le nom de code Monad à la PDC en Septembre 2003.

Vous découvrirez dans ce premier article les nombreuses fonctionnalités ajoutées dans cette nouvelle version.

On parlera dans cet article de PowerShell en général mais aussi, en deuxième partie, de l’éditeur PowerShell ISE qui a lui aussi eu droit à un rafraîchissement.

Les nouveautés de la console PowerShell V3

Après avoir installé Windows 8 (build 8102) ; j’ai immédiatement lancé l’application Desktop pour me retrouver sur un bureau de type Windows 7. A ce stade, j’étais un peu perdu car le menu Démarrer n’existe plus.

Mais heureusement PowerShell n’a pas bougé et on retrouve donc les binaires sous le chemin : C:\Windows\System32\WindowsPowerShell\v1.0

Emplacement de PowerShell 3.0 dans Windows 8

C’est parti ! Voyons la version de ce fameux PowerShell :

PS C:\Users\richard.lazaro> $Host.Version

Major Minor Build Revision
----- ----- ----- --------
3 0 -1 -1

Jusque-là tout va bien, on est bien en version 3 et cela annonce plein de bonne chose à se mettre sous la dent ! Allons voir la version du Framework .Net utilisée :

PS C:\Users\richard.lazaro> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      3.0
PSCompatibleVersions           {1.0, 2.0, 3.0}
BuildVersion                   6.2.8102.0
CLRVersion                     4.0.30319.17020
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.103
SerializationVersion           1.1.0.1

On s’aperçoit que ce fameux PowerShell 3.0 tourne sous le Framework 4.0. J’espère honnêtement qu’il tourne aussi sous une version antérieure ; car quand on voit l’adoption des évolutions technologiques chez les grands comptes je me demande si cette version 3.0 pourra être utilisée rapidement en production.

C’est maintenant qu’on relève les manches et part faire un tour dans les cmdlets de PowerShell. Première chose qui m’a surprise, PowerShell ne charge plus des snapin mais des modules pour son initialisation (en effet, PowerShell et à la base une boîte vide à laquelle été rajouté des snapins (Microsoft.PowerShell.Core, Microsoft.PowerShell.Management, etc.) dans les versions 1.0 et 2.0). Ici comme je l’ai dit, ce sont des modules :

PS C:\Users\richard.lazaro> Get-PSSnapin
PS C:\Users\richard.lazaro> Get-Module

ModuleType Name ExportedCommands
---------- ---- ----------------
Manifest Microsoft.PowerShell.Core {Add-History, Add-PSSnapin, Clear-History, Connec...
Manifest Microsoft.PowerShell.M... {Add-Computer, Add-Content, Checkpoint-Computer, ...
Manifest Microsoft.PowerShell.U... {Add-Member, Add-Type, Clear-Variable, Compare-Ob...

On a toujours à disposition la cmdlet Add-PSSnapin pour le support des anciens snapins comme celui de VMware, pour la gestion des ESX.
En terme de quantitatif (pour les modules, on parle de ceux présent par défaut sur l’OS client) :

  PowerShell 1.0 PowerShell 2.0 PowerShell 3.0
Cmdlet 129 236 376
Function 34 37 522
Alias 101 137 146
Snapin 5 7 0
Module n/a 4 44

On a vraiment fait un bond en avant dans cette version, le nombre de cmdlet/function a été triplé. Par contre, je trouve que la gestion des modules est confuse. Comme on l’a montré précédemment, on a uniquement 3 modules de chargés par défaut mais lorsqu’on exécute la cmdlet Get-Command, cette dernière nous remonte les cmdlets d’autres modules :

PS C:\Users\richard.lazaro> Get-Command | Group-Object ModuleName

Count Name Group
----- ---- -----
182 {%, ?, ac, asnp...}
64 Storage {Initialize-Volume, Add-InitiatorIdToMaskingSet, Add-P...
5 Appx {Add-AppxPackage, Get-AppxLastError, Get-AppxPackage, ...
31 BranchCache {Add-BCDataCacheExtension, Clear-BCCache, Disable-BC, ...
49 BitLocker {Add-BitLockerKeyProtector, Add-BitLockerPassphrasePro...
15 DnsClient {Add-DnsClientNrptRule, Clear-DNSClientCache, Get-DNSC...
7 DnsNrpt {Add-DnsClientNrptRule, Get-DnsClientEffectiveNrptPoli...
41 MsDtc {Add-DtcClusterTMMapping, Get-Dtc, Get-DtcAdvancedHost...
37 NetworkTransition {Add-NetIpHTTPsCertBinding, Disable-NetDnsTransitionCo...

La cmdlet Get-Command affiche toutes les commandes présentes même celles dans des modules non chargés, car PowerShell 3.0 apporte une fonctionnalité d’ajout dynamique des modules ; Quand on utilisera une commande qui est présente dans un module non-chargé, ce dernier se chargera automatiquement :

PS C:\Users\richard.lazaro> Get-Module

ModuleType Name ExportedCommands
---------- ---- ----------------
Manifest Microsoft.PowerShell.Core {Add-History, Add-PSSnapin, Clear-History, Connec...
Manifest Microsoft.PowerShell.M... {Add-Computer, Add-Content, Checkpoint-Computer, ...
Manifest Microsoft.PowerShell.U... {Add-Member, Add-Type, Clear-Variable, Compare-Ob...

PS C:\Users\richard.lazaro> Resolve-DnsName -QueryName www.google.fr

NameHost : www.google.com
Name : www.google.fr
Type : CNAME
CharacterSet : Unicode
Section : Answer
DataLength : 4
TTL : 86

NameHost : www.l.google.com
Name : www.google.com
Type : CNAME
CharacterSet : Unicode
Section : Answer
DataLength : 4
TTL : 86

...

PS C:\Users\richard.lazaro> Get-Module

ModuleType Name ExportedCommands
---------- ---- ----------------
Manifest DnsClient {Resolve-DnsName, Add-DnsClientNrptRule, Clear-DN...
Manifest Microsoft.PowerShell.Core {Add-History, Add-PSSnapin, Clear-History, Connec...
Manifest Microsoft.PowerShell.M... {Add-Computer, Add-Content, Checkpoint-Computer, ...
Manifest Microsoft.PowerShell.U... {Add-Member, Add-Type, Clear-Variable, Compare-Ob...

Comme on peut l’observer, le module DnsClient est ajouté automatiquement après l’utilisation de la cmdlet Resolve-DnsName (nouvelle cmdlet) faisant partie de ce module.

TIPS : Lors de l’appel d’une cmdlet, il est maintenant possible de spécifier de quel module elle provient sous la forme <module>\<cmdlet> :

PS C:\Users\richard.lazaro> DnsClient\Resolve-DnsName -QueryName www.google.frNameHost : www.google.com
Name : www.google.fr
Type : CNAME
CharacterSet : Unicode
Section : Answer
DataLength : 4
TTL : 86

On va s’arrêter ici pour le petit tour de la console PowerShell, passons maintenant à l’éditeur fourni en natif : PowerShell ISE

Les nouveautés de l’éditeur ISE PowerShell

Comme sur PowerShell 2.0 avec Seven, on retrouve le fameux éditeur ISE qui n’était pas vraiment complet. Microsoft a eu la gentillesse de rafraîchir cet éditeur pour rajouter de nouvelles fonctionnalités !

IntelliSense par défaut

Cette version apporte l’IntelliSense (l’IntelliSense est la version de Microsoft de l’auto-complétion) au sein de l’éditeur et elle n’est pas trop mal implémentée :

IntelliSense sur les cmdlets

On peut constater qu’elle nous remonte les commandes ayant pour verbe Get mais qui contient la chaîne Pro et non qui commence par Pro (ce comportement de l’IntelliSense avait fait son apparition avec Visual Studio 2010). Cela va faciliter la recherche des commandes au sein, je le rappelle, des 1000 commandes par défaut ! Le menu déroulant est accompagné d’une info-bulle, sur la commande qu’on a en surbrillance, qui contient la syntaxe de la commande.

Mais l’IntelliSense ne s’arrête pas là, elle fonctionne aussi sur les paramètres et les valeurs de ces derniers (c’est vraiment bon ça :]) :

IntelliSense sur les parametres et valeurs

Bien sûr, l’IntelliSense fonctionne aussi dans l’éditeur de script mais une autre surprise nous attend dans celui-ci.

La gestion des régions

PowerShell ISE sait dorénavant interpréter les régions, cela va permettre de « réduire » un bloc de code et donc d’avoir un script plus lisible surtout quand il fait 4000 lignes. Eh oui, avant il fallait passer par un éditeur comme PowerGUI pour gérer les régions mais c’est du passé :

Gestion des regions dans ISE

Il y’a une option « Show Outlining (Regions) » dans le menu View qui permet d’activer/désactiver cette fonctionnalité.

Et le dernier ajout que je vais vraiment survoler cette fois, est une GUI (Graphical User Interface, interface graphique) pour appeler les commandes.

Constructeur de commandes

Interface de gestion des commandes

Quand on ouvre l’éditeur, un panel sur la droite doit vous attirer le regard.

Ce dernier va permettre de construire les commandes d’une manière plus intuitive. Il propose la liste des commandes, même celles dont le module n’est pas chargé.

Si on en sélectionne une (dont le module est chargé par contre), un formulaire va apparaître fournissant ainsi une aide pour remplir les différents paramètres.

Ici, si on sélectionne la commande Get-WmiObject, le formulaire nous aidera à sélectionner la classe, les propriétés, le filtre, etc. Et on a trois boutons en bas qui vont permettre de placer la commande dans le presse papier (Copy), de l’insérer dans l’invite de commande (Insert) ou de directement l’exécuter (Run).

Nous retrouvons cette interface via la cmdlet Show-Command, cette dernière fait apparaître une fenêtre WPF identique à l’Add-On ISE.

Un article un peu plus détaillé viendra sur cette fonctionnalité vraiment très complète.

 

J’espère que ce premier article vous aura inéressé et j’attends vos réactions dans les commentaires.

A bientôt pour de prochaines aventures autour de PowerShell et l’infrastructure.

  1. Excellent article ! Merci pour toutes ces précisions, je vais de ce pas tester toutes ces fonctionnalités !

    • Florent
    • septembre 19th, 2011

    Merci pour l’article, bien sympa la v3 :)

    • YvesCa
    • septembre 19th, 2011

    Enfin un (très) bon article français sur le PowerShell v3 :)

    Je vois aussi que Microsoft a l’air d’abandonner les Snapins…

  2. salut,

    merci pour cet article interessant, j’espère que cette version implémentera une gestion plus complète des « Transactions »

  1. No trackbacks yet.