Windows PowerShellUn aperçu furtif de la gestion à distance de la version 2.0

Don Jones

Cette rubrique est basée sur une version préliminaire de Windows PowerShell. Toutes les informations contenues dans le présent document sont susceptibles d’être modifiées.

Sommaire

Deux types d'accès distant
Synchrone - Asynchrone
Espaces d'exécution réutilisables
Accès à distance de type entrance
L'application qui tue dans 2.0

Avez-vous eu la possibilité d'essayer le tout dernier CTP de Windows PowerShell 2.0 ? La dernière version, CTP2, a encore amélioré la gestion à distance et maintenant il est grand temps de commencer à se familiariser avec ses nouvelles fonctionnalités. Avant que je ne commence les explications, vous pouvez

télécharger la nouvelle version depuis go.microsoft.com/fwlink/?LinkID=119707.

Premièrement, permettez-moi de clarifier quelques détails importants. Un CTP est un code pré-bêta que Microsoft fournit pour que des utilisateurs passionnés comme moi puissent se faire une idée de ce que Microsoft souhaite réaliser avec la nouvelle version d'une application. Chaque jalon de CTP ou drop (comme ils sont appelés dans le secteur) peut être complètement différent des drops précédents. Ceci est dû au fait que l'équipe de développement rassemble des commentaires, les étudie minutieusement et modifie l'application en fonction des commentaires des utilisateurs. Cette méthode présente de nombreux avantages et fournit des informations importantes concernant votre utilisation du CTP.

L'avantage est que, lorsque vous utilisez le CTP, vous pouvez envoyer des commentaires (via le site Web connect.microsoft.com) et que l'équipe de développement peut encore agir sur la base de ces commentaires ! Si vous attendez la bêta ou, pire, la version Release Candidate, il sera beaucoup plus difficile d'intégrer vos commentaires. Pendant le CTP, quoi qu'il arrive, l'équipe peut encore apporter des modifications de grande envergure si cela est nécessaire.

J'en arrive donc à ma mise en garde. Le CTP n'est pas prêt pour la production. Certes, le CTP2 de Windows PowerShell™ 2.0 est peut-être l'un des codes préliminaires les plus stables que vous ayez vus, mais n'oubliez pas que le prochain drop de CTP sera peut-être une application complètement différente. Donc, ne commencez pas à vous appuyer sur le CTP2 : la prochaine version sera peut-être complètement différente et vous devrez tout recommencer depuis le début.

Notez que le CTP ne peut pas être installé parallèlement à Windows PowerShell 1.0. Pour une configuration idéale, Microsoft® .NET Framework 3.5 devrait également être installé sur le système. Ceci permet, en effet, d'activer toutes les fonctions additionnelles. Autrement dit, certaines fonctions seront limitées.

Par ailleurs, puisque le CTP est un code très précoce, Microsoft a mis l'accent, jusque là, sur le fonctionnement de l'application avec les derniers systèmes d'exploitation, c'est-à-dire Windows Vista® et Windows Server® 2008. Si le CTP est actuellement compatible avec votre système d'exploitation, le code final ne le sera peut-être pas. On ne se penche sur le backporting que plus tard dans le cycle de développement.

Deux types d'accès distant

Dans le monde de la gestion à distance, vous trouvez habituellement deux types d'accès à distance : l'entrance et la sortance. L'accès à distance de type entrance comprend des administrateurs multiples qui effectuent des connexions Secure Shell à un serveur unique. Windows PowerShell est conçu pour permettre cela de manière sûre et partitionnée de sorte que, par exemple, une entreprise d'hébergement Exchange Server puisse offrir à ses clients un accès administratif à leurs portions de serveur. L'accès à distance de type entrance offre un accès à distance sûr et interactif à la copie de Windows PowerShell (version 2.0 uniquement !) installée sur un serveur distant.

On parle d'accès à distance de type sortance lorsque vous transmettez, en une fois, une série de commandes à un groupe entier de serveurs distants. Les commandes « sortent » de votre poste de travail pour atteindre le groupe de serveurs en parallèle. Les commandes s'exécutent sur chaque serveur et les résultats sont renvoyés à votre poste de travail (sous la forme d'objets Windows PowerShell) de sorte que vous pouvez les revoir et les utiliser pour travailler. Windows PowerShell prend en charge deux technologies fondamentales pour l'accès à distance de type sortance : l'infrastructure de gestion Windows® (WMI) et la gestion à distance Windows (WinRM), qui étaient d'abord inclus dans Windows Server 2008 et qui ont ensuite été mis à jour dans le CTP Windows PowerShell 2.0.

Synchrone - Asynchrone

En fait, même Windows PowerShell 1.0 offrait quelques fonctionnalités de sortance de base, qui étaient liées à l'infrastructure de gestion Windows. Par exemple, vous pouviez créer facilement un tableau de noms d'ordinateurs et, ensuite, récupérer, à partir de chaque nom, une classe WMI :

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem 
    –computer $names

Exécuter des méthodes (telles qu'un redémarrage d'ordinateur) demandait un peu plus de travail puisque la version 1.0 n'offrait pas de moyen d'exécuter les méthodes WMI en bloc. Mais cela a changé dans la version 2.0 du CTP grâce à l'applet de commande Invoke-WmiMethod :

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot

Toutefois, cette technique présente un problème. Il s'agit d'une technique synchrone, ce qui signifie que chaque ordinateur est contacté séparément et que vous devez attendre la fin de chaque commande avant d'en exécuter d'autres. Mais le CTP introduit un nouveau concept : les tâches en arrière-plan. Ceci permet d'exécuter des commandes de ce type en arrière-plan. Pour simplifier, vous pouvez exécuter une tâche en arrière-plan en ajoutant tout simplement le paramètre –AsJob :

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob

Vous pouvez consulter l'état de la tâche en exécutant Get-PSJob et afficher les résultats finaux de la tâche en exécutant Receive-PSJob. (Je me pencherai sur les détails de l'administration des tâches dans un prochain article). Toutefois, l'applet de commande Invoke-Command offre de meilleures possibilités d'exécution des commandes en arrière-plan, comme ceci :

$command = { Get-WmiObject     Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command     –computer $names –asjob

il effectue une transmission de type push de la commande Get-WmiObject à chaque ordinateur spécifié, puis il l'exécute localement. L'exécution est généralement beaucoup plus rapide et ne doit pas s'appuyer sur les connexions d'appel de procédure distante (RPC) de WMI. En effet, Invoke-Command utilise WinRM, qui utilise les ports 80 ou 443 par défaut. Ces ports facilitent la navigation des pare-feu et sont entièrement configurables. Invoke-Command prend également en charge des paramètres additionnels pour des informations d'identification alternatives et la limitation, ce qui vous permet de cibler des centaines d'ordinateurs bien que seuls quelques uns tournent en parallèle. Ceci vous permet d'éviter les surcharges excessives et l'encombrement.

Instances d'exécution réutilisables

Si vous planifiez d'administrer à distance une série donnée d'ordinateurs et cela avec une certaine fréquence, vous devez considérer l'utilisation d'instances d'exécution réutilisables plutôt que de simples listes de noms d'ordinateur. Dans Windows PowerShell, une instance d'exécution n'est qu'une instance du moteur Shell, qu'elle soit exécutée localement, sur votre ordinateur sous la forme d'une fenêtre de console Shell ou en arrière-plan, sur un ordinateur distant. Le démarrage d'un espace d'exploitation à distance est une opération simple :

$names = @("server1","server2","server2")
New-RunSpace –computer $names

Puisque les espaces d'exploitation utilisent WinRM, ils utilisent donc le port 80 (ou 443, si vous spécifiez le paramètre UseSSL) par défaut. Ces ports peuvent également accepter des informations d'identification alternatives, etc. Si vous récupérez les objets d'espaces d'exploitation résultants, vous pouvez les transmettre à la commande Invoke-Command. Windows PowerShell effectue alors une transmission de type push de la commande aux ordinateurs sur lesquels ces instances d'exploitation existent :

$command = { Get-WmiObject     Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command     –runspace $rs –asjob

L'avantage est que les instances d'exploitation restent actives aussi longtemps que le Shell est ouvert. Donc, vous pouvez les réutiliser pour des commandes additionnelles.

Accès à distance de type entrance

Les instances d'exploitation sont également essentielles pour l'accès à distance de type entrance. Par exemple, la figure 1 montre que j'ai créé une instance d'exploitation sur un ordinateur distant, que j'ai récupéré une référence à cet espace d'exploitation et qu'ensuite, j'ai utilisé l'applet de commande Push-Runspace pour activer l'espace d'exploitation. À ce stade, j'exécute des commandes sur l'ordinateur distant, un peu comme SSH ou d'autres utilitaires Remote Shell me permettraient de le faire. L'exécution de Pop-Runspace ramène mon instance d'exploitation d'origine « locale » et l'invite Shell me permet de savoir où je suis à tout moment.

Figure 1 Utiliser un espace d'exploitation pour exécuter des commandes sur un ordinateur distant (cliquez sur l'image pour l'agrandir)

La séquence exacte de commandes que j'ai exécutée est comme suit :

PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32>    pop-runspace
PS C:\>

Cette technique est appelée entrance parce que plusieurs administrations peuvent ouvrir des espaces d'exploitation interactives sur le même serveur, au même moment : elles « entrent » de leurs postes de travail individuels sur le serveur. Un nouveau modèle de sécurité dans Windows PowerShell 2.0 vous permet de créer des Shells et des applets de commande limités. De cette manière, toutes les administrations sont limitées et ne peuvent donc pas apporter de modifications globales. Chacune est limitée à sa propre zone de Shell. (Ces nouvelles techniques de sécurité requièrent un développement logiciel personnalisé dans un langage ciblé .NET Framework. Ceci n'entre pas dans le cadre de la rubrique Windows PowerShell, mais il est intéressant de savoir que ces fonctions existent).

L'application qui tue dans 2.0

Le CTP Windows PowerShell 2.0 offre une liste étonnante de nouvelles fonctions. À mon avis, l'accès à distance est une application qui tue. Chaque administrateur dans pratiquement n'importe quel environnement peut en bénéficier.

Vous devriez vous familiariser avec ces fonctions afin de pouvoir envoyer vos suggestions à l'équipe produit. Voulez-vous que les ports par défaut de WinRM soient administrés via la Stratégie de groupe ? Les applets de commande devraient-ils fonctionner différemment ? Y a-t-il des problèmes de performance ? WinRM est-il facile à configurer ? Vous pouvez avoir une influence en envoyant des suggestions à connect.microsoft.com ou en partageant vos commentaires avec les lauréats de la récompense MVP, dont je fais partie (pour me contacter, envoyez vos commentaires aux forums sur ScriptingAnswers.com). Alors, participez à la création de l'application qui tue pour la prochaine génération de Windows PowerShell !

Applet de commande du mois Select-Object

Essayez ça ! Get-Service | ConvertTo-HTML | Out-File Services.htm. Maintenant, contrôlez le fichier HTML résultant dans votre navigateur Web. Il y a pas mal d'informations, n'est-ce pas ? Si seulement il y avait une façon de les trier en sélectionnant les informations qui vous intéressent ! Et bien, c'est précisément ce que Select-Object peut faire pour vous. Imaginons, par exemple que vous souhaitiez une liste de noms de services et leur état actuel. Vous pouvez utiliser ceci : Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Services.htm.

Mais n'oubliez pas que Select-Object élimine l'objet original (dans ce cas, services) et génère un objet personnalisé (littéralement un type d'objet PSCustom), qui contient uniquement les propriétés que vous avez spécifiées. Les fonctionnalités de l'objet original ne seront plus accessibles, donc vous souhaiterez probablement garder Select-Object à la fin de votre pipeline et travailler avec l'objet original aussi longtemps que possible.

Don Jones est coauteur de Windows PowerShell v2.0 : TFM. Il est aussi le formateur de la formation dirigée « Special Forces  » de ScriptingAnswers.com (scriptinganswers.com/training.asp). Vous pouvez le contacter à l'adresse suivante : jeepdon@mac.com.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. La reproduction partielle ou totale sans autorisation est interdite.