À la découverte de PowerShell

Présentation de PowerShell

PowerShell est à la fois un interpréteur de commandes et un puissant langage de scripts. Il tire sa puissance en grande partie grâce au Framework .NET sur lequel il s’appuie. Bien connu des développeurs, le Framework .NET l’est en revanche beaucoup moins des administrateurs système et autres développeurs de scripts ; ce qui est normal... Pour vulgariser en quelques mots, le Framework .NET est une immense bibliothèque de classes à partir desquelles nous ferons naître des objets ; objets qui nous permettront d’agir sur l’ensemble du système d’exploitation en un minimum d’effort. Tous ceux qui ont goûté à la puissance du Framework .NET ne tariront pas d’éloges à son égard. C’est donc grâce à ce dernier que PowerShell tire toute son intelligence ainsi que sa dimension objet. Et c’est d’ailleurs cette faculté à manipuler les objets qui fait de PowerShell un shell d’exception !

Avec PowerShell vous ne manipulerez donc plus uniquement du texte, comme c’est le cas avec la plupart des autres shells, mais des objets ; et ce, sans vraiment vous en rendre compte. Par exemple, lorsque vous utiliserez le pipe « | » pour passer des données à une commande, eh bien vous ne transmettrez...

Historique des versions

C’est dans les années 2003-2004 que la firme de Redmond comprit qu’il lui manquait un véritable langage de scripts homogène mais surtout qu’il était temps que tous les produits de la gamme System Center puissent être administrables entièrement en lignes de commandes.

C’est ainsi que le projet Monad vit le jour, projet qui donna naissance fin 2006 à la première version de PowerShell. Jusqu’à la version 3, le rythme de sortie des versions se faisait tous les trois ans, ce qui correspondait à celui des versions de Windows. Depuis 2012, le rythme s’est nettement accéléré et le cycle a été réduit de moitié, soit une nouvelle version tous les dix-huit mois. Ce rythme soutenu n’est pas un hasard ; il est le fruit de l’adoption de la démarche Agile au sein de Microsoft qui consiste à sortir des produits plus souvent mais avec moins de nouvelles fonctionnalités. Cette démarche s’oppose à celle utilisée jusqu’alors qui consistait à sortir une nouvelle version majeure contenant de nombreuses évolutions mais à un rythme nettement plus lent. Ce nouveau paradigme s’inscrit en plein dans la démarche DevOps dont nous aurons l’occasion de reparler plus longuement… Monad

Historique de sortie des versions

2016 est une date clé dans le petit monde PowerShell car cette année vit apparaître la première version de PowerShell, appelée « PowerShell Core ». Celui-ci s’appuie désormais non plus sur le Framework .NET mais sur .NET Core (nous aurons l’occasion de reparler plus longuement dans le chapitre Framework .NET et .NET Core). Net Core est la déclinaison open source du Framework .NET. PowerShell Core sort donc officiellement en version 5.1 et il fait partie de Windows Server Nano appelé également « Nano Server ». En parallèle de cela, quelques mois auparavant, Microsoft publiait sur Github.com le code source de PowerShell et le libérait sous licence MIT. PowerShell devint alors officiellement open source et multiplateformes grâce à la portabilité intrinsèque de .NET Core, lui-même également multiplateformes.

La sortie de Windows Server 2016 est une date importante dans l’éco-système PowerShell car elle est aussi synonyme de rupture. En effet, on se trouve désormais avec deux versions distinctes de PowerShell que sont « Windows PowerShell 5.1 » et « PowerShell...

Plateformes supportées

Prise en main

En plus de la console en ligne de commande, il existe depuis la version 2.0 un appréciable environnement de développement de scripts PowerShell en mode graphique appelé PowerShell ISE. L’avantage de ce dernier est qu’il est installé de base sur toutes les versions de Windows. Son « inconvénient » est qu’il ne prend en charge que Windows PowerShell. Par conséquent, il laisse de côté PowerShell Core.

C’est la raison pour laquelle, depuis peu, Microsoft met en avant un nouvel environnement de développement multiplateforme appelé Visual Studio Code. Ce dernier est polyvalent car il prend en charge toutes les éditions de PowerShell et il est disponible sur toutes les plateformes (Windows, Mac, Linux).

Dans un premier temps, nous nous intéresserons à la console « classique », console que nous pourrions qualifier d’« historique » du fait qu’elle existe depuis la toute première version.

1. Console Windows PowerShell classique

a. Démarrage de la console

Lorsque l’on démarre la console PowerShell, il faut savoir que cette dernière s’exécute avec des droits de simple utilisateur et donc limités ; et ce, même si l’on a ouvert notre session avec un compte administrateur. Ne soyez donc pas surpris si vous vous voyez l’accès refusé à certains répertoires, à certaines clés de registre ou à certaines commandes. Ceci est dû au mécanisme de sécurité bien connu nommé « User Account Control » (UAC) pour « contrôle de comptes d’utilisateurs » en français.

Pour ouvrir une console classique ou graphique (ISE) avec le privilège Administrateur, vous devez systématiquement effectuer un clic droit sur l’icône PowerShell (ou PowerShell ISE) et choisir Exécuter en tant qu’administrateur (ou Run as Administrator sur un système en anglais) comme ci-après.

Exécuter en tant qu’administrateur - Menu contextuel

Vous ferez la différence entre les consoles PowerShell ouvertes en tant qu’administrateur et celles qui ne le sont pas en observant l’intitulé des fenêtres en haut à gauche...

Une transition en douceur avec le passé

Les scripts sont rétrocompatibles, c’est-à-dire que, par exemple, les scripts écrits pour la version 1 de PowerShell fonctionneront avec la version 5.x. Du moins, en principe… car chaque nouvelle version apporte potentiellement de nouveaux mots-clés, commandes et variables et donc si par malchance vous les avez employés en tant que noms de variable ou de fonction, vous pourriez alors rencontrer quelques dysfonctionnements… Mais ne vous affolez pas pour autant car, dans plus de 99 % des cas, il n’y a pas de problème, ou alors c’est que vous n’avez pas de chance...

Il convient cependant de nuancer un peu nos propos car depuis PowerShell 6, les choses ont quelque peu changé. En effet, comme nous vous le disions au début de ce chapitre, PowerShell 6 représente en quelque sorte un renouveau dans l’écosystème PowerShell du fait qu’il soit maintenant open source et multiplateforme. Microsoft s’est donc autorisé de nombreux « breaking changes », entendez par là des changements pouvant entraîner des dysfonctionnements sur des scripts existants.

Quant aux inconditionnels de CMD qui ne se seraient pas encore convertis à PowerShell, qu’ils se rassurent : PowerShell ne fait pas table rase du passé. Pratiquement toutes les commandes qui étaient...

Système d’aide intégré

Depuis PowerShell 3.0 la philosophie de Microsoft vis-à-vis du système d’aide intégré a profondément changé. Dans les versions précédentes, l’aide était installée en standard et celle-ci était disponible en français. Ce n’est désormais plus le cas depuis la version 3...

Ainsi pour pouvoir bénéficier du système d’aide, très complet par ailleurs (mais exclusivement en anglais à présent), il faut télécharger l’aide. Bien que cela puisse sembler contraignant au premier abord, cela nous garantit de disposer des derniers fichiers d’aide disponibles. En effet, l’aide est régulièrement actualisée par Microsoft et il est possible de bénéficier des mises à jour, chose qui n’était pas possible auparavant. Seul petit inconvénient, il faut que la machine sur laquelle on télécharge l’aide ait un accès direct à Internet, c’est-à-dire sans passer par un proxy, ou qu’un administrateur ait au préalable téléchargé l’aide et l’ait placée sur un partage réseau. De plus, vous devez être administrateur de votre ordinateur pour pouvoir mettre à jour l’aide.Mais ne vous en faites pas trop car PowerShell propose toutes les commandes pour mettre à disposition les fichiers d’aide en environnement d’entreprise.

Si l’aide n’est pas installée sur votre système, vous vous en rendrez compte rapidement car seule l’aide syntaxique est proposée. Autrement dit, vous n’aurez accès qu’à la découverte du nom des paramètres sans plus d’explications.

Exemple

Demande d’aide sur une commande lorsque l’aide n’est pas installée.

PS > help update-help 
 
NAME 
    Update-Help 
 
SYNTAX 
    Update-Help [[-Module] <string[]>] [[-SourcePath] <string[]>] 
[[-UICultur... ...

Commandes de base

Avant toute chose, PowerShell est un environnement en lignes de commandes au service du système d’exploitation mais aussi et surtout au service des utilisateurs. En tant que tel, il est livré avec un jeu de commandes qu’il est bon de connaître, ou tout du moins de savoir comment les trouver ou les retrouver lorsque l’on a la mémoire courte…

Gestion des répertoires et des fichiers

Nous avons vu que nous pouvions utiliser les bonnes vieilles commandes DOS/CMD afin de nous déplacer dans une hiérarchie de dossiers. Bien que cela soit toujours possible et fasse gagner du temps à celui qui les emploie, cela ne lui élève pas son niveau de connaissance de PowerShell.

Lorsque vous tapez DIR en PowerShell, vous faites en réalité appel à un alias. L’alias vous fait exécuter la commande Get-ChildItem. Pour le vérifier, tapez la commande suivante :

PS > Get-Alias dir 
 
CommandType     Name                     ModuleName 
-----------     ----                     ---------- 
Alias           dir -> Get-ChildItem
 

Voici un tableau récapitulatif des principales commandes CMD et de leurs équivalents en PowerShell.

Comme l’objet de cet ouvrage est l’apprentissage de PowerShell, nous nous efforcerons de ne plus utiliser les anciennes commandes CMD, et nous vous encourageons à faire de même !

Fournisseurs PowerShell

Maintenant que vous êtes familier avec le jeu de commandes qui permet de naviguer et de gérer une arborescence de fichiers et de dossiers, nous pouvons vous avouer que celui-ci permet également bien d’autres choses…

Toutes les commandes que nous avons vues précédemment (familles *-Item et *-Location) permettent la manipulation non seulement du système de fichiers mais aussi :

C’est ce qui explique la généricité du nom des commandes *-Item, dans la mesure ou un « item » peut représenter par exemple un fichier, un dossier, une clé de registre, une variable ou tout autre chose.

Toutes les sources de données que nous venons d’énumérer précédemment sont accessibles par le biais de ce que l’on appelle dans le jargon PowerShell des fournisseurs (on rencontre également très couramment les termes Provider ou PSProvider). Ils sont au nombre de huit mais seuls six sont affichés par défaut. Afin d’en obtenir la liste et les détails associés, tapez la commande Get-PSProvider.

PS > Get-PSProvider 
 
Name        Capabilities                       Drives 
----        ------------                       ------ 
Alias       ShouldProcess                      {Alias} 
Environment ShouldProcess                      {Env} 
FileSystem  Filter, ShouldProcess, Credentials {C, E, D, F} 
Function    ShouldProcess            ...