L’une des meilleures fonctionnalités offertes par PowerShell est la possibilité de gérer à distance vos serveurs. Il vous permet même d’en gérer plusieurs à la fois.
Assurez-vous de lire les articles précédents de la série:
Et restez à l’écoute pour le reste de la série toute la semaine.
Qu’est-ce que la communication à distance?
La gestion en masse de vos serveurs peut être fastidieuse, et si vous avez déjà dû faire un changement de configuration IIS sur 50 serveurs Web auparavant, vous saurez ce que je veux dire. Ce sont les types de situations dans lesquelles PowerShell Remoting et les capacités de script du langage peuvent venir à la rescousse. En utilisant HTTP ou HTTPS plus sécurisé, PowerShell Remoting vous permet d’envoyer des commandes à une machine distante de votre réseau. La machine exécute ensuite les commandes et vous renvoie la sortie, qui s’affiche à son tour sur votre écran.
Passons à la technique
Au cœur de PowerShell Remoting se trouve un service Windows unique, le service Windows Remote Management ou WinRM, comme on l’appelle désormais. À l’aide de WinRM, vous pouvez configurer une ou plusieurs configurations de session (également appelées points de terminaison), qui sont essentiellement des fichiers contenant des informations sur l’expérience que vous souhaitez fournir à la personne qui se connecte à votre instance PowerShell distante. Plus spécifiquement, vous pouvez utiliser des fichiers de configuration de session pour définir qui peut et qui ne peut pas se connecter à l’instance, quels cmdlets et scripts ils peuvent exécuter, ainsi que dans quel contexte de sécurité la session doit être exécutée. À l’aide du service WinRM, vous configurez également des «écouteurs», qui écoutent les demandes PowerShell entrantes. Ces «écouteurs» peuvent être HTTP ou HTTPS et peuvent être liés à une seule adresse IP sur votre machine. Lorsque vous ouvrez une connexion PowerShell à une autre machine (techniquement, cela se fait à l’aide du protocole WS-MAN, basé sur HTTP), la connexion se lie à l’un de ces «écouteurs». Les «écouteurs» sont alors en charge d’envoyer le trafic vers l’application associée au fichier de configuration de session approprié; l’application (normalement PowerShell mais vous pouvez avoir d’autres applications d’hébergement si vous le souhaitez) exécute alors la commande et renvoie les résultats via «l’écouteur» sur le réseau et de nouveau sur votre machine.
Me montrer comment
La première chose à faire est d’activer la communication à distance sur la machine à laquelle vous souhaitez vous connecter. Cela peut être fait en exécutant ce qui suit:
Enable-PSRemoting
Vous devrez ensuite répondre oui à toutes les invites. Lorsque vous exécutez Enable-PSRemoting, quelques modifications sont apportées à votre PC:
- Le service WinRM démarre.
- Le service WinRM passe du mode de démarrage manuel à automatique.
- Il crée un écouteur HTTP lié à toutes vos cartes réseau.
- Il crée également une exception de pare-feu entrant pour le protocole WS-MAN.
- Certaines configurations de session par défaut sont créées
Si vous exécutez Windows 7 et que l’emplacement de votre carte réseau est défini sur Public, l’activation de PowerShell Remoting échouera. Pour résoudre ce problème, passez simplement à l’emplacement du réseau domestique ou professionnel. Vous pouvez également ignorer la vérification du réseau en utilisant les éléments suivants:
Enable-PSRemoting –SkipNetworkProfileCheck
Cependant, nous vous recommandons plutôt de modifier votre emplacement réseau.
Il existe deux façons de se connecter à une autre machine à l’aide de PowerShell. Il y a la méthode one to one, qui est très similaire à l’utilisation de SSH, et puis il y a la méthode one to many.
Utilisation d’une session PowerShell
La première façon de se connecter à une machine distante à l’aide de PowerShell consiste à utiliser quelque chose appelé une session PowerShell. En termes simples, une session vous permet d’exécuter des commandes sur la machine distante de manière interactive de la même manière que vous le feriez sur votre propre machine. Pour ouvrir une session, tapez simplement ce qui suit:
Enter-PSSession –Nom de l’ordinateur « Darlah »
L’invite recevra un préfixe qui signifie la machine sur laquelle vous exécutez les applets de commande.
À partir de là, vous pouvez vraiment traiter l’invite comme si vous étiez assis devant la machine distante. Par exemple, si vous voulez voir tous les fichiers sur le lecteur C: , vous pouvez faire un simple:
Get-ChildItem –Path C:
Si vous venez d’un arrière-plan Linux, vous pouvez envisager d’utiliser cette méthode de communication à distance comme alternative PowerShell à SSH.
Utiliser Invoke-Command
La deuxième façon d’utiliser PowerShell sur un ordinateur distant consiste à utiliser Invoke-Command. L’avantage d’utiliser Invoke-Command vient du fait que vous pouvez exécuter la même commande sur plusieurs machines simultanément. Comme vous pouvez l’imaginer, cela est particulièrement utile lorsque vous souhaitez faire quelque chose comme collecter des journaux d’événements à partir de vos serveurs. Invoke-Command suit la syntaxe suivante:
Invoke-Command -ComputerName Darlah, localhost -ScriptBlock {Get-EventLog Application -Newest 2}
Puisque la commande est exécutée en parallèle sur toutes les machines, vous aurez besoin d’un moyen de voir de quel PC provient un résultat donné. Vous pouvez le faire en examinant la propriété PSComputerName.
Lorsque vous utilisez Invoke-Command, vous n’avez plus les objets attendus dans le pipeline. Vous voyez, pour que PowerShell récupère les informations de la machine distante vers votre machine, ils ont besoin d’un moyen de représenter les objets que la commande que vous avez exécutée sur la machine distante génère. De nos jours, il semble que la manière choisie pour représenter une structure de données hiérarchique soit d’utiliser XML, ce qui signifie que lorsque vous émettez une commande en utilisant Invoke-Command, les résultats sont d’abord sérialisés en XML avant d’être renvoyés à votre machine. Une fois qu’ils reviennent sur votre machine, ils sont désérialisés en un objet; le problème ici est que lorsqu’elles sont désérialisées, toutes les méthodes, à l’exception de la méthode ToString (), que l’objet avait en sont supprimées.
