Questions fréquentes (FAQ) sur la communication à distance PowerShell

Oui. Pour travailler à distance, les ordinateurs locaux et distants doivent disposer de PowerShell, de Microsoft .NET Framework et du protocole WS-Management (Web Services for Management). Tous les fichiers et toutes les autres ressources nécessaires pour exécuter une commande particulière doivent se trouver sur l’ordinateur distant.

Les ordinateurs exécutant Windows PowerShell 3.0 et les ordinateurs exécutant Windows PowerShell 2.0 peuvent se connecter à distance entre elles et exécuter des commandes distantes. Toutefois, certaines fonctionnalités, comme la possibilité de se déconnecter d’une session et de s’y reconnecter, ne fonctionnent que lorsque les deux ordinateurs exécutent Windows PowerShell 3.0.

Vous devez avoir l’autorisation de vous connecter à l’ordinateur distant, l’autorisation d’exécuter PowerShell, mais également l’autorisation d’accéder aux magasins de données (tels que les fichiers et dossiers) et au registre sur l’ordinateur distant.

Pour plus d’informations, consultez about_Remote_Requirements.

Lorsque vous envoyez une commande distante, la commande est transmise à travers le réseau au moteur PowerShell sur l’ordinateur distant et s’exécute dans le client PowerShell sur l’ordinateur distant. Les résultats de la commande sont renvoyés à l’ordinateur local et y apparaissent dans la session PowerShell.

Pour transmettre les commandes et recevoir la sortie, PowerShell utilise le protocole WS-Management. Pour obtenir des informations sur le protocole WS-Management, consultez le protocole WS-Management dans la documentation Windows.

À compter de Windows PowerShell 3.0, les sessions à distance sont stockées sur les ordinateurs distants. Cela vous permet de vous déconnecter de la session et de vous y reconnecter à partir d’une autre session ou d’un autre ordinateur sans interrompre les commandes ou perdre l’état.

Lorsque vous vous connectez à un ordinateur distant, le système utilise les informations d’identification (nom d’utilisateur et de mot de passe) sur l’ordinateur local ou les informations d’identification que vous fournissez dans la commande pour vous connecter à l’ordinateur distant. Les informations d’identification et le reste de la transmission sont chiffrées.

Pour ajouter une protection supplémentaire, vous pouvez configurer le protocole SSL (Secure Sockets Layer) sur l’ordinateur distant (plutôt que le protocole HTTP) pour écouter les requêtes WinRM (Windows Remote Management). Les utilisateurs peuvent ensuite utiliser le paramètre UseSSL des cmdlet Invoke-Command, New-PSSession et Enter-PSSession lors de l’établissement d’une connexion. Cette option utilise le canal HTTPS plus sécurisé que le protocole HTTP.

Non. Certains cmdlet ont un paramètre ComputerName vous permettant d’obtenir des objets à partir de l’ordinateur distant.

Ces cmdlet n’utilisent pas de communication à distance PowerShell. Par conséquent, vous pouvez les utiliser sur n’importe quel ordinateur exécutant PowerShell, même s’il n’est pas configuré pour la communication à distance PowerShell ou s’il ne répond pas aux exigences de la communication à distance PowerShell.

Ces cmdlet contiennent les éléments suivants :

• Get-Hotfix
• Rename-Computer
• Restart-Computer
• Stop-Computer

Pour rechercher toutes les cmdlet avec un paramètre ComputerName, tapez :

Get-Help * -Parameter ComputerName
# or
Get-Command -ParameterName ComputerName

Pour déterminer si le paramètre ComputerName d’un cmdlet particulier nécessite la communication à distance PowerShell, consultez la description du paramètre. Pour afficher la description du paramètre, tapez :

Get-Help <cmdlet-name> -Parameter ComputerName

Par exemple :

Get-Help Get-Hotfix -Parameter ComputerName

Pour toutes les autres commandes, utilisez le cmdlet Invoke-Command.

Pour exécuter une commande sur un ordinateur distant, utilisez le cmdlet Invoke-Command.

Mettez votre commande entre accolades ({}) pour en faire un bloc de script. Utilisez le paramètre ScriptBlock de Invoke-Command pour spécifier la commande.

Vous pouvez vous servir du paramètre ComputerName de Invoke-Command pour spécifier un ordinateur distant. Vous pouvez également créer une connexion persistante à un ordinateur distant (une session), puis utiliser le paramètre Session de Invoke-Command afin d’exécuter la commande dans la session.

Par exemple, les commandes suivantes exécutent une commande à distance Get-Process.

Invoke-Command -ComputerName Server01, Server02 -ScriptBlock {Get-Process}

#  - OR -

Invoke-Command -Session $s -ScriptBlock {Get-Process}

Pour interrompre une commande distante, appuyez sur CTRL+C. La demande d’interruption est transmise à l’ordinateur distant, dans lequel elle met fin à la commande distante.

Pour plus d’informations sur les commandes distantes, consultez about_Remote et les rubriques Aide pour les cmdlet prenant en charge la communication à distance.

Vous pouvez vous servir du cmdlet Enter-PSSession pour commencer une session interactive avec un ordinateur distant.

À l’invite PowerShell, tapez :

Enter-PSSession <ComputerName>

L’invite de commandes change pour vous indiquer la connexion à l’ordinateur distant.

<ComputerName>\C:>

Les commandes que vous tapez s’exécutent à présent sur l’ordinateur distant, comme si vous les tapiez directement sur ce dernier.

Pour terminer la session interactive, tapez :

Exit-PSSession

Une session interactive est une session persistante utilisant le protocole WS-Management. Elle n’est pas identique à l’utilisation de Telnet, mais offre une expérience semblable.

Pour plus d’informations, consultez Enter-PSSession.

Oui. Vous pouvez exécuter des commandes distantes en spécifiant le nom de l’ordinateur distant, son nom NetBIOS ou son adresse IP. Vous pouvez également exécuter des commandes distantes en spécifiant une session PowerShell (PSSession) connectée à l’ordinateur distant.

Lorsque vous utilisez le paramètre ComputerName de Invoke-Command ou Enter-PSSession, PowerShell établit une connexion temporaire. PowerShell utilise cette connexion uniquement pour exécuter la commande active, puis la ferme. Il s’agit d’une méthode très efficace pour exécuter une unique commande ou plusieurs commandes sans liens entre elles, même sur de nombreux ordinateurs distants.

Lorsque vous utilisez un cmdlet New-PSSession pour créer une PSSession, PowerShell établit une connexion permanente pour la PSSession. Vous pouvez ensuite exécuter plusieurs commandes dans la session PSSession, y compris les commandes qui partagent des données.

En règle générale, vous créez une session PSSession pour exécuter une série de commandes associées partageant des données. Sinon, la connexion temporaire créée par le paramètre ComputerName est suffisante pour la plupart des commandes.

Pour des informations complémentaires, consultez about_PSSessions.

Oui. Le paramètre ComputerName du cmdlet Invoke-Command accepte plusieurs noms d’ordinateurs, tandis que le paramètre Session accepte plusieurs PSSession.

Lorsque vous exécutez une commande Invoke-Command, PowerShell exécute les commandes sur tous les ordinateurs spécifiés ou dans toutes les PSSession spécifiées.

PowerShell peut gérer des centaines de connexions distantes simultanées. Le nombre de commandes distantes (que vous pouvez envoyer) peut toutefois être limité par les ressources de votre ordinateur, mais également sa capacité à établir et à gérer plusieurs connexions réseau.

Pour plus d’informations, consultez l’exemple dans la rubrique Aide Invoke-Command.

Les profils PowerShell n’étant pas exécutés automatiquement dans les sessions à distance, les commandes ajoutées par le profil ne sont pas présentes dans la session. La variable automatique $profile n’est également pas remplie dans les sessions à distance.

Pour exécuter un profil dans une session, utilisez le cmdlet Invoke-Command.

Par exemple, la commande suivante exécute le profil CurrentUserCurrentHost à partir de l’ordinateur local dans la session dans $s.

Invoke-Command -Session $s -FilePath $profile

La commande suivante exécute le profil CurrentUserCurrentHost à partir de l’ordinateur distant dans la session dans $s. La variable $profile n’étant pas remplie, la commande utilise le chemin explicite vers le profil.

Invoke-Command -Session $s {
  . "$home\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1"
}

Après l’exécution de cette commande, les commandes ajoutées par le profil à la session sont disponibles dans $s.

Vous pouvez également utiliser un script de démarrage dans une configuration de session pour exécuter un profil dans chaque session à distance utilisant la configuration de session.

Pour plus d’informations sur les profils PowerShell, consultez about_Profiles. Pour plus d’informations sur les configurations de sessions, consultez Register-PSSessionConfiguration.

Pour vous aider à gérer les ressources sur votre ordinateur local, PowerShell contient une fonctionnalité de limitation par commande pour vous permettre de limiter le nombre de connexions distantes simultanées établies pour chaque commande.

La valeur par défaut est 32 connexions simultanées, mais vous pouvez utiliser le paramètre ThrottleLimit des cmdlet pour définir une limitation personnalisée pour des commandes particulières.

Lorsque vous utilisez la fonctionnalité de limitation, n’oubliez pas qu’elle est appliquée à chaque commande, pas à l’ensemble de la session ou à l’ordinateur. Si vous exécutez des commandes simultanément dans plusieurs sessions ou PSSessions, le nombre de connexions simultanées est la somme des connexions simultanées dans toutes les sessions.

Pour rechercher des cmdlet avec un paramètre ThrottleLimit, tapez :

Get-Help * -Parameter ThrottleLimit
-or-
Get-Command -ParameterName ThrottleLimit

Lorsque vous utilisez PowerShell localement, vous envoyez et recevez des objets .NET Framework « en direct ». Les objets « en direct » sont des objets associés à des programmes ou des composants réels du système. Lorsque vous appelez les méthodes ou modifiez les propriétés des objets dynamiques, les modifications affectent le programme ou le composant réel. Enfin, lorsque les propriétés d’un programme ou d’un composant changent, les propriétés de l’objet qui les représentent changent également.

Toutefois, la plupart des objets dynamiques ne pouvant pas être transmis sur le réseau, PowerShell « sérialise » la plupart des objets envoyés dans des commandes distantes. Autrement dit, il convertit chaque objet en une série d’éléments de données XML (Langage de contrainte en XML [CLiXML]) pour la transmission.

Lorsque PowerShell reçoit un objet sérialisé, il convertit le code XML en un type d’objet désérialisé. L’objet désérialisé est un enregistrement précis des propriétés du programme ou du composant à l’heure précédente, mais il n’est plus « en direct ». Autrement dit, il n’est plus directement associé au composant. Les méthodes sont enfin supprimées, car elles ne sont plus efficaces.

En règle générale, vous pouvez utiliser des objets désérialisés comme vous utiliseriez des objets dynamiques, mais vous devez connaître leurs limitations. En outre, les objets retournés par le cmdlet Invoke-Command ont des propriétés supplémentaires qui vous aident à déterminer l’origine de la commande.

Certains types d’objets, tels que les objets DirectoryInfo et les GUID, sont convertis en objets dynamiques à leur réception. Ces objets n’ont besoin d’aucune gestion ou mise en forme particulière.

Pour obtenir des informations sur l’interprétation et la mise en forme de la sortie distante, consultez about_Remote_Output.

Oui. Une tâche PowerShell en arrière-plan est une commande PowerShell s’exécutant de manière asynchrone sans interagir avec la session. Lorsque vous lancez un travail en arrière-plan, l’invite de commandes retourne immédiatement et vous pouvez continuer à travailler dans la session pendant l’exécution du travail, même s’il s’exécute pendant une période prolongée.

Vous pouvez démarrer un travail en arrière-plan, même si d’autres commandes s’exécutent, car les travaux en arrière-plan s’exécutent toujours de manière asynchrone dans une session temporaire.

Vous pouvez exécuter des travaux en arrière-plan sur un ordinateur local ou distant. Par défaut, un travail en arrière-plan s’exécute sur l’ordinateur local. Vous pouvez toutefois utiliser le paramètre AsJob du cmdlet Invoke-Command pour exécuter n’importe quelle commande distante comme travail en arrière-plan. Vous pouvez également utiliser Invoke-Command pour exécuter une commande Start-Job à distance.

Pour plus d’informations sur les travaux en arrière-plan dans PowerShell, consultez about_Jobs et about_Remote_Jobs.

Vous pouvez utiliser des commandes distantes PowerShell pour exécuter des programmes Windows sur des ordinateurs distants. Par exemple, vous pouvez exécuter Shutdown.exe ou Ipconfig.exe sur un ordinateur distant.

Vous ne pouvez toutefois pas utiliser des commandes PowerShell pour ouvrir l’interface utilisateur pour n’importe quel programme sur un ordinateur distant.

Lorsque vous démarrez un programme Windows sur un ordinateur distant, la commande n’est pas terminée et l’invite de commandes PowerShell ne retourne pas, tant que le programme n’est pas terminé ou jusqu’à ce que vous utilisiez le raccourci CTRL+C pour interrompre la commande. Par exemple, si vous exécutez le programme Ipconfig.exe sur un ordinateur distant, l’invite de commandes ne retourne pas jusqu’à ce que Ipconfig.exe soit terminé.

Si vous utilisez des commandes distantes pour démarrer un programme doté d’une interface utilisateur, le processus du programme démarre sans affichage de l’interface utilisateur. La commande PowerShell n’est pas terminée et l’invite de commandes ne retourne pas jusqu’à l’arrêt du processus du programme ou l’utilisation du raccourci CTRL+C qui interrompt la commande et arrête le processus.

Par exemple, si vous utilisez une commande PowerShell pour exécuter Notepad sur un ordinateur distant, le processus Notepad (bloc-notes) démarre sur l’ordinateur distant, mais l’interface utilisateur Notepad ne s’affiche pas. Pour interrompre la commande et restaurer l’invite de commandes, appuyez sur CTRL+C.

Oui. Chaque session à distance doit utiliser une des configurations de session sur l’ordinateur distant. Vous pouvez gérer des configurations de session sur votre ordinateur (mais également les autorisations pour ces configurations de session) pour déterminer les personnes autorisées à exécuter des commandes à distance sur votre ordinateur et les commandes qu’elles peuvent exécuter.

Une configuration de session configure l’environnement pour la session. Vous pouvez définir la configuration en utilisant un assembly qui implémente une nouvelle classe de configuration ou en utilisant un script qui s’exécute dans la session. La configuration peut déterminer les commandes disponibles dans la session. Cette configuration peut enfin inclure des paramètres qui protègent l’ordinateur, notamment les paramètres limitant la quantité de données pouvant être reçues par la session à distance dans un objet ou une commande unique. Vous pouvez également spécifier un descripteur de sécurité qui détermine les autorisations requises pour utiliser la configuration.

Le cmdlet Enable-PSRemoting crée les configurations de session par défaut sur votre ordinateur : Microsoft.PowerShell, Microsoft.PowerShell.Workflow et Microsoft.PowerShell32 (systèmes d’exploitation 64 bits uniquement). Enable-PSRemoting définit le descripteur de sécurité pour la configuration afin de n’autoriser que les membres du groupe Administrateurs sur votre ordinateur à les utiliser.

Vous pouvez utiliser les cmdlet de configuration de session pour modifier les configurations de session par défaut, créer de nouvelles configurations de session et modifier les descripteurs de sécurité de toutes les configurations de session.

À compter de Windows PowerShell 3.0, le cmdlet New-PSSessionConfigurationFile vous permet de créer des configurations personnalisées de session à l’aide d’un fichier texte. Le fichier contient des options pour définir le mode de langage, mais également spécifier les cmdlet et les modules disponibles dans les sessions utilisant la configuration de session.

Lorsque des utilisateurs se servent des cmdlet Invoke-Command, New-PSSession ou Enter-PSSession, ils peuvent utiliser le paramètre ConfigurationName pour indiquer la configuration de session utilisée pour la session. Ils peuvent également modifier la configuration par défaut utilisée par leurs sessions en changeant la valeur de la variable de préférence $PSSessionConfigurationName dans la session.

Pour plus d’informations sur les configurations de session, consultez l’Aide pour les cmdlet de configuration de session. Pour rechercher les cmdlet de configuration de session, tapez :

Get-Command *PSSessionConfiguration

Le scénario de communication à distance PowerShell le plus courant impliquant plusieurs ordinateurs est la configuration un-à-plusieurs. Dans cette dernière, un ordinateur local (l’ordinateur de l’Administrateur) exécute des commandes PowerShell sur de nombreux ordinateurs distants. Il s’agit du scénario « fan-out ».

Toutefois, dans certaines entreprises, il s’agit d’une configuration plusieurs-à-un dans laquelle de nombreux ordinateurs clients se connectent à un seul ordinateur distant exécutant PowerShell, tel qu’un serveur de fichiers ou un kiosque. Il s’agit de la configuration « fan-in ».

La communication à distance PowerShell prend en charge les configurations fan-out et fan-in.

Pour la configuration fan-out, PowerShell utilise le protocole WS-Management (Web Services for Management) et le service WinRM qui prend en charge l’implémentation Microsoft du protocole WS-Management. Lorsqu’un ordinateur local se connecte à un ordinateur distant, WS-Management établit une connexion et utilise un plug-in PowerShell afin de démarrer le processus hôte PowerShell (Wsmprovhost.exe) sur l’ordinateur distant. L’utilisateur peut spécifier un autre port, une configuration de session secondaire et d’autres fonctionnalités pour personnaliser la connexion à distance.

Pour prendre en charge la configuration « fan-in », PowerShell utilise IIS (Internet Information Services) pour héberger WS-Management, charger le plug-in PowerShell et démarrer PowerShell. Dans ce scénario, au lieu de démarrer chaque session PowerShell dans un processus distinct, toutes les sessions PowerShell s’exécutent au sein du même processus hôte.

L’hébergement IIS et la gestion à distance fan-in ne sont pas pris en charge dans Windows XP ou dans Windows Server 2003.

Dans une configuration fan-in, l’utilisateur peut spécifier un URI de connexion et un point de terminaison HTTP, notamment le transport, le nom de l’ordinateur, le port et le nom de l’application. IIS transfère toutes les requêtes avec un nom d’application spécifié à l’application. La valeur par défaut est WS-Management qui peut héberger PowerShell.

Vous pouvez également spécifier un mécanisme d’authentification, mais aussi interdire ou autoriser la redirection à partir de points de terminaison HTTP et HTTPS.

Oui. La communication à distance PowerShell est disponible même si l’ordinateur local ne se trouve pas dans un domaine. Vous pouvez utiliser les fonctionnalités de communication à distance pour vous connecter à des sessions et créer des sessions sur le même ordinateur. Les fonctionnalités se comportent de la même façon que lorsque vous vous connectez à un ordinateur distant.

Pour exécuter des commandes distantes sur un ordinateur dans un groupe de travail, modifiez les paramètres Windows suivants sur l’ordinateur.

Attention : ces paramètres affectent tous les utilisateurs du système et peuvent rendre le système plus vulnérable à une attaque malveillante. Soyez prudent lorsque vous apportez ces modifications.

• Windows Vista, Windows 7, Windows 8 :

  Créez l’entrée de Registre suivante, puis définissez sa valeur sur 1 : LocalAccountTokenFilterPolicy dans HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

  Vous pouvez utiliser la commande PowerShell suivante pour ajouter cette entrée :

  $parameters = @{
    Path='HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
    Name='LocalAccountTokenFilterPolicy'
    propertyType='DWord'
    Value=1
  }
  New-ItemProperty @parameters
  

• Windows Server 2003, Windows Server 2008, Windows Server 2012, Windows Server 2012 R2 :

  Aucune modification n’est nécessaire, car le paramètre par défaut de la stratégie « Accès réseau : partage et modèle de sécurité pour les comptes locaux » est « Classique ». Vérifiez le paramètre au cas où il a changé.

Oui. En règle générale, les commandes s’exécutent sans erreur, même si vous pouvez avoir à utiliser le paramètre Informations d’identification des cmdlet Invoke-Command, New-PSSession ou Enter-PSSession pour fournir les informations d’identification d’un membre du groupe Administrateurs sur l’ordinateur distant. Cela est parfois nécessaire, même lorsque l’utilisateur actuel est membre du groupe Administrateurs sur les ordinateurs locaux et distants.

Si l’ordinateur distant n’est toutefois pas dans un domaine approuvé par l’ordinateur local, l’ordinateur distant peut ne pas pouvoir authentifier les informations d’identification de l’utilisateur.

Pour activer l’authentification, utilisez la commande suivante pour ajouter l’ordinateur distant à la liste des hôtes approuvés pour l’ordinateur local dans WinRM. Tapez la commande dans l’invite PowerShell.

Set-Item WSMan:\localhost\Client\TrustedHosts -Value <Remote-computer-name>

Par exemple, pour ajouter l’ordinateur Server01 à la liste des hôtes approuvés sur l’ordinateur local, tapez la commande suivante dans l’invite PowerShell :

Set-Item WSMan:\localhost\Client\TrustedHosts -Value Server01

Oui. Pour plus d’informations, consultez Communication à distance PowerShell via SSH.

Voir aussi

about_Remote

about_Profiles

about_PSSessions

about_Remote_Jobs

about_Remote_Variables

Invoke-Command

New-PSSession