Windows PowerShellLa puissance des profils

Don Jones

Sommaire

Shells, hôtes et profils
Vous utilisez votre profil ?
Créer une console personnalisée
Autres astuces de profils
Précautions d'utilisation des profils

Si vous lisez régulièrement cette rubrique, vous savez déjà que Windows PowerShell prend en charge un système de profils. Il s'agit essentiellement de scripts de shell, avec une extension de fichier .ps1, qui s'exécutent automatiquement lorsque le shell démarre. Ils offrent une excellente façon de définir par exemple des alias personnalisés. Vous pouvez faire en sorte que chaque fois que le shell s'exécute, le profil définisse automatiquement vos alias, en les rendant disponibles chaque fois que vous utilisez le shell.

Le shell définit quatre profils différents :

• Un s'appliquant à tous les shells et tous les utilisateurs de l'ordinateur.
• Un s'appliquant à tous les utilisateurs, mais uniquement au shell Microsoft PowerShell.
• Un s'appliquant à l'utilisateur actuel et à tous les shells.
• Un s'appliquant à l'utilisateur actuel et uniquement au shell Microsoft PowerShell.

Le concept de « tous les shells » peut porter quelque peu à confusion. Cette terminologie a pour origine certains concepts de développement des débuts de Windows PowerShell qui n'ont pas été véritablement inclus dans le produit final. Aujourd'hui, le terme « tous les hôtes » serait probablement plus approprié.

Shells, hôtes et profils

En fait, Windows PowerShell se compose d'un ensemble d'assemblys de Microsoft .NET Framework. J'aime faire référence à cette partie du shell comme au moteur de Windows PowerShell, car elle contient les fonctionnalités que vous considérez généralement comme étant Windows PowerShell. Il n'existe toutefois aucune méthode intégrée permettant aux humains d'interagir avec ce moteur. Pour que vous puissiez en fait utiliser le shell, le moteur doit être chargé par une application d'hébergement (ou hôte).

L'application powershell.exe que vous avez probablement l'habitude d'exécuter constitue un tel hôte. L'application gpowershell.exe incluse avec le CTP Windows PowerShell 2.0 constitue un autre hôte. Cette relation entre hôtes et shells n'est pas aussi simple que je l'ai décrite ici, mais mon explication simplifiée couvre le comportement que vous constatez.

Il est important de comprendre que si vous interagissez avec le shell via une interface de ligne de commande à base de texte, vous utilisez probablement l'hôte powershell.exe. Ceci est vrai même si vous avez lancé le shell en utilisant un raccourci installé par une autre application, comme Exchange Management Shell. Exchange Management Shell n'est pas un autre shell ou une autre application d'hébergement. Il s'agit simplement de l'hôte powershell.exe normal lancé en utilisant un raccourci qui spécifie un ensemble de composants logiciels enfichables et de scripts à précharger. Ces composants logiciels enfichables activent la fonctionnalité d'administration d'Exchange dans le shell. Vous utilisez toutefois toujours le même shell.

Les emplacements (sur Windows Vista) des profils pour l'hôte powershell.exe sont les suivants :

• %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 Ceci correspond à tous les utilisateurs de l'ordinateur et tous les shells.
• %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 Ceci correspond à tous les utilisateurs de l'ordinateur, mais seulement pour le shell Microsoft.PowerShell.
• %UserProfile%\Documents\WindowsPowerShell\profile.ps1 Ceci correspond à l'utilisateur actuel seulement et à tous les shells.
• %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 Ceci correspond à l'utilisateur actuel seulement et seulement au shell Microsoft.PowerShell.

Ces profils ne sont pas créés par défaut. Ils existent seulement si vous les créez.

Chaque application d'hébergement est responsable du chargement et de l'exécution du profil correct. Si une application particulière d'hébergement « décide » de ne pas charger de profils du tout, elle n'est pas obligée de le faire. L'exécution de profil n'est pas effectuée automatiquement par le moteur de Windows PowerShell.

La manière la plus facile de prendre note de tout ceci est de simplement ouvrir le shell, taper $profile et appuyer sur Entrée. Cela vous donnera le chemin complet que le shell tente d'utiliser pour ce que je considère comme le profil « principal » (qui est le profil par utilisateur et spécifique au shell). Vous pouvez ensuite créer ou modifier ce script et il s'exécutera chaque fois que le shell démarrera.

Utilisation de votre profil

L'une des utilisations courantes d'un profil consiste à définir des alias personnalisés, comme je l'ai suggéré précédemment. Vous pouvez également ajouter des PSDrives personnalisés (il s'agit essentiellement de lecteurs mappés qui existent entièrement au sein de Windows PowerShell). Une utilisation moins courante consiste à créer une sorte de super shell qui peut effectuer toute tâche d'administration dont vous pourriez avoir besoin, en fonction des logiciels que vous utilisez dans votre environnement. Pour expliquer véritablement le concept de super shell, je dois tout d'abord vous donner un peu d'informations d'arrière-plan.

Le groupe de produit de Microsoft qui crée Windows PowerShell est responsable de beaucoup d'autres technologies d'administration essentielles, dont Microsoft Management Console (MMC). MMC est une bonne analogie pour décrire comment fonctionne Windows PowerShell. Lorsque vous exécutez mmc.exe, vous démarrez avec une console vide qui ne vous est pas d'une grande utilité. Vous ajoutez des composants logiciels enfichables MMC pour créer une console fonctionnelle.

Une fois que votre console a été configurée de la façon dont vous le souhaitez, vous enregistrez la console dans un fichier avec une extension de fichier .msc. Ce fichier de console enregistré vous permet de recharger rapidement votre console personnalisée à tout moment.

Au lieu de créer des consoles MMC personnalisées, beaucoup d'administrateurs s'appuient sur les consoles qui sont installées avec les produits qu'ils administrent. Exchange Server, par exemple, crée une console qui contient seulement le composant logiciel enfichable Exchange Server. Utilisateurs et ordinateurs Active Directory est une autre console créée au préalable et qui contient un seul composant logiciel enfichable.

Windows PowerShell fonctionne de manière très similaire. L'icône Exchange Management Shell installée avec les outils d'administration d'Exchange Server 2007 est en fait un raccourci vers powershell.exe avec des instructions pour le chargement d'un fichier de console. Les fichiers de console de shell ont une extension de nom de fichier .psc1 et contiennent une liste de composants logiciels enfichables à précharger (tout comme un fichier .msc contient une liste de composants logiciels enfichables que MMC charge au préalable pour vous). Cependant, vous n'êtes pas limité à l'utilisation de ces consoles de shell créées au préalable. Vous pouvez créer une console personnalisée, tout comme vous pouvez le faire avec MMC et utiliser celle-ci pour accomplir toutes vos tâches d'administration. Les profils jouent un rôle essentiel pour rendre ceci possible.

Création d'une console personnalisée

Pour créer une console personnalisée, vous devez commencer par rechercher le nom complet de chaque composant logiciel enfichable avec lequel vous voulez travailler. Assurez-vous que tous les outils d'administration nécessaires sont installés sur votre ordinateur. Ensuite, dans Windows PowerShell, exécutez Get-PSSnapin –registered. Ceci répertoriera tous les composants logiciels enfichables disponibles et inscrits, sans être pour autant chargés. Créez ou modifiez ensuite le profil Windows PowerShell approprié. Ajoutez les commandes Add-PSSnapin pour charger chaque composant logiciel enfichable devant toujours être disponible. Ceci pourrait inclure des composants logiciels enfichables pour Exchange Server, des produits System Center et des composants logiciels enfichables de tiers, tels que PowerShell Community Extensions. Enregistrez ensuite votre profil (n'oubliez pas de signer numériquement le profil si votre stratégie d'exécution de PowerShell le nécessite) et fermez le shell. Rouvrez le shell et il chargera automatiquement tous les composants logiciels enfichables répertoriés dans votre profil.

Une autre technique consiste à charger tous vos composants logiciels enfichables dans le shell (en utilisant Add-PSSnapin et les noms des composants logiciels enfichables) et à exécuter ensuite Export-Console pour créer un fichier de console .psc1 contenant tous les composants logiciels enfichables que vous utilisez actuellement. Vous pouvez ensuite utiliser ce fichier de console .psc1 pour créer un nouveau raccourci Windows PowerShell spécifiant le paramètre PSConsolefile et votre fichier .psc1 personnalisé. Ce raccourci utiliserait alors votre console, en chargeant automatiquement tous les composants logiciels enfichables spécifiés.

Autres astuces de profils

J'utilise mon profil Windows PowerShell pour exécuter plusieurs autres tâches utiles chaque fois que le shell démarre. Voici ce qui se produit lorsque le shell démarre sur mon système :

1. J'exécute Get-Credential à partir de mon compte d'administrateur de domaine, en enregistrant le résultat dans une variable nommée $cred. Ceci rend $cred disponible dans tout le shell. Je peux ensuite le passer au paramètre -credential de diverses applets de commande, telle que l'applet de commande Get-WmiObject. Puisque $cred contient le mot de passe, je peux utiliser ces applets de commande sans être invité à entrer un mot de passe.
2. J'exécute Cd C:\ afin que le shell démarre dans la racine du lecteur C: de mon ordinateur.
3. J'exécute New-Alias of Out-File pour créer un alias nommé « of ». J'effectue ceci pour pouvoir ensuite utiliser « of » au lieu de « Out-File ». J'utilise beaucoup cette méthode et posséder un alias court défini est très pratique.

J'essaie de créer une clé de test dans le lecteur HKLM: du shell, qui représente la partie HKEY_LOCAL_MACHINE du Registre. Si une erreur survient, je sais alors que le shell a été lancé sans privilèges élevés. J'ai habituellement besoin des privilèges élevés pour le travail que j'effectue et ceci est juste une façon rapide pour moi de savoir d'avance si je dispose de privilèges élevés avant de commencer une tâche importante.

Je définis une fonction personnalisée nommée Ping-Address acceptant un nom d'ordinateur ou une adresse IP et renvoyant une valeur True ou False, si un ping de l'ordinateur peut ou non être effectué. J'utilise beaucoup cette fonction dans mon travail. Comme elle est définie dans mon profil, elle est globalement disponible dans mon shell.

Applet de commande du mois : Get-WmiObject

Un observateur attentif aura remarqué que j'aborde une applet de commande que j'ai déjà présentée, mais je souhaite vous faire découvrir une petite surprise qu'elle propose. J'observe souvent les administrateurs essayant de récupérer des informations Windows Management Instrumentation (WMI) depuis de multiples ordinateurs dont les noms sont répertoriés dans un fichier texte, en utilisant cette technique :

Get-Content c:\computers.txt | ForEach-Object 
  { Get-WmiObject Win32_Service –comp $_ }

Bien que cette technique fonctionne, vous n'avez pas vraiment besoin de celle-ci car Get-WmiObject peut accepter un tableau de noms d'ordinateurs pour le paramètre -computerName. Pour obtenir le même résultat, vous pouvez utiliser seulement ceci :

Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)

Placer la commande Get-Content entre parenthèses force le shell à exécuter la commande et à placer les résultats (un tableau de noms d'ordinateur) dans le paramètre -computerName.

Précautions d'utilisation des profils

N'oubliez pas que powershell.exe n'est pas la seule application qui charge les profils de Microsoft.PowerShell ou all-shells. De nombreux environnements de développement intégré (IDE) fournissent la prise en charge de Windows PowerShell, dont PrimalScript de SAPIEN Technologies, PowerGUI de Quest Software, et PowerShell Plus de ShellTools, qui chargent également ces mêmes profils pour offrir une expérience équivalente à l'hôte powershell.exe.

Un gros profil chargeant de nombreux composants logiciels enfichables peut provoquer un démarrage plus lent de ces applications, car le moteur de Windows PowerShell doit exécuter de nombreuses instructions avant d'être prêt pour l'application d'hébergement. En fait, même powershell.exe peut nécessiter beaucoup de temps pour démarrer si vous avez un très gros script de profil à exécuter.

Les composants logiciels enfichables qui définissent des applets de commande avec les mêmes noms peuvent également provoquer des collisions. Par exemple, si deux composants logiciels enfichables définissent une applet de commande nommée Get-User, Windows PowerShell n'exécutera aucune des applets de commande jusqu'à ce que vous utilisiez le nom complet de l'applet de commande pour spécifier celle que vous voulez. Ce nom complet peut être très complexe, car les noms de composants logiciels enfichables peuvent être très longs. Lorsque je rencontre ce problème, je renonce d'ordinaire simplement à l'idée d'avoir ces deux composants logiciels enfichables chargés simultanément. Je charge plutôt seulement celui que j'utilise le plus dans mon profil et utilise alors un shell séparé et « neuf » lorsque j'ai besoin de charger et d'utiliser l'autre composant logiciel enfichable.

Les profils Windows PowerShell peuvent offrir une commodité supplémentaire substantielle au shell. Mais souvenez-vous que s'ils sont modifiés à des fins nuisibles par un logiciel malveillant, les profils peuvent également causer beaucoup de dégâts. Vous pouvez protéger votre profil en le signant numériquement et configurer Windows PowerShell pour qu'il utilise sa stratégie d'exécution AllSigned, ou modifier les autorisations de fichier de NTFS de vos profils (tous) pour que votre compte utilisateur normal ne puisse pas les modifier.

Don Jones est l'auteur de Windows PowerShell : TFM and VBScript, WMI, and ADSI Unleashed. Vous pouvez le contacter par l’intermédiaire du site Web PowerShellCommunity.org.