Windows PowerShellApprofondissez vos connaissances
Don Jones
Windows PowerShell offre une multitude de fonctionnalités qui sont souvent négligées par de nombreux administrateurs. En creusant davantage, vous découvrirez des fonctionnalités stupéfiantes. En fait, je trouve souvent moi-même de nouvelles fonctionnalités associées à une applet de commande particulière que je pensais déjà bien connaître.
Dans les cours Windows PowerShellTM que je donne, je recommande aux administrateurs d'établir un calendrier des applets de commande du jour pour eux-mêmes, comparable à un calendrier des mots du jour que l'on peut acheter. Ensuite, chaque matin (excepté le week-end car il faut bien qu'ils se reposent), ils peuvent passer quelques minutes à se familiariser avec les fonctionnalités complètes d'une applet de commande. Windows PowerShell est vendu avec environ 130 applets de commande, ce qui vous permet d'apprendre à connaître pratiquement toutes ses fonctionnalités en six mois environ, si vous respectez ce calendrier. Vous serez alors prêt à gérer toutes les applets de commande d'Exchange Server 2007.
Dans l'article de ce mois-ci, je voudrais vous donner quelques exemples de ce que vous pourriez découvrir et de ce que vous pourriez faire si vous consacriez quelques minutes seulement à l'exploration en profondeur des fonctionnalités de diverses applets de commande.
Des rapports HTML plus attrayants
ConvertTo-HTML est une applet de commande très sous-utilisée. Cette applet de commande intelligente peut accepter une collection d'objets d'entrée, tels que des services, processus, objets WMI (Windows ® Management Instrumentation) ou autres, et les transformer en table HTML. Vous pouvez ensuite canaliser le HTML vers Out-File et vous obtenez une page HTML qui peut être publiée sur un serveur Web d'intranet. Par exemple, vous pouvez planifier l'exécution de cette ligne simple tous les matins :
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML | Out-File C:\ServiceAlert.html
Elle créera un rapport HTML, comme celui illustré à la figure 1, sur les services qui devraient être démarrés automatiquement mais qui ne sont pas exécutés.
Figure 1** Rapport HTML sur les services qui ne sont pas exécutés **(Cliquer sur l'image pour l'agrandir)
Bien sûr, vous pouvez essayer de produire un rapport un peu plus attrayant. Fort heureusement, l'applet de commande ConvertTo-HTML produit un HTML propre, c'est-à dire qu'elle n'intègre pas de formatage au code HTML qu'elle crée. Selon les règles HTML, vous ne devez jamais intégrer de formatage au HTML (ou du moins, vous devez en intégrer le moins possible). Vous devez mettre le formatage dans une feuille CSS (cascading style sheets) externe et la lier au HTML. Et vous pouvez créer ce lien avec ConvertTo-HTML.
CSS est relié à la section <HEAD> d'un fichier HTML. Si vous jetez un coup d'œil sur ConvertTo-HTML, vous verrez que sa syntaxe inclut des paramètres que vous pourriez avoir négligé :
ConvertTo-Html [[-property] <Object[]>]
[-inputObject <psobject>] [-body <string[]>]
[-head <string[]>] [-title <string>] [<CommonParameters>]
Le paramètre –head vous permet de spécifier le code HTML supplémentaire qui doit être inséré dans la section <HEAD> du script. Je peux, à présent, facilement modifier ma ligne de code et la relier à un fichier CSS existant qui contient le formatage que je souhaite appliquer à la table HTML :
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML -title "Services" -head "<link
rel='stylesheet' href='styles.css' type='text/
css' />" | Out-File C:\ServiceAlert.html
Ici, j'ai utilisé le paramètre –head pour insérer un lien dans un fichier CSS situé dans le même dossier que le fichier HTML de sortie. J'ai également utilisé le paramètre –title pour définir le titre de la page Web. Le résultat est illustré à la figure 2. Le texte du fichier Style.CSS que j'ai utilisé ressemble à ceci :
Figure 2** Rapport HTML formaté avec un fichier CSS **(Cliquer sur l'image pour l'agrandir)
body { background-color:#EEEEEE; }
body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt }
th { font-weight:bold; background-color:#CCCCCC; }
td { background-color:white; }
Un filtrage plus facile
Applet de commande du mois
Ce mois-ci, je m'intéresse à deux applets de commande : Start-Transcript et Stop-Transcript. Les deux sont utilisées pour contrôler la journalisation des transcriptions Windows PowerShell, c'est-à-dire l'écriture dans un fichier texte que vous avez spécifié de tout ce qui apparaît dans la fenêtre de la console. Cette opération est très simple. Exécutez Start-Transcript et donnez-lui un nom de fichier pour commencer. Ensuite exécutez Stop-Transcript pour mettre fin à la journalisation et fermez le fichier. Il s'agit là d'un bon moyen de passer d'une utilisation ad hoc de l'environnement de ligne de commande au script formel. Une fois que les lignes de commande individuelles fonctionnent dans l'environnement, il vous suffit de les copier et coller à partir du fichier de transcription que vous avez créé. Bien sûr, vous pouvez également modifier la transcription et la limiter au script lui-même. Mon collègue Jeffery Hicks, MVP, a même écrit un script qui analyse les transcriptions et les transforme en fichiers PS1 Windows PowerShell. Vous trouverez ce script à l'adresse blog.sapien.com/current/2006/11/28/powershell-transcripts.html.
Examinons maintenant l'applet de commande Get-WMIObject. Sa syntaxe, comme indiqué dans l'aide de Windows PowerShell, suggère des fonctionnalités inexploitées :
Get-WmiObject [-class] <string> [[-property]
<string[]>] [-namespace <string>]
[-computerName <string[]>] [-filter <string>]
[-credential <PSCredential>]
[<CommonParameters>]
Les nouveaux utilisateurs de Windows PowerShell font souvent l'erreur d'émettre une commande WMI comme suit :
Gwmi Win32_NTLogEvent –comp Server2
Cette commande récupère les entrées des journaux d'événements de Server2, soit toutes les entrées des journaux d'événements. Il faudra du temps à Server2 pour traiter et transmettre cette tâche, et Windows PowerShell mettra beaucoup de temps à organiser une telle collection d'entrées.
Une meilleure approche est celle qui consiste à faire en sorte que Server2 trouve et envoie les événements qui vous intéressent vraiment. Vous pouvez effectuer cette opération à l'aide d'une requête WQL (WMI Query Language). Certains trouvent cette syntaxe de requête difficile, mais Windows PowerShell vous permet de spécifier uniquement la partie de filtrage d'une requête WQL à l'aide du paramètre –filter :
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
Vous récupérez ainsi tous les événements de n'importe quel journal portant l’ID d’événement 1024. Remarquez que les critères du filtre utilisent = comme opérateur de comparaison au lieu de l'opérateur –eq de Windows PowerShell. La raison en est que le filtre est transmis au service WMI de l'ordinateur distant pour traitement, et les critères doivent donc être dans la syntaxe WMI et non pas dans la syntaxe Windows PowerShell.
Il existe en fait un paramètre –filter sur d'autres applets de commande telles que Get-ChildItem, l'applet de commande sur laquelle s’appuient les alias tels que Dir et Ls. Dans la plupart des cas, le paramètre –filter transmet vos critères de filtre directement à la technologie sous-jacente, ce qui aboutit à ce que je choisis d'appeler le filtrage source qui est souvent beaucoup plus rapide que le fait d'avoir à réunir tous les objets et à les faire passer ensuite par l'applet de commande Where-Object pour éliminer ceux dont vous n'avez pas besoin.
Applets de commande négligées
Bien sûr, cette méthode d'étude « un par jour » des applets de commande vous aidera à mieux comprendre les applets de commande que vous pensiez déjà connaître. Toutefois, il existe une autre bonne raison d'avoir un calendrier « applet de commande du jour » : éviter d'ignorer complètement les applets de commande que vous n'auriez pas pu découvrir autrement. Une de mes applets de commande préférées que beaucoup de gens n'utilisent pas est Resolve-Path. Avec un chemin d'accès à caractères génériques, cette applet de commande renvoie une collection de noms de fichier et de dossier correspondant à ce chemin. Elle est similaire à l'applet de commande Get-ChildItem (c'est-à-dire les alias bien connus Dir ou Ls), mais au lieu de renvoyer des objets de fichiers et dossiers entiers, elle renvoie de simples chaînes qui peuvent être dirigées vers d'autres applets de commande pour y être filtrées ou traitées. Son utilisation est simple :
Resolve-Path C:\P*
Cette simple ligne renverra des chemins tels que C:\Program Files, C:\Processes.txt, et ainsi de suite. La figure 3 montre deux exemples de cette applet de commande en utilisation.
Figure 3** Utilisation de l'applet de commande Resolve-Path, robuste mais souvent négligée **(Cliquer sur l'image pour l'agrandir)
Commencez au tout début.
Une fois prêt à démarrer votre expérience « applet de commande du jour », exécutez Gcm, alias de Get-Command. Vous obtenez un liste de toutes les applets de commande connues de Windows PowerShell, y compris celles que vous y avez ajoutées au moyen de composants logiciels enfichables tels qu'Exchange Server 2007 Management Shell, PowerShell Community Extensions, etc. Choisissez la première de la liste (la mienne était Add-Content) et lisez son aide :
Help Add-Content –full
Il vous faut l'aide complète, et non pas l'aide par défaut qui est plus concise, afin d'obtenir une description complète de ce que chaque paramètre fait, de voir des exemples d'utilisation de l'applet de commande et de trouver d'autres informations détaillées. Essayez cette applet de commande pendant quelques instants. (Essayez d'utiliser une machine virtuelle pour ne pas avoir à toucher à votre environnement de production). Je vous recommande d'y consacrer 10 minutes tous les jours de semaine et à peu près au même moment de la journée afin que cela devienne une habitude. Vous maîtriserez ainsi, en un temps record, toutes les fonctions et fonctionnalités de Windows PowerShell.
Don Jones est le gourou des scripts chez SAPIEN Technologies et co-auteur de Windows PowerShell: TFM (SAPIEN Press, 2007). Vous pouvez le contacter sur le site www.ScriptingAnswers.com.
© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.