Envoi de commandes à une autre application de console powershell. Techniques pour travailler avec des systèmes distants via PowerShell. WinRM - Gestion à distance Windows

Je travaille souvent avec des commandes sur des systèmes distants via PowerShell, à la fois lors de tests d'intrusion et dans les tâches quotidiennes. Les commandes à distance sont lancées via le protocole WinRM (Windows Remote Management), qui, à ma connaissance, est pris en charge dans Windows Vista SP 1, Windows 7, Windows Server 2008 et Windows Server 2012.

introduction

Paramètres initiaux

Avant de pouvoir commencer à travailler avec le système distant, vous devez terminer la configuration.

1. Démarrez la console PowerShell en tant qu'administrateur et exécutez la commande suivante :

Activer-PSRemoting -force

La commande ci-dessus permet d'exécuter des commandes sur des systèmes distants. Si vous rencontrez des problèmes, utilisez les commandes ci-dessous :

2. Assurez-vous que le service WinRM démarre automatiquement.

# Réglez le mode souhaité

Set-Service WinRM -StartMode Automatique

# Vérifiez que le service est en cours d'exécution

Get-WmiObject -Class win32_service | Where-Object ($ _. Name -like "WinRM")

3. Définissez le statut de tous les hôtes sur « valide » (vous pouvez le faire plus tard).

# Nous faisons confiance à tous les hôtes

Set-Item WSMan : localhost \ client \ Trustedhosts -value *

# Vérifiez la configuration des hôtes de confiance

Get-Item WSMan : \ localhost \ Client \ TrustedHosts

Exemples de travail avec systèmes distants

Exécution d'une seule commande sur un système distant

La commande "Invoke-Command" est utilisée pour exécuter des commandes sur des systèmes distants. Vous pouvez travailler en tant qu'utilisateur actuel ou utiliser un compte tiers si vous travaillez sur un système qui ne fait pas partie d'un domaine :

Invoke-Command -ComputerName MyServer1 -ScriptBlock (Hostname)
Invoke-Command -ComputerName MyServer1 -Credentials demo \ serveradmin -ScriptBlock (Hostname)

Si un module pour travailler avec Active Directory est installé, il devient possible d'exécuter des commandes sur plusieurs systèmes à l'aide d'un pipeline :

Get-ADComputer -Filter * -properties nom | select @ (Nom = "nom_ordinateur"; Expression = ($ _. "nom")) |
Invoke-Command -ScriptBlock (nom d'hôte)

Parfois, sur un système distant, vous devez exécuter un script stocké localement :

Invoke-Command -ComputerName MyServer1 -FilePath C:\pentest\Invoke-Mimikatz.ps1
Invoke-Command -ComputerName MyServer1 -FilePath C:\pentest\Invoke-Mimikatz.ps1 -Credentials demo\serveradmin

Si vous générez des commandes ou des fonctions dynamiquement, qui sont ensuite transmises au système distant, vous pouvez utiliser un ensemble de commandes invoke-expression et invoke-command :

$ MaCommande = "nom d'hôte"
$ MyFunction = "function evil (write-host` "Getting evil ...` "; iex -command $ MyCommand); evil"
invoke-command -ComputerName MyServer1 -Credentials demo \ serveradmin -ScriptBlock
(Invoke-Expression -Command "$ args") -ArgumentList $ MyFunction

Organisation d'une console interactive sur un système distant

Vous pouvez configurer une console PowerShell interactive sur un système distant à l'aide de la commande "Enter-PsSession" (un peu comme SSH). La commande "Enter-PsSession" est également exécutée soit en tant qu'utilisateur actuel, soit en utilisant un autre compte :

Enter-PsSession – ComputerName server1.domain.com
Enter-PsSession – ComputerName server1.domain.com – Credentials domain \ serveradmin

La session est fermée à l'aide de la commande "Exit-PsSession" :

Création de sessions en arrière-plan

Une autre fonctionnalité utile vous permet de créer des sessions en arrière-plan (la commande "New-PsSession"). Les sessions en arrière-plan peuvent être utiles lors de l'exécution de plusieurs commandes sur plusieurs systèmes. Comme les commandes précédentes, la commande "New-PsSession" est exécutée au nom de l'utilisateur actuel, ou à l'aide d'un compte alternatif :

Nouveau-PSSession - ComputerName server1.domain.com
Nouveau-PSSession – ComputerName server1.domain.com – Credentials domain \ serveradmin

Si le module pour travailler avec ActiveDirectory est installé, il devient possible de créer simultanément des sessions en arrière-plan pour plusieurs systèmes (cette astuce peut être réalisée différentes façons). Vous trouverez ci-dessous un exemple de création de sessions en arrière-plan pour tous les systèmes d'un domaine. Dans l'exemple, les sessions sont créées sur un système sans domaine à l'aide d'un autre compte de domaine.

Nouveau-PSDrive -PSProvider ActiveDirectory -Name RemoteADS -Root "
"-Server a.b.c.d -credential domain \ user
cd RemoteADS :
Get-ADComputer -Filter * -Nom des propriétés | select @ (Name = "ComputerName"; Expression = ($ _. "name"))
| Nouveau-PSSession

Répertorier les sessions d'arrière-plan

Une fois plusieurs sessions d'arrière-plan créées, vous pouvez en visualiser la liste à l'aide de la commande "Get-PsSession".

Interagir avec les sessions en arrière-plan

Au début, j'avais un sentiment similaire à la façon dont je travaillais avec les sessions dans MetaSploit. Cependant, les sessions en arrière-plan dans PowerShell sont légèrement plus stables. Un exemple d'interaction utilisant un ID de session est présenté ci-dessous :

Entrée-PsSession –id 3

Pour quitter la session, utilisez la commande "Exit-PsSession". La session revient à l'arrière-plan.

Exécution de commandes via des sessions en arrière-plan

Si vous souhaitez exécuter la commande dans toutes les sessions actives, utilisez un ensemble de commandes "Invoke-Command" et "Get-PsSession".

Invoke-Command -Session (Get-PSSession) -ScriptBlock (Hostname)

Supprimer les sessions en arrière-plan

Pour supprimer toutes les sessions actives, utilisez la commande "Disconnect-PsSession"

Obtenez-PSSession | Déconnecter-PSSession

Conclusion

Les commandes à distance dans PowerShell ouvrent d'énormes opportunités pour les administrateurs et les testeurs d'intrusion. Quelle que soit la situation, comment vous allez travailler avec des systèmes distants, tout se résume à ce qui suit :

Utilisez Invoke-Command pour exécuter une seule commande sur un système distant.
Utilisez Enter-PSSession pour interagir avec un seul système.
Si vous souhaitez exécuter plusieurs commandes sur plusieurs systèmes, utilisez des sessions en arrière-plan.

J'espère que vous avez trouvé cet article utile.

04.03.2011 Bill Stewart

V Versions Windows PowerShell 2.0 implémente un mécanisme alternatif pour se connecter à des ordinateurs distants appelé distant. Ce mécanisme utilise les installations du service télécommande Windows (Gestion à distance Windows, WinRM). Il fournit la connectivité à un ordinateur distant ainsi que le lancement de commandes exécutées sur cet ordinateur distant

Le développement de PowerShell 1.0 a été une véritable percée dans les outils de gestion et d'automatisation de Windows XP et des versions ultérieures de la plate-forme Windows OS. Basé sur la plate-forme. NET Framework La technologie PowerShell 1.0 comprend une structure de commande cohérente (applets de commande), elle dispose de puissants outils de formatage de sortie intégrés et fournit une augmentation significative de la disponibilité d'autres technologies, et surtout, Windows Management Instrumentation (WMI). Cependant, bien que certains composés Commandes PowerShell 1.0 et objets. NET peut se connecter à des ordinateurs distants, cette fonction est implémentée de manière différentielle, selon le cas spécifique. Les commandes qui prennent en charge les connexions à distance ont le paramètre -ComputerName ; ils utilisent également des appels de procédure distante (RPC) ou DCOM pour établir des connexions.

Dans de nombreuses situations, RPC et DCOM font un bon travail de gestion, mais parfois des problèmes surviennent lors de l'exécution des diagnostics et de l'identification de la cause première des problèmes. Par exemple, la commande Get-Service peut lire les données de service à partir d'un ordinateur distant à l'aide du paramètre -ComputerName, mais cette commande n'a pas de paramètre -Credential et doit donc être connectée avec un compte autorisé à accéder au système distant pour l'exécuter.

Cependant, Windows PowerShell 2.0 introduit un mécanisme alternatif de connexion à des ordinateurs distants appelé communication à distance. Ce mécanisme utilise les outils du service Windows Remote Management (WinRM). Il fournit une connectivité à un ordinateur distant ainsi que le lancement de commandes exécutées sur cet ordinateur distant. Permettez-moi d'expliquer cela avec un exemple. Les connecteurs Bureau à distance font référence à une interface utilisateur graphique de la même manière que l'accès à distance à la ligne de commande PowerShell. Lorsque vous exécutez une commande composée à l'aide de la télécommande, la commande est en fait exécutée sur la machine distante, mais vous pouvez voir les résultats sur la machine locale.

Où obtenir Windows PowerShell 2.0

PowerShell 2.0 et WinRM sont inclus avec Windows 7 et Windows Server 2008 R2, donc si vous utilisez ces systèmes d'exploitation, vous n'avez pas besoin d'installer ces composants. Si vous travaillez avec Systèmes Windows Vista SP2, Windows XP SP3, Windows Server 2008 SP2 ou Windows Server 2003 SP2, vous devrez télécharger et installer Paquet Windows Management Framework Core (support.microsoft.com/kb/968930).

Activation de la fonctionnalité d'accès à distance

Pour que l'ordinateur puisse se connecter aux systèmes distants sur lesquels PowerShell est installé, les conditions suivantes doivent être remplies.

Le service WinRM doit être activé.
Un écouteur WinRM doit être installé qui accepte les connexions à partir d'une ou plusieurs adresses IP.
Pare-feu Windows doit être configuré pour pouvoir établir des connexions via WinRM.
La session PowerShell doit être activée et correctement configurée.

Si l'ordinateur n'accepte pas les connexions de PowerShells installés sur des ordinateurs distants, exécutez conditions spécifiées pas nécessaire.

Pour aider les utilisateurs à être opérationnels dès que possible, les développeurs Microsoft PowerShell ont créé la commande Enable-PSRemoting pour configurer automatiquement ces composants. Ce paramétrage n'a pas besoin d'être fait sur la machine avec laquelle vous allez interagir à distance, mais sur l'ordinateur auquel vous accéderez à distance. Vous pouvez exécuter la commande Enable-PSRemoting uniquement si vous utilisez PowerShell en tant qu'administrateur. Si vous travaillez avec Machines Windows Vista, Server 2008 et versions ultérieures, cliquez avec le bouton droit sur l'icône PowerShell et sélectionnez Exécuter en tant qu'administrateur dans le menu déroulant. Si vous exécutez la commande Enable-PSRemoting avec le paramètre -Force, le système ne vous demandera pas l'autorisation de terminer chaque étape de configuration lors de son exécution. Pour plus d'informations sur la commande composée Enable-PSRemoting, exécutez la commande

Get-Help Activer-PSRemoting

Exécuter une commande sur un ordinateur distant

Le moyen le plus simple de se connecter à PowerShell sur un ordinateur distant consiste à utiliser la commande Enter-PSSession. Par défaut, cette commande est exécutée avec le paramètre -ComputerName, vous n'avez donc pas besoin de spécifier ce paramètre lorsque vous le saisissez à partir du clavier. Par exemple, pour établir une connexion avec un ordinateur distant nommé rigel, saisissez à partir du clavier

PS C: \> Entrer-PSSession rigel

Veuillez noter que pour être complet, j'inclus une invitation dans le texte. Vous n'avez pas besoin d'entrer l'invite dans le cadre de la commande.

Après avoir entré une session à distance, la syntaxe de l'invite PowerShell change. Il inclura désormais le nom de l'ordinateur distant entre crochets ; cela signifie que vous avez établi une connexion à l'ordinateur distant. Dans ce cas, l'invitation ressemblera à ceci :

: PS C: \>

Après avoir établi connexion à distance toutes les commandes que vous entrez sur la ligne de commande seront exécutées sur la machine distante. Donc si vous entrez la commande

: PS C: \> Get-ChildItem C: \

la commande Get-ChildItem sera exécutée sur la machine distante. Sa sortie contiendra les noms des fichiers et dossiers stockés dans le lecteur C de l'ordinateur distant. Pour terminer la session distante, utilisez la commande Exit-PSSession

: PS C: \> Quitter-PSSession

Exécution d'un bloc de script sur un ordinateur distant

La communication à distance PowerShell vous permet d'exécuter un bloc de script, ou scriptblock (c'est-à-dire un bloc de code PowerShell entouré d'accolades) sur un ordinateur distant. Pour ce faire, vous devez utiliser la commande Invoke avec le paramètre -ComputerName. Par exemple, dans la commande illustrée à la figure 1, j'ai utilisé Invoke-Command pour exécuter Get-ChildItem sur un ordinateur distant. Lorsque vous examinez la figure 1, remarquez que je n'ai pas utilisé la commande Enter-PSSession pour établir une connexion à l'ordinateur distant avant d'exécuter le bloc de script. Enter-PSSession et Invoke-Command sont deux méthodes d'accès distant différentes.

Le premier paramètre de Invoke-Command est le paramètre -ScriptBlock ; il pointe vers le code que vous êtes sur le point d'exécuter. Dans la figure 1, j'ai omis le nom du paramètre -ScriptBlock car il est facultatif. Le paramètre -ComputerName contient le nom de l'ordinateur distant. Comme vous pouvez le voir dans la sortie de la commande Get-ChildItem, PowerShell répertorie même le nom de l'ordinateur distant dans la colonne PSComputerName de la sortie pour la commodité de l'opérateur.

Exécution d'un bloc de script sur plusieurs ordinateurs distants

Le bloc de script peut également être exécuté sur plusieurs ordinateurs distants. C'est ce qu'on appelle une configuration un-à-plusieurs ou un déploiement continu. Dans la figure 1, le paramètre -ComputerName pour Invoke-Command contient un seul nom, mais vous pouvez également inclure plusieurs noms d'ordinateur. Ainsi, la commande

PS C: \> Invoke-Command (Get-ChildItem env: co *) -Computer titan, rigel

permet à la commande Get-ChildItem de s'exécuter sur deux ordinateurs distants. Dans le texte de l'article, cette commande est découpée en plusieurs lignes, mais en Console PowerShell il doit être saisi sur une seule ligne. Il en va de même pour les autres commandes réparties sur plusieurs lignes. Comme dans la figure 1, la colonne PSComputerName dans la sortie contiendra les noms d'ordinateur.

Exécuter un bloc de script en arrière-plan

PowerShell 2.0 fournit des tâches en arrière-plan, ce qui signifie qu'un opérateur peut exécuter une commande en arrière-plan. Cette fonctionnalité est utile lors de l'exécution de commandes qui prennent beaucoup de temps.

Vous pouvez utiliser la commande Start-Job pour démarrer une tâche en arrière-plan sur l'ordinateur local. Mais je dois dire que cette commande n'a pas de paramètre -ComputerName, ce qui signifie qu'elle ne peut pas être utilisée pour exécuter une tâche en arrière-plan sur une machine distante. Au lieu de cela, vous devrez exécuter Invoke-Command avec le paramètre -AsJob. Par exemple, la commande top de la figure 2 lance le bloc de script en tant que tâche d'arrière-plan sur l'ordinateur distant titan. Après avoir entré cette commande, l'invite est immédiatement apparue à l'écran : PowerShell a envoyé un bloc de script pour exécution à l'ordinateur distant, puis m'a rendu le contrôle. L'avertissement indique que la commande exécutée ne tenait pas dans la fenêtre de la console et n'était donc pas incluse dans la sortie. Si j'avais une fenêtre de console plus large, le formateur PowerShell inclurait la commande dans la sortie. Les colonnes Id et Name indiquent la tâche (son identifiant et son nom convivial, respectivement) et la colonne State indique si la tâche est en cours, en pause ou terminée. La colonne HasMoreData contient des informations indiquant que toutes les données d'un travail donné ont été récupérées ou que le travail contient plus d'informations qui doivent être récupérées.

Vous pouvez exécuter la commande Get-Job pour déterminer si une tâche en arrière-plan est terminée, comme le montre la deuxième commande de la figure 2. Si vous n'utilisez aucun paramètre, Get-Job vérifie l'état de toutes les tâches en cours d'exécution dans la session en cours. . Si plusieurs tâches sont exécutées en même temps, vous pouvez utiliser des options telles que -Id ou -Name pour spécifier la tâche que vous souhaitez vérifier. Une fois le travail en arrière-plan terminé, la colonne État de la sortie sera Terminé.

Vous pouvez utiliser la commande Receive-Job pour lire les résultats d'une tâche en arrière-plan. Cette commande, comme la commande Get-Job, renvoie la sortie de tous les travaux démarrés dans la session en cours, sauf si vous avez utilisé un paramètre pour indiquer le travail qui vous intéresse. Par exemple, la dernière commande de la figure 2 inclut le paramètre -Id, qui indique que vous souhaitez obtenir la sortie pour l'ID de travail 9. J'ai omis le nom du paramètre -Id car il est facultatif. La figure 3 montre les dernières lignes de sortie liées à l'exécution de la tâche d'arrière-plan distante en question.

Création de sessions PowerShell

Les exemples ci-dessus montrent comment accéder à l'invite PowerShell sur une machine distante et comment exécuter des commandes sur des ordinateurs distants. Mais je n'ai pas encore mentionné que le remoting se fait toujours dans le cadre de la session. Une session est, dirons-nous, la maison de PowerShell. Lorsque vous ouvrez une fenêtre PowerShell Console ou une fenêtre PowerShell Integrated Scripting Environment (ISE), vous créez une session. Sans télécommande, toutes les sessions s'exécutent sur l'ordinateur local et sont indépendantes les unes des autres. Tous les exemples de communication à distance ci-dessus créent des sessions temporaires qui se terminent automatiquement à la fin de la communication à distance. De plus, il est possible d'instancier des sessions à distance et de les réutiliser. Cette approche est beaucoup plus efficace lorsque vous devez accéder plusieurs fois à des ordinateurs distants.

Pour créer de nouvelles sessions, utilisez la commande New-PSSession avec le paramètre -ComputerName. Le nom de ce paramètre peut être omis dans les commandes. Ainsi, la commande

C: \> $ sessions = Nouvelle-PSSession phineas, ferb, poiré

crée trois sessions sur trois ordinateurs nommés phineas, ferb et perry. Vous pouvez afficher ces sessions en créant la variable $ sessions. Pour ce faire, entrez le nom sur la ligne de commande

$ séances

et appuyez sur Entrée. Le paramètre -Session d'Invoke-Command prend en charge les objets de session créés avec la commande New-PSSession, vous pouvez donc utiliser une commande comme celle-ci :

C: \> Invoke-Command (Get-ChildItem) -session $ sessions

Cette commande exécute la commande Get-ChildItem sur les machines phineas, ferb et perry, mais ne se déconnecte pas. Vous pouvez ajouter le paramètre -AsJob et exécuter la commande en arrière-plan :

C: \> Invoke-Command (Get-ChildItem) -session $ sessions -asjob

Une nouvelle approche du travail

La communication à distance PowerShell est un nouveau mécanisme puissant pour exécuter des commandes sur des ordinateurs distants. J'espère que cet article vous motivera à explorer de nouvelles possibilités. Des informations plus détaillées sur la communication à distance, y compris les problèmes de diagnostic, sont disponibles dans les rubriques de référence PowerShell about_Remote sur technet.microsoft.com/en-us/library/dd347616.aspx.

Bill Stewart ( [email protégé]) - Administrateur système et réseau pour la morgue française, Nouveau-Mexique

Gestion à distance à l'aide de PowerShell

Il existe plusieurs méthodes pour travailler avec des ordinateurs distants. Il y a Gestion des fenêtres Instrumentation (WMI), largement utilisé en VBScript. Il existe divers utilitaires qui permettent le contrôle à distance, tels que ceux de Sysinternals. Même de nombreuses applets de commande PowerShell ont un paramètre ComputerName à exécuter sur des ordinateurs distants.

En général, il existe de nombreuses méthodes, mais chacune d'entre elles a ses inconvénients. Premièrement, la syntaxe est différente, ce qui est facile à confondre. Deuxièmement, certaines commandes se comportent différemment selon qu'elles sont exécutées localement ou à distance. Enfin, la communication peut nécessiter l'ouverture de ports supplémentaires sur le pare-feu, ce qui n'est pas bon d'un point de vue sécurité.

Télécommande PowerShell résout la plupart des problèmes décrits. Il est basé sur l'implémentation par Microsoft du protocole Web Services for Management (WS-Management) et utilise un service (WinRM) pour la communication. La communication entre les ordinateurs se fait via HTTP (par défaut) ou HTTPS. Tout le trafic entre deux ordinateurs est crypté au niveau du protocole (sauf lorsque SSL est utilisé). Plusieurs méthodes d'authentification sont prises en charge, notamment NTLM et Kerberos.

Contrairement aux utilitaires qui utilisent différentes interfaces de programmation, PS Remoting fonctionne comme suit : les commandes saisies sur l'ordinateur local sont transmises à l'ordinateur distant et y sont exécutées, puis le résultat est renvoyé. Étant donné que toutes les commandes sont exécutées localement, il n'y a pas besoin de s'inquiéter de la compatibilité. De plus, PS Remoting n'a besoin que d'un port ouvert sur le pare-feu.

Il existe plusieurs façons de le gérer à l'aide de PowerShell Remoting.

Contrôle individuel

Le moyen le plus simple de contrôler à distance est d'ouvrir de manière interactive séance à distance et y effectuer les actions nécessaires. Par exemple, ouvrons une session sur l'ordinateur SRV4 et redémarrons le service d'impression sur celui-ci :

Enter-PSSession -ComputerName SRV4
Restart-Service - Spouleur de nom

Voyons l'état du service et fermons la session à distance :

Get-Service - Spouleur de noms
Quitter-PSSession

Le travail interactif est adapté à la résolution tâches simples gestion à distance. Si vous devez automatiser le processus, il est préférable d'utiliser l'applet de commande Invoke-Command. Voici comment vous pouvez faire la même action avec :

Invoke-Command -ScriptBlock (spouleur de redémarrage du service) -ComputerName SRV4

Cette commande ouvrira une session à distance sur SRV4, exécutera le bloc de commande spécifié dans le paramètre -ScriptBlock et fermera la session. Et pour exécuter le travail en arrière-plan, vous pouvez éventuellement spécifier le paramètre -AsJob.

Gardez à l'esprit que lors de l'exécution en arrière-plan, PowerShell ne renvoie pas de résultat. Pour l'obtenir, vous devrez utiliser l'applet de commande Receive-Job.

Afin d'exécuter non pas quelques commandes, mais un script, Invoke-Command a un paramètre –FilePath, qui peut être utilisé à la place de –ScriptBlock pour définir un fichier de script. À titre d'exemple, j'ai créé un script qui répertorie les services arrêtés et l'ai exécuté sur une machine SRV4 distante :

Invoke-Command -FilePath.\ Script.ps1 -ComputerName SRV4

Gestion un-à-plusieurs

Assez souvent, il devient nécessaire d'exécuter une tâche en parallèle sur plusieurs ordinateurs. Cela peut être fait assez facilement en utilisant la même Invoke-Command. Par exemple, les noms d'ordinateurs peuvent être simplement répertoriés, séparés par des virgules :

Invoke-Command -ScriptBlock (spouleur de redémarrage du service) -ComputerName SRV4, SRV5

Placer dans la variable :

$ serveurs = @ (″ SRV1 ″, ″ SRV2 ″, ″ SRV3 ″)
Invoke-Command -ScriptBlock (spouleur de redémarrage du service) -ComputerName $ serveurs

Ou prenez dans le fichier :

Invoke-Command -ScriptBlock (spouleur de redémarrage du service) -ComputerName`
(Obtenir le contenu. \ Servers.txt)

Noter: Invoke-Command a un paramètre ThrottleLimit limitant quantité maximale ordinateurs qui peuvent être contrôlés en même temps. Par défaut, ce paramètre est 32. Vous pouvez le modifier si nécessaire, mais notez que l'augmentation de ce paramètre augmentera la charge sur le processeur et la mémoire de votre ordinateur, cette opération doit donc être effectuée avec beaucoup de précautions.

Séances

Chaque fois que vous exécutez Invoke-Command, une nouvelle session est créée, ce qui prend du temps et des ressources à créer. Pour éviter cela, nous pouvons ouvrir une session dans laquelle exécuter toutes les commandes. Par exemple, ouvrons une session nommée SRV4 sur l'ordinateur SRV4 et mettons-la dans la variable de session $, puis cette session effectuera notre tâche (arrêtez le spouleur qui souffre depuis longtemps) :

$ session = New-PSSession -ComputerName SRV4 -Name SRV4
Invoke-Command -ScriptBlock (Spouleur Get-Service | Stop-Service) `
-Séance $ séance

La session sera active jusqu'à ce que nous quittions la console PowerShell. Vous pouvez également fermer la session - Disconnect-PSSession ou supprimer - Remove-PSSession.

Voici maintenant quelques fonctionnalités intéressantes introduites dans PowerShell 3.0. Si plus tôt, lorsque vous quittez la session ou fermez la console, la session a été supprimée, alors dans PS 3.0, lorsque vous fermez la session, elle passe à l'état débranché... Nous pouvons ouvrir une nouvelle session sur le même (ou tout autre) ordinateur et exécuter la commande directement dans cette session déconnectée. A titre d'exemple, nous démarrons le service d'impression sur l'ordinateur SRV4, qui a été arrêté la dernière fois :

Invoke-Command -ScriptBlock (spouleur de démarrage du service) `
-Nom de l'ordinateur SRV4 -Déconnecté

Une autre option pour utiliser des sessions déconnectées consiste à lancer des tâches chronophages. Par exemple, ouvrons une session nommée LongJob sur SRV4 et lançons une tâche en arrière-plan dedans, qui affichera une liste de services avec un intervalle de 1 minute :

$ session = New-PSSession -ComputerName SRV4 -Name LongJob
Invoke-Command -Session $ session -ScriptBlock`
(Get-Service | foreach ($ _; sleep 60)) -AsJob

Voyons comment la tâche est effectuée et fermons la session :

Receive-Job -Nom Job2
Déconnecter-PSSession $ session

Nous allons sur un autre ordinateur et ouvrons la console, nous connectons à la session LongJob et utilisons l'applet de commande Receive-PSSession pour obtenir le résultat de la tâche :

Connect-PSSession -Name LongJob -ComputerName SRV4
Receive-PSSession -Name LongJob

Ou une autre option, sans se connecter explicitement à la session à l'aide de Connect-PSSession :

$ session = Get-PSSession -Name LongJob -ComputerName SRV4
$ job = Receive-PSSession $ session -OutTarget Job
Recevoir-Travail $ travail

Noter: pour que le résultat reste dans le système, Receive-Job doit être utilisé avec le paramètre -Keep.

Télécommande implicite

Une autre méthode de contrôle à distance, plutôt non conventionnelle, est la télécommande implicite. En l'utilisant, vous pouvez exécuter localement des applets de commande situées sur l'ordinateur distant sans créer de session à distance.

Par exemple, prenons un poste de travail ordinaire sans outils d'administration à distance installés. Créez une session à distance avec le contrôleur de domaine SRV4 et importez le module dans cette session Active Directory:

$ session = New-PSSession - ComputerName SRV4
Invoke-Command (Import-Module ActiveDirectory) -Session $ session

Ensuite, nous exportons les applets de commande Active Directory de la session distante et les plaçons dans le module RemoteAD local :

Export-PSSession -Session $ session -CommandName * -AD * -OutputModule RemoteAD`
-AutoriserClobber

Cette commande créera un nouveau module PowerShell dans le dossier WindowsPowerShell \ Modules \ RemoteAD. Seules les applets de commande avec des noms correspondant au modèle * -AD * seront chargées. Cependant, les applets de commande elles-mêmes ne sont pas copiées dans ordinateur local... Le module local sert en quelque sorte de raccourci et les commandes elles-mêmes seront exécutées sur le contrôleur de domaine distant.

Après avoir créé le module, la session à distance peut être fermée, elle n'est plus nécessaire.

Nous importons le nouveau module dans la session en cours (dans PS 3.0, vous pouvez sauter cette étape) :

Importer-Module RemoteAD

Attention maintenant - nous n'ouvrons pas de session à distance avec le contrôleur de domaine où se trouvent les applets de commande. Vous n'avez pas besoin de démarrer explicitement cette session - cela peut être fait implicitement en essayant d'exécuter des applets de commande distantes :

Nouveau-ADUser -Nom BillGates -Société Microsoft
Get-ADUser BillGates

Cela restaurera la connexion à distance au contrôleur de domaine, après quoi la commande sera envoyée au contrôleur de domaine et exécutée là-bas. Le résultat de l'exécution sera sérialisé en XML et transmis sur le réseau à l'ordinateur local, où il sera désérialisé en objets avec lesquels PowerShell peut fonctionner.

La session à distance restera active jusqu'à ce que vous fermiez la console ou désinstalliez le module RemoteAD.

Le contrôle à distance implicite vous permet de travailler avec des applets de commande sur un ordinateur distant de la même manière que si elles étaient installées sur l'ordinateur local. Dans le même temps, toutes les applets de commande nécessaires sont toujours à portée de main, ce qui est très pratique.

En conclusion, je dirai qu'à l'heure actuelle, PowerShell Remoting est le principal outil de gestion à distance des systèmes d'exploitation Windows. Par conséquent, tout administrateur Windows doit connaître ses capacités et pouvoir les utiliser.

Cet article explique en détail le sujet de la communication à distance à l'aide de PowerShell 2.0. Tout d'abord, nous devons démarrer le service avec lequel la communication à distance sera effectuée.

Nous démarrons le service WinRm
Pour la communication à distance, PowerShell 2.0 utilise le service WinRM, qui est préinstallé sur Windows 7 et Windows 2008 R2 par défaut. Pour plus les premières versions système opérateur il doit être installé en plus. Le service spécifié est installé sur la machine lorsque installation de PowerShell 2.0. Pour vérifier que WinRM est présent, démarrez la console PowerShell 2.0 et exécutez la commande dedans :
Get-Service WinRm
Le résultat ressemblera à ceci :

Nom d'état DisplayName ------ ---- ----------- Winrm Windows Remote Management (WS-Manag ...

Comme vous pouvez le voir, le service est présent, mais pas démarré. Pour démarrer WinRm, vous devez exécuter la commande depuis la console PowerShell 2.0 avec les droits d'administrateur :
Activer-PSRemoting
A la demande de confirmation du démarrage du service, appuyez sur la touche "Y". Le service WinRM est maintenant défini sur le type de démarrage « Automatique » ; il s'exécutera à chaque démarrage de l'ordinateur. La commande Enable-PSRemoting démarre non seulement le service et modifie son type de démarrage, mais configure également correctement le pare-feu pour qu'il fonctionne correctement. Le service WinRm accepte les demandes de n'importe quelle adresse IP.

Nous demandons les noms de tous les fournisseurs connectés :
Obtenir-PSProvider
Comme vous pouvez le voir, nous avons maintenant un autre fournisseur appelé WSMan.
Attribution de nœuds de confiance

Dans la console PowerShell 2.0, exécutez les commandes avec les droits d'administrateur :

Set-Location –Path WSMan : Set-Location –Path localhost \ client Get-ChildItem

Noter
Notez que dans la première commande, la valeur du paramètre –Path se termine par deux points car il s'agit d'un fournisseur.

Sur l'ordinateur avec lequel vous souhaitez travailler à distance, vous devez spécifier quels serveurs sont autorisés à se connecter à cette machine. Ces serveurs sont appelés "sites de confiance". Ainsi, si vous êtes sur le serveur "MyServer", alors avant de pouvoir travailler à distance avec l'ordinateur "MyComputer", vous devez configurer les hôtes de confiance (TrustedHosts). La méthode suivante d'attribution de sites de confiance est utilisée lorsque l'ordinateur n'est pas membre d'un domaine Active Directory. Si l'ordinateur est membre d'un domaine Active Directory, les paramètres TrustedHosts peuvent être configurés via la stratégie de groupe.

Important!
La commande ci-dessous ne fonctionnera pas si WSMan:\localhost\client n'est pas installé dans le répertoire courant (voir l'appel de commande que nous avons fait ci-dessus).

Set-Item TrustedHosts *

Vous pouvez exécuter la commande à partir d'un répertoire différent, mais vous devez ensuite spécifier le chemin complet vers TrustedHosts :

Set-Item WSMan : \ localhost \ Client \ TrustedHosts *

Sur la demande de confirmation, appuyez sur la touche "Y".

Pour que PowerShell puisse voir les modifications que nous avons apportées aux paramètres TrustedHosts, vous devez redémarrer le service WSMan. Cela se fait avec la commande suivante :
Service de redémarrage winrm

Une action similaire peut être effectuée sous DOS. Exécutez la commande winrm - ?. Vous verrez une aide générale pour la commande. Pour afficher la valeur actuelle de TrustedHosts, exécutez la commande :

winrm obtenir winrm / config / client

et pour définir la valeur, vous devez exécuter :

winrm set winrm / config / client / @ (TrustedHosts = "*")

Dans les commandes ci-dessus, pour TrustedHosts, le symbole "*" a été spécifié comme valeur, cependant, au lieu de cela, vous pouvez spécifier les noms de serveurs spécifiques. La gestion de TrustedHosts est un cas classique d'utilisation conjointe des verbes Get et Set de PowerShell : vous utilisez Get-Item et Set-Item.
Création et fermeture d'une session PowerShell 2.0 à distance
Dans les commandes ci-dessous, au lieu de "IpAddress", spécifiez l'adresse IP souhaitée, et au lieu de "FQDN", spécifiez le nom de domaine complet :

Entrez-PSSession IpAddress

Entrez-PSSession FQDN

Pour mettre fin à une session de travail à distance, exécutez la commande :

La commande Enter-PSSession requiert un nom de domaine complet. Par exemple, dans le cas de MyServer.domain.local, la simple spécification de MyServer ne fonctionnerait pas, mais l'utilisation de l'adresse IP fonctionne toujours bien dans des situations comme celle-ci. Méthode alternative de session PS :

New-PSSession -nom_ordinateur testMachine2 Get-PSSession

Vous pouvez terminer cette session comme ceci :

Obtenez-PSSession | supprimer-PSSession

Si vous souhaitez tester le travail à distance, mais que vous n'avez pas de deuxième machine, créez alors une "connexion à distance" de votre ordinateur avec vous-même. Par exemple, si votre machine s'appelle "MyMachine", essayez ceci :

New-PSSession -nom_ordinateur MaMachine

Cela peut vous sembler étrange et pas logique, mais de cette façon, vous pouvez toujours essayer le travail à distance dans PowerShell 2.0.

Travailler dans une session PowerShell 2.0 à distance
Après avoir créé une connexion à distance, vous pouvez organiser les pipelines de commandes en les exécutant dans la console PowerShell 2.0, mais en même temps, ils seront exécutés sur la machine distante, comme si vous étiez à son clavier et que vous tapiez des commandes là-bas, pas ici. Par exemple, exécutez une commande comme celle-ci et voyez le résultat de son travail :

Ensemble-Emplacement c: \ | Obtenir-élément enfant

Étant donné que l'objectif principal de ce didacticiel est de vous aider à créer une session de connexion à distance PowerShell 2.0 et de vous montrer comment la fermer, vous devrez décider vous-même des opérations que vous souhaitez effectuer lors de la connexion à distance.

Noter
S'il vous semble qu'une commande ne fonctionne pas pour une session de connexion à distance, testez-la d'abord sur votre machine locale.

Dès que la connexion à distance fonctionne pour vous, elle vous donne immédiatement la possibilité d'utiliser PowerShell 2.0 pour gérer les ordinateurs connectés à votre réseau. Vous pouvez désormais exécuter des scripts sur d'autres machines. Dans PowerShell 2.0, de nombreuses applets de commande prennent en charge le paramètre "-computerName", mais une connexion à distance vous permet d'utiliser les commandes de la famille PSSession ainsi que d'appeler Invoke-Command (c'est-à-dire que vous pouvez faire ce que vous voulez).

Dépannage des problèmes de télécommande PowerShell 2.0

Un problème courant est l'ERREUR « L'accès est refusé ».

Solution:
Exécutez PowerShell 2.0 en tant qu'administrateur. Essayez sur les deux machines (celle à laquelle vous vous connectez et celle à laquelle vous vous connectez) pour définir le paramètre "TrustedHosts" sur * (astérisque). N'oubliez pas que cette option permet des connexions de n'importe où.
N'oubliez pas de redémarrer le service WinRm, sinon les modifications que vous avez apportées à "TrustedHosts" ne prendront pas effet. Pour redémarrer le service, exécutez la commande dans la console PowerShell 2.0 : Restart-Service WinRm
Veillez également à ne pas confondre le nom du fournisseur WSMan avec le nom du service WinRm.
Un autre conseil étrange, mais parfois utile : essayez de réessayer la connexion à distance. Étrangement, cela pourrait ne pas fonctionner du premier coup, mais cela pourrait fonctionner au deuxième ou au troisième. Celles. vous devez réexécuter la commande : Enter-PSSession -computerName myOtherMachineName

Les pare-feu, PowerShell 2.0 et le serveur rpc ne sont pas disponibles
Les spécialistes de la sécurité lèveront la main avec horreur devant une telle proposition, cependant, en cas de réception de l'erreur ci-dessus, je vous suggère de désactiver le pare-feu sur les deux ordinateurs. Si tout fonctionne correctement après l'arrêt, vous devez vérifier l'utilisation des ports 135 et 445. Configurez des exceptions pour ces ports dans les pare-feu - cela permettra à PowerShell 2.0 de fonctionner à distance et en même temps, le pare-feu protégera l'ordinateur contre des menaces.

P.S. J'ai lu que la commande Enable-PSRemoting devrait prendre en charge les modifications automatiques des paramètres du pare-feu, mais d'après mon expérience, ce n'est pas toujours le cas.
Pour plus d'informations sur la façon de désactiver le pare-feu dans Windows 8 à l'aide de la stratégie de groupe, lisez.

Deux types utilisés pour le travail à distance dans PowerShell 2.0
Il est temps d'annoncer qu'il existe deux options pour le travail à distance dans PowerShell 2.0.
La première méthode est une variante plus sophistiquée qui utilise des applets de commande pour créer un canal persistant vers la deuxième machine. Les noms de telles commandes contiennent le mot "PSSession" comme nom (rappelez-vous que les noms des applets de commande sont construits selon la règle "Verb-Noun"). Vous pouvez obtenir une liste de ces applets de commande à l'aide de la commande suivante :

Get-Command -nom PSSession

La deuxième façon est également la forme plus canonique du travail à distance PowerShell 2.0. Cette méthode développe simplement les commandes locales en ajoutant le paramètre "-computerName", qui spécifie l'ordinateur distant sur lequel effectuer l'opération. Par conséquent, ces commandes seront exécutées sur une autre machine du réseau :

Get-Process -computerName machine2

Liste des applets de commande qui peuvent être utilisées comme ceci d'une manière simple(c'est-à-dire ceux qui ont le paramètre "-computerName") peuvent être obtenus à l'aide de la commande suivante :

Obtenir la commande | où ($ _. parameters.keys -contient "NomOrdinateur")

Une liste complète des applets de commande pouvant fonctionner de la deuxième manière peut être obtenue comme suit :

Obtenir la commande | où ($ _. parameters.keys -contains "ComputerName" -et ($ _. parameters.keys -notContains "Session"))

Résumer le travail à distance dans PowerShell 2.0
Le secret pour travailler à distance avec PowerShell 2.0 est de comprendre les choses de base :
Installez WinRm.
La communication à distance doit être activée à l'aide de la commande Enable-PSRemoting.
Vous devez configurer TrustedHosts (par exemple, définissez-le comme valeur *).
Lorsque vous utilisez la commande Enter-PSSession, n'oubliez pas de spécifier le nom d'hôte complet ou l'adresse IP.

Une source d'information en anglais présentée et légèrement révisée par moi.

# Créer une nouvelle session pour se connecter à la machine distante $ s = New-PSSession -computername TestComputer

# Effectuez des actions arbitraires sur la machine distante, par exemple - regardez le contenu du répertoire C :
Invoke-Command -Session $ s -ScriptBlock (ls c: \)

# Créer le répertoire "% ProgramFiles% \ MyCompany \ MySoft" sur la machine distante
Invoke-Command -Session $ s -ScriptBlock (New-Item -Path "$ env: ProgramFiles \ MyCompany \ MySoft" -ItemType directory)

# Cependant, il est beaucoup plus pratique de ne pas saisir manuellement les commandes, mais d'exécuter un script prêt à l'emploi sur une machine distante :
Invoke-Command -Session $ s -FilePath "\\ ServerDir \ Common Scripts \ MyScript.ps1"

# Terminer la session
$ s | supprimer-PSSession

Didacticiel

Il y a un minimum de théorie, principalement une partie pratique. Il décrit comment configurer WinRM, comment modifier le profil d'une carte réseau, fournit un script pour l'ajout à TrustedHosts avec filtrage, explique pourquoi les hôtes de confiance sont nécessaires et le couvre de manière superficielle. connexions à distance afin que vous puissiez vous asseoir et administrer immédiatement les machines distantes.

La façon la plus simple de configurer la télécommande est de Activer-PSRemoting en powershell avec des privilèges d'administrateur. Dans ce cas, les événements suivants se produiront :

le service WinRM démarrera (s'il est démarré, il redémarrera)
le service WinRM passera à l'état - démarrage automatique au démarrage
un écouteur WinRM sera créé pour HTTP trafic sur le port 5985 pour toutes les adresses IP locales
une règle de pare-feu sera créée pour l'écouteur WinRM. Attention, cet élément se terminera par une erreur si l'une des cartes réseau est de type réseau "public", car ouvrir un port sur une telle carte n'est pas bon. Si vous obtenez une telle erreur lors de la configuration, modifiez le profil de cette fille réseau à l'aide de l'applet de commande Set-NetConnectionProfile et après cela, exécutez à nouveau Enable-PSRemoting. Si vous avez besoin d'une carte réseau avec le profil "Public Network", exécutez Enable-PSRemoting avec le paramètre -SkipNetworkProfileCheck dans ce cas, les règles de pare-feu ne seront créées qu'à partir de réseau local.

Après cela, vous devez autoriser la connexion à la machine distante à partir de la machine à partir de laquelle le contrôle aura lieu. Ceci est fait pour des raisons de sécurité afin de réduire le risque de piratage de la session de contrôle à distance ou du DNS en se substituant à la machine distante et d'empêcher l'exécution de scripts sur des machines que vous n'avez pas autorisées de force.

Pour vérifier où vous pouvez vous connecter, utilisez :
get-item wsman: \ localhost \ Client \ TrustedHosts
pour la permission de se connecter à tous
set-item wsman: localhost \ client \ Trustedhosts -value *
Si vous ouvrez l'accès à tous en spécifiant *, WinRM se connectera à TOUTES les machines sans vérification. N'oubliez pas que vous vous exposez à un piratage potentiel de votre réseau local. Il est préférable de spécifier les adresses des hôtes auxquels vous devez vous connecter, WinRM rejettera alors toutes les autres adresses ou noms. Si la machine à partir de laquelle elle est gérée se trouve dans un domaine, elle fera confiance à toutes les machines de ce domaine. Si ce n'est pas dans un domaine, ou dans un autre domaine, alors vous devez spécifier dans TrustedHosts l'adresse ou le nom de la machine à laquelle nous allons nous connecter. Il n'est pas nécessaire de s'ajouter sur la machine à laquelle nous nous connectons.

L'aide contient des commandes, je les ai légèrement modifiées en script
################################################## # #################################### # ajoute NewHost à la liste TrustedHost avec filtrage si une telle ligne existe déjà # vous pouvez sortir ligne de commande en spécifiant directement le paramètre par exemple #. \ Add-TrustedHost.ps1 192.168.2.1 ################################# # ################################################## # param ($ NewHost = "192.168.2.89") Write-Host "ajout d'hôte: $ NewHost" $ prev = (get-item WSMan: \ localhost \ Client \ TrustedHosts) .value if (($ prev.Contains ($ NewHost) )) -eq $ false) (if ($ prev -eq "") (set-item WSMan: \ localhost \ Client \ TrustedHosts -Value " (! LANG: $ NewHost" } else { set-item WSMan:\localhost\Client\TrustedHosts -Value "$ précédent, $ NouvelHôte" } } Write-Host "" Write-Host "Now TrustedHosts contains:" (get-item WSMan:\localhost\Client\TrustedHosts).value !}
il vérifie s'il existe une telle entrée, sinon, l'ajoute à la liste. Vous pouvez appeler à partir de la ligne de commande en spécifiant l'adresse ou le nom.

Cela fait une différence d'indiquer un nom ou une adresse. S'il n'y a qu'une adresse dans TrustedHosts, cela ne fonctionnera pas pour ouvrir une session par nom, et vice versa - si vous spécifiez un nom, cela ne fonctionnera pas pour attacher à l'adresse. Considère ceci.

quelle est la différence

Enable-PSRemoting fait plus que "winrm quickconfig". L'applet de commande Set-WSManQuickConfig fait exactement la même chose que « winrm quickconfig ». Enable-PSRemoting exécute Set-WSManQuickConfig lors de la configuration du système

Connexions à distance
1. Séances 1 à 1
ouvert par l'équipe
Enter-PSSession -ComputerName Test
Vous obtiendrez un shell sur la machine distante. Vous pouvez vous connecter à vous-même en spécifiant localhost. Les crédits alternatifs sont spécifiés avec le paramètre -Authentification, la sortie se fait par l'applet de commande Quitter-PSSession

Les restrictions sont les suivantes :

vous ne pouvez pas faire un deuxième saut - seulement 1 session, vous ne pouvez pas vous connecter plus loin à l'intérieur de la session
vous ne pouvez pas utiliser de commandes qui ont interface graphique... Si vous faites cela, le shell se bloquera, appuyez sur Ctrl + C pour se bloquer
vous ne pouvez pas exécuter de commandes qui ont leur propre shell, par exemple nslookup, netsh
vous pouvez exécuter des scripts si la politique de lancement sur la machine distante leur permet de s'exécuter
vous ne pouvez pas vous attacher à une session interactive, vous vous connectez en tant que "connexion réseau" comme s'il s'accrochait à lecteur réseau... Par conséquent, les scripts d'ouverture de session ne démarreront pas et vous risquez de ne pas obtenir le dossier de départ sur la machine distante (une raison supplémentaire de ne pas mapper les dossiers de départ avec les scripts d'ouverture de session)
vous ne pourrez pas interagir avec l'utilisateur sur la machine distante même s'il y est connecté. Vous ne pourrez pas lui montrer la fenêtre ou lui imprimer quoi que ce soit.

cette méthode est la meilleure pour les opérations simples, se connecter, secouer le serveur et se déconnecter. Si vous devez conserver des variables dans la portée, vous avez besoin d'une opération longue (plusieurs heures ou jours), vous avez besoin de plus d'options d'administration, puis vous devez utiliser une technique plus avancée.

Un commentaire.
les objets transmis sur le réseau sont coupés et cessent d'être vivants. Leurs méthodes sont supprimées, les propriétés restent. Tirer un objet sur votre voiture, le conjurer et le repousser ne fonctionnera pas. Si vous avez besoin d'écrire plus, je l'ajouterai séparément.

2. 1-à-plusieurs sessions
Invocation-Commande
nous définissons ce que nous allons exécuter comme ceci :
$ sb = (commandes pour la machine distante séparées par des points-virgules)
transfert vers des machines distantes Test1 et Test2
Invoke-Command -ComputerName Test1, Test2 -ScriptBlock $ sb
peut être lancé sur 32 voitures à la fois. Si des crédits alternatifs, utilisez le paramètre -Credential

Pour transmettre l'intégralité du script au lieu du paramètre -ScriptBlock, écrivez -FilePath, la machine distante n'a PAS besoin d'avoir accès au fichier, il sera analysé en parties, transféré via HTTP et exécuté de l'autre côté.

N'oubliez pas qu'il y aura une nouvelle portée de l'autre côté, donc votre script ne recevra pas de valeurs de votre console, et les variables de script peuvent être vides de ce côté. Par conséquent, transférez des instructions et des scripts prêts à l'emploi avec des paramètres à la fois.

pour utiliser pleinement Invoke-Command, vous devez être capable de transformer les lignes en blocs de script. Par exemple, vous avez des commandes qui dépendent d'une liste, vous devez générer une chaîne, la transformer en ScriptBlock et l'envoyer à un ordinateur distant :
$ sb = :: Créer ($ SomeString)

kuda78
L'article manque un très point important- passer des paramètres à un script sur une machine distante.
$ deployRemote = (
param (
$ targetEnvName,
$ targetUsername)
$ Global : ErrorActionPreference = "Stop"
#…
}
Invoke-Command -Session $ session -ScriptBlock $ deployRemote -ArgumentList ($ targetEnvName, $ targetUsername)

Oui en effet raté. Je l'ai fait délibérément pour ne pas encombrer la revue de paramètres et de descriptions. Merci. Le paramètre -ArgumentList fonctionne à la fois avec les blocs de script et les scripts

3. Séances
C'est à ce moment qu'une copie de la pièce est créée de l'autre côté, qui est constamment suspendue dans la mémoire, et des commandes lui sont envoyées. En conséquence, vous pouvez vous y reconnecter, lire un long run pour l'exécution, vous accrocher à différents scripts ou à différents utilisateurs. Par exemple, vous avez un ensemble de scripts qui résolvent une tâche en plusieurs parties, chacun d'eux peut à son tour se connecter à une session à distance, voir les résultats des commandes précédentes, avoir un module chargé, des variables communes, un environnement commun, jusqu'à la session est fermé de force.

La session est créée à l'aide de l'applet de commande New-PSSession, le résultat peut être placé dans une variable
$ DC01 = New-PSSession - ComputerName DC01 $ Controllers = New-PSSession DC01, DC02, DC03
vous pouvez utiliser les mêmes paramètres de connexion que dans Invoke-Command

Comment utiliser:
si 1 pour 1
Entrer-PSSession -Session $ DC01
si 1-à-plusieurs
Invoke-Command -Sessions $ Controllers -ScriptBlock (get-eventlog -logname security -newest 50)
vous pouvez voir quelles sessions sont ouvertes en utilisant Get-PSSession, fermez Remove-PSSession
fermer toutes les sessions complètement
Obtenez-PSSession | Supprimer-PSSession
vous pouvez vous connecter à la session en utilisant Connect-PSSession, vous déconnecter via Disconnect-PSSession

Invoke-Command peut créer immédiatement une session déconnectée, il envoie des commandes pour l'exécution et se déconnecte, plus tard vous pouvez vous connecter et télécharger les résultats du travail. Ceci est fait avec le paramètre -Disconnected. Récupération des résultats via l'applet de commande Recieve-PSSession.

Les sessions ont beaucoup de paramètres, il est même possible de créer des sessions avec un ensemble tronqué de commandes, de modules, etc. Points de terminaison personnalisés appelés