Flash info

"Those who forget to script are doomed to repeat their work."

Jeffery Hicks (PowerShell MVP)

 
Accueil arrow Articles / Tutoriaux arrow Aperçu de la préversion de PowerShell V2.0
Aperçu de la préversion de PowerShell V2.0
Écrit par Batchman   
12-03-2008

 

Aperçu de la préversion de PowerShell V2.0

 


Microsoft à publié début novembre 2007 une CTP de PowerShell V2.0. Voyons ce que cette Community Technical Preview propose comme possibles évolutions et orientations.

Note :

Une CTP qui n'est pas une beta indique que certaines fonctionnalités peuvent ne pas être intégrées dans la version finale qui elle est nommée une RTM, acronyme de Released to Manufacturing.

L'usage de cette préversion nécessite de désinstaller la version 1.0 de PowerShell. Consultez le fichier releaseNotes.rtf pour plus d'informations.

Télécharger la CTP et le SDK associé.

Le remoting

Jusqu'à maintenant Powershell proposait nativement l'exécution de code sur un ordinateur distant via WMI (Get-WMIObject). WMI s'appuyant sur DCOM (Distributed COM) il est parfois difficile de passer un firewall qui, pour des raisons de sécurité, bloquent le trafic DCOM.

Microsoft propose de nombreuses améliorations autour des Web Services (voir WSE, Web Services Enhancements) notamment WS-Management basé sur le protocole SOAP qui consiste à sérialiser les données en XML au dessus de HTTP; ainsi cela ne pose plus de problème pour traverser les firewalls. Avec WS-Management les échanges entre serveurs sont cryptés.

Cet ensemble étant une brique de base du Framework .NET il n'est pas étonnant de le retrouver ici.

Le remoting de Powershell V2 s'appuie sur Windows Remote Management (WinRM) qui n'est autre que l'implémentation du protocole WS-Management. Chaque machine devra donc posséder cette couche, présente sous forme de service.

Une fois l'installation de WS-Management effectuée, le service WinRM doit être démarré sur la machine locale et sur le ou les PC distants :

  • Start-Service WinRM

Note :

Le setup installe des fichiers .adm, une classe et un provider WMI ainsi qu'un objet COM, voir la TLB WSMauto.dll. Il est peut être possible d'utiliser WinRM avec PowerShell 1.0 ...

Ensuite configurer Windows remoting en exécutant le script Configure-Wsman.ps1 présent dans le répertoire d'installation de PowerShell :

> .\Configure-Wsman.ps1

Lors de mes premiers tests sur un LAN, j'ai du autoriser, sur le PC local, le ou les pc distant dans la liste des machines autorisées :

winrm s winrm/config/client '@{TrustedHosts="Server01"}'

L'exécution d'une commande sur une machine distante se fait via l'appel du cmdlet invoke-expression :

 invoke-expression -computername Server01 -command "Get-Process"

Cette instruction récupère en local la liste des processus en cours d'exécution sur la machine distante Server01. Il est tout à fait possible d'exécuter une instruction identique sur une centaine de serveurs. Dans ce cas on peut récupérer les noms des serveurs à partir d'un fichier texte :

invoke-expression -computername (Get-Content W:\Repository\all-serveur.txt) -command "Get-Process"

Il va s'en dire que dans ce cas les ressources de la machine locale seront très sollicitées. Notez qu'on ne peut exécuter qu'une suite d'instructions à la fois et par défaut il n'y a pas, sur les machines distantes, de persistance des informations de sessions entre 2 appels.

Pour ce faire on doit utiliser le paramètre RunSpace.

Note :

L'usage de la commande invoke-expression lors de l'analyse d'une telle ligne de commande par PowerShell amène un problème potentiel au niveau de la gestion des simples et doubles quotte, cf. Windows PowerShell 2.0 CTP. Remoting Quoting

La notion de Runspace

Un runspace, ou environnement d'exécution, fournit les mécanismes de communication entre le runtime de Powershell et une application d'accueil, par défaut le Host du graphique ci-dessous n'est autre que Powershell.exe mais cela pourrait être une autre application hébergeant le runtime Powershell.

runspace.gif

                                                                                        © Msdn - Microsoft

Note :

MakeKit est un outil de développement disponible avec le  SDK Windows nommé Make-Shell.exe. Il permet de générer une version spécifique de PowerShell en y intégrant des cmdlets externes.

Chaque création d'un runspace crée un thread dédié, en ce sens on pourrait également parler de contexte d'exécution, un runspace est en quelque sorte une abstraction du runtime de PowerShell. Ils permettent, entre autre, l'exécution en parallèle de bloc de script.

Techniquement, un runspace est un environnement d'exécution dans lequel fonctionne Windows PowerShell. Chaque runspace inclut une instance du moteur de System.Management.Automation qui définit une session de Windows PowerShell et un programme d'accueil dans lequel Windows PowerShell fonctionne.

Après qu'un runspace ait été créé et ouvert, les applications d'accueil peuvent exécuter dans ce contexte d'exécution les scripts de démarrage incluant les scripts de profils et d'initialisation (dans ce cas on peut aussi parler de session PowerShell).

Le runspace ne fournit pas d'affichage. Les données sont retournées à l'application d'accueil par les pipelines s'exécutant dans le runspace.

Dans l'exemple suivant la dernière commande n'est autre que la configuration du runspace initiale de PowerShell à l'aide d'un fichier de configuration XML:

PS > add-pssnapin NewPSSnapIn

PS > export-console -path NewPsSnapinConsole.psc1

C:> powershell.exe -PsConsoleFile NewPsSnapinConsole.psc1

Chaque exécution de PowerShell crée un runspace. Il est possible d'en créer sur la machine locale ou sur une machine distante.

Il autorise dans le premier cas l'exécution de code en parallèle (voir sur le blog de Janel cet exemple sous PowerShell V1.0) et dans le second cas, et dans un contexte de remoting au travers de l'usage du paramètre runspace de la commande Invoke-Expression, la persistance des données d'une session de PowerShell entre 2 appels.

Lors de l'exécution d'une commande sur de multiples serveurs, l'affichage du résultat se fait sans aucun regroupement par nom de machine. Dans ce cas l'information d'identifiant de runspace peut être utilisée pour regrouper les données :

PS > invoke-expression -computername SERVER01,SERVER02 -command "get-process"|`
sort runspaceid| ft -group runspaceid

RunspaceID: 0b4ed86e-cc6d-48d3-b55b-b86452eec338

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- ----------- 
  842      78    45988       3312   167   848,36   1616 kavsvc

...   

Cmdlet dédiés au runspace :

Voir aussi :

About_Runspace

PowerShell Hosting

Un script fonctionnel pour PowerShell v1.0 utilisant les runspaces.

Le coin des développeurs, How Windows PowerShell Works.

Note :

De nouvelle APIs font leur apparition notamment la manipulation de pool de runspace et les runspaces contraints. Contraintes portant sur l'accès et l'exécution de cmdlet, de script et ou d'instruction du langage. On peut supposer que leurs usages permettront de brider une application d'accueil de PowerShell.

Commandes en tâche de fond (Background Jobs)

Windows PowerShell 2.0 introduit le concept de travail en tâche de fond (PS Job). Un PS Job exécute une commande ou une expression de manière asynchrone et en arrière plan sans interagir avec la console. L'exécution d'une telle commande rend immédiatement la main, vous pouvez par la suite et à votre convenance interroger le pool de jobs. Ces jobs peuvent être exécutés sur un ordinateur local ou distant.

Cmdlet dédiés au Job:

  • Start-Job
  • Receive-Job
  • Remove-Job
  • Wait-Job
  • Get-Job

Pour approfondir les notions de jobs et de remoting consultez ce chapitre gratuit proposé par l'éditeur d'outils de Scripting Sapiens.

Les extensions WMI

Windows PowerShell 2.0 proposes 3 nouveaux cmdlets:

Cet article passe en revue ces nouveaux cmdlets propres à WMI, certains ne sont que des facilités d'écriture. Leur usage permet de réduire le nombre d'instructions nécessaire à la manipulation d'instance WMI.

Par exemple la suite de commandes suivante :

$a = Get-WMIObject Win32_WMISetting -computername atl-fs-001

$a.LoggingLevel = 2

$a.Put()

Devient :

Set-WMIInstance -class Win32_WMISetting -argument @{LoggingLevel=2} -computername atl-fs-001

Le cmdlet Get-WMIObject propose de nouveaux paramètres afin de faciliter la gestion de l'authentification sur des machines distantes. Ces nouveaux paramètres sont :

-Impersonation, -Authentication, -Locale, -EnableAllPrivileges, -Amended, -DirectRead, -Authority.

Les évolutions du débogage sous PowerShell

De nouvelles fonctionnalités facilitant le débogage ont été ajoutées, telles que la pose de point d'arrêt sur une ligne, une variable, une fonction ou une commande d'un script sont désormais possible. Il est également possible de spécifier une action particulière lors du déclenchement d'un point d'arrêt.

Les cmdlets dédiés au débogage :

  • New-PSBreakPoint
  • Get-PSBreakPoint
  • Enable-PSBreakPoint
  • Disable-PSBreakPoint
  • Remove-PSBreakPoint
  • Step-Into
  • Step-Over
  • Step-Out
  • Get-PSCallStack

Pour plus de détails consulter l'article suivant The PowerShell Debugger

Le cmdlet Out-GridView

Ce nouveau cmdlet permet l'affichage de données au sein d'un composant fenêtré, la recopie suivant affiche le regroupement de service par statut :

 out-gridview.jpg
  

 

 

 

 

 

 

 

 

 

 

© Msdn - Microsoft

L'usage de ce cmdlet requiert le Framework Microsoft .NET 3.0.

Pour plus de détails sur ce cmdlet consulter l'article suivant, Out-GridView: Displaying Information in a Data Grid

Console PowerShell graphique

Cette CTP propose une console graphique, nécessitant le Framework 3.0, en version beta : "This release includes a very early alpha version of the new graphical shell."

consolegraphiqueps.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

                                                   © Msdn - Microsoft

Pour plus de détails sur le sujet consulter l'article suivant, Sneak Peek: Graphical PowerShell

L'internationalisation de scripts

Cette nouvelle fonctionnalité permet d'écrire des scripts de manière à ce qu'ils soient traduits dans les langues supportées par Windows. Il est désormais possible de séparer la gestion des chaînes de caractères du reste du code via des fichiers ressources.

En utilisant le nouveau cmdlet Import-LocalizedData, vous pouvez  demander à PowerShell de vérifier la langue du système d'exploitation et de remplacer les chaînes de ressources  à partir d'un fichier de données traduit (psd1) présent dans le dossier de culture approprié (telle que en-US, ou fr-Fr : $host.CurrentUICulture)

Exemple :

Data msgs{

ConvertFrom-StringData @"
Usage = "Usage: Get-Process Name <name>"
NoSuchProc= "No such Process Found"
"@
}

Import-LocalizedData-Bind msgs
....
Throw $msgs.NoSuchProc

 Les cmdlets dédiés:

ScriptCmdlets

Il sera désormais possible de créer Cmdlets au sein de script et non plus uniquement via du code compilé .NET.

D'autres informations sur le sujet.

La suite...

Il existe de nombreux autres ajout ou modifications, vous pouvez en consulter la liste sur le blog de l'équipe de PowerShell ou encore mieux en installant cette préversion sur une machine de test ;-)

A noter qu'en page 10 de ce document, l'équipe de développement de PowerShell V2.0 proposerait un gestionnaire d'événement ainsi, cf. pg 21, que des packages.

La gestion d'événements pouvant être un complément appréciable pour, entre autres, la gestion de PSjob ou encore associer du code à une méthode de callback WMI.

On peut voir que ces possibles évolutions faciliteront l'écriture de scripts après ces premiers pas il me reste le sentiment que PowerShell devient un langage de développement au même titre que le C#.

Voir aussi :

La page dédiée à la CTP 2.0.

Les fichiers d'aide en ligne de la CTP.

Pour les curieux, document préparatoire des spécifications de WS-Management.

 
Dernière mise à jour : ( 20-03-2008 )
 
© 2017 PowerShell-Scripting.com