Partager via

about_Remote_Troubleshooting

  • Article

Description courte

Décrit comment résoudre les problèmes d’opérations à distance dans PowerShell.

Description longue

Avant d’utiliser la communication à distance PowerShell, consultez about_Remote et about_Remote_Requirements pour obtenir des conseils sur la configuration et l’utilisation de base.

Vous devez disposer de droits d’administration pour afficher ou modifier les paramètres de l’ordinateur local dans le WSMan: lecteur. Cela inclut les modifications apportées à la configuration de session, aux hôtes approuvés, aux ports ou aux écouteurs.

Vous devez exécuter PowerShell avec l’option Exécuter en tant qu’administrateur .

Comment s’exécuter en tant qu’administrateur

Pour l’erreur :

ERREUR : L’accès est refusé. Vous devez exécuter cette applet de commande à partir d’un processus avec élévation de privilèges.

Pour démarrer Windows PowerShell avec l’option Exécuter en tant qu’administrateur , cliquez avec le bouton droit sur l’icône PowerShell dans le menu Démarrer, puis sélectionnez Exécuter en tant qu’administrateur.

Comment activer la communication à distance

Pour les erreurs :

  • ERREUR : L’ACCÈS EST REFUSÉ
  • ERREUR : La connexion à l’hôte distant a été refusée. Vérifiez que le service WS-Management s’exécute sur l’hôte distant et configuré pour écouter les requêtes sur le port et l’URL HTTP appropriés.

Pour recevoir des commandes distantes, la communication à distance PowerShell doit être activée sur l’ordinateur. La communication à distance Windows PowerShell est activée par défaut sur Windows Server 2012 et les versions plus récentes de Windows Server. Vous pouvez exécuter Enable-PSRemoting pour réactiver la communication à distance si elle a été désactivée. Pour plus d’informations, consultez Enable-PSRemoting.

Comment activer la communication à distance dans une entreprise

Pour les erreurs :

  • ERREUR : L’ACCÈS EST REFUSÉ
  • ERREUR : La connexion à l’hôte distant a été refusée. Vérifiez que le service WS-Management s’exécute sur l’hôte distant et configuré pour écouter les requêtes sur le port et l’URL HTTP appropriés.

Pour permettre à un seul ordinateur de recevoir des commandes PowerShell distantes et d’accepter des connexions, utilisez l’applet de Enable-PSRemoting commande.

Pour activer la communication à distance pour plusieurs ordinateurs d’une entreprise, vous pouvez utiliser les options mises à l’échelle suivantes.

  • Activez la configuration automatique de la stratégie de groupe d’écouteurs pour configurer les écouteurs pour la communication à distance.
  • Configurez et activez le Pare-feu Windows : Autoriser la stratégie de groupe Exceptions de port local.
  • Définissez le type de démarrage du service WinRM sur Automatic et démarrez le service.

Comment activer les écouteurs à l’aide d’une stratégie de groupe

Pour les erreurs :

  • ERREUR : L’ACCÈS EST REFUSÉ
  • ERREUR : La connexion à l’hôte distant a été refusée. Vérifiez que le service WS-Management s’exécute sur l’hôte distant et configuré pour écouter les requêtes sur le port et l’URL HTTP appropriés.

Activez la configuration automatique de la stratégie Autoriser l’écoute des écouteurs pour tous les ordinateurs d’un domaine.

La stratégie se trouve dans le chemin d’accès de stratégie de groupe suivant :

Computer Configuration\Administrative Templates\Windows Components
    \Windows Remote Management (WinRM)\WinRM service

Activez la stratégie et spécifiez les filtres IPv4 et IPv6. Les caractères génériques (*) sont autorisés.

Comment activer la communication à distance sur les réseaux publics

Enable-PSRemoting retourne cette erreur lorsque le réseau local est public et que le paramètre SkipNetworkProfileCheck n’est pas utilisé dans la commande.

ERREUR : Impossible de vérifier l’état du pare-feu

Sur les versions serveur de Windows, Enable-PSRemoting réussit sur tous les profils réseau. Il crée des règles de pare-feu qui autorisent l’accès à distance aux réseaux privés et de domaine (« Accueil » et « Travail »). Pour les réseaux publics, il crée des règles de pare-feu qui autorisent l’accès à distance à partir du même sous-réseau local.

Sur les versions clientes de Windows, Enable-PSRemoting réussit sur les réseaux privés et de domaine. Par défaut, elle échoue sur les réseaux publics, mais si vous utilisez le paramètre SkipNetworkProfileCheck , Enable-PSRemoting réussit et crée une règle de pare-feu qui autorise le trafic à partir du même sous-réseau local.

Remarque

Dans Windows PowerShell 2.0, sur les ordinateurs exécutant des versions de serveur de Windows, Enable-PSRemoting crée des règles de pare-feu qui autorisent l’accès à distance sur des réseaux privés, de domaine et publics. Sur les ordinateurs exécutant des versions clientes de Windows, Enable-PSRemoting crée des règles de pare-feu qui autorisent l’accès à distance uniquement sur les réseaux privés et de domaine.

Pour supprimer la restriction de sous-réseau local sur les réseaux publics et autoriser l’accès à distance à partir de n’importe quel emplacement, exécutez la commande suivante :

Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any

L’applet Set-NetFirewallRule de commande est exportée par le module NetSecurity .

Remarque

Le nom de la règle de pare-feu peut être différent pour différentes versions de Windows. Permet Get-NetFirewallRule d’afficher la liste des règles. Avant d’activer la règle de pare-feu, affichez les paramètres de sécurité de la règle pour vérifier que la configuration est appropriée pour votre environnement.

Comment activer une exception de pare-feu à l’aide d’une stratégie de groupe

Pour les erreurs :

  • ERREUR : L’ACCÈS EST REFUSÉ
  • ERREUR : La connexion à l’hôte distant a été refusée. Vérifiez que le service WS-Management s’exécute sur l’hôte distant et configuré pour écouter les requêtes sur le port et l’URL HTTP appropriés.

Utilisez le Pare-feu Windows : autorisez la stratégie d’exceptions de port local pour activer une exception de pare-feu pour tous les ordinateurs d’un domaine.

La stratégie se trouve dans le chemin d’accès de stratégie de groupe suivant :

Computer Configuration\Administrative Templates\Network
    \Network Connections\Windows Firewall\Domain Profile

Cette stratégie permet aux membres du groupe Administrateurs de créer une exception de pare-feu pour le service Windows Remote Management (WinRM).

Si la configuration de la stratégie est incorrecte, vous pouvez recevoir l’erreur suivante :

Le client ne peut pas se connecter à la destination spécifiée dans la requête. Vérifiez que le service sur la destination est en cours d’exécution et accepte les demandes.

Une erreur de configuration dans la stratégie entraîne une valeur vide pour la propriété ListeningOn . Utilisez la commande suivante pour vérifier la valeur.

Get-WSManInstance winrm/config/listener -Enumerate

cfg                   : http://schemas.microsoft.com/wbem/wsman/1/config/listener
xsi                   : http://www.w3.org/2001/XMLSchema-instance
Source                : GPO
lang                  : en-US
Address               : *
Transport             : HTTP
Port                  : 5985
Hostname              :
Enabled               : true
URLPrefix             : wsman
CertificateThumbprint :
ListeningOn           : {}

Comment définir le type de démarrage du service WinRM

Pour l’erreur :

ERREUR : L’ACCÈS EST REFUSÉ

La communication à distance PowerShell dépend du service Windows Remote Management (WinRM). Le service doit être en cours d’exécution pour prendre en charge les commandes à distance.

Sur les versions serveur de Windows, le type de démarrage du service WinRM est Automatic. Toutefois, sur les versions clientes de Windows, le service WinRM est désactivé par défaut.

Utilisez l’exemple suivant pour définir le type de démarrage du service WinRM et Automatic démarrer le service. Le paramètre ComputerName accepte plusieurs valeurs.

$invokeCimMethodSplat = @{
    ComputerName = 'Server01', 'Server02'
    Query = 'Select * From Win32_Service Where Name = "WinRM"'
    MethodName = 'ChangeStartMode'
    Arguments = @{StartMode  = 'Automatic'}
}
Invoke-CimMethod @invokeCimMethodSplat

Comment recréer les configurations de session par défaut

Pour l’erreur :

ERREUR : L’ACCÈS EST REFUSÉ

Lorsque vous utilisez Enable-PSRemoting, il crée des configurations de session par défaut sur l’ordinateur local. Les utilisateurs distants utilisent ces configurations de session chaque fois qu’une commande distante n’inclut pas le paramètre ConfigurationName .

Si les configurations par défaut sur un ordinateur ne sont pas inscrites ou supprimées, utilisez l’applet Enable-PSRemoting de commande pour les recréer. Vous pouvez utiliser cette applet de commande à plusieurs reprises. Elle ne génère pas d’erreurs si une fonctionnalité est déjà configurée.

Si vous modifiez les configurations de session par défaut et que vous souhaitez restaurer les configurations de session d’origine, vous pouvez supprimer et recréer les configurations.

Utilisez l’applet de Unregister-PSSessionConfiguration commande pour supprimer les configurations de session modifiées. Permet Enable-PSRemoting de restaurer les configurations de session d’origine. Enable-PSRemoting ne modifie pas les configurations de session existantes.

Remarque

Lorsque Enable-PSRemoting vous restaurez la configuration de session par défaut, elle ne crée pas de descripteurs de sécurité explicites pour les configurations. Au lieu de cela, les configurations héritent du descripteur de sécurité de RootSDDL, qui est sécurisé par défaut.

Pour afficher le descripteur de sécurité RootSDDL , tapez :

Get-Item wsman:\localhost\Service\RootSDDL

Pour modifier rootSDDL, utilisez l’applet Set-Item de commande dans le WSMan: lecteur. Pour modifier le descripteur de sécurité d’une configuration de session, utilisez l’applet Set-PSSessionConfiguration de commande avec les paramètres SecurityDescriptorSDDL ou ShowSecurityDescriptorUI .

Pour plus d’informations sur le WSMan: lecteur, consultez about_WSMan_Provider.

Comment fournir des informations d’identification d’administrateur

Pour l’erreur :

ERREUR : L’ACCÈS EST REFUSÉ

Vous devez être membre du groupe Administrateurs pour vous connecter aux points de terminaison de session à distance par défaut. Vous pouvez utiliser le paramètre Credential du ou Enter-PSSession Invoke-Command des applets de New-PSSessioncommande pour vous connecter à des points de terminaison distants à l’aide d’autres informations d’identification.

L’exemple suivant montre comment fournir les informations d’identification d’un utilisateur administrateur.

Invoke-Command -ComputerName Server01 -Credential Domain01\Admin01

Pour plus d’informations sur le paramètre Credential, consultez l’aide de New-PSSession, Enter-PSSession ou Invoke-Command.

Comment activer la communication à distance pour les utilisateurs non administratifs

Pour l’erreur :

ERREUR : L’ACCÈS EST REFUSÉ

Par défaut, seuls les membres du groupe Administrateurs sur un ordinateur ont l’autorisation d’utiliser les configurations de session par défaut. Par conséquent, seuls les membres du groupe Administrateurs peuvent se connecter à distance à l’ordinateur.

Pour permettre à d’autres utilisateurs de se connecter à l’ordinateur local, accordez à l’utilisateur des autorisations d’exécution aux configurations de session par défaut sur l’ordinateur local.

L’exemple suivant ouvre une feuille de propriétés qui vous permet de modifier le descripteur de sécurité de la configuration de session par défaut Microsoft.PowerShell sur l’ordinateur local.

Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI

Pour plus d’informations, consultez about_Session_Configurations.

Comment activer la communication à distance pour les administrateurs dans d’autres domaines

Pour l’erreur :

ERREUR : L’ACCÈS EST REFUSÉ

Lorsqu’un utilisateur d’un autre domaine est membre du groupe Administrateurs sur l’ordinateur local, l’utilisateur ne peut pas se connecter à distance à l’ordinateur local avec des privilèges d’administrateur. Par défaut, les connexions distantes d’autres domaines s’exécutent uniquement avec des jetons de privilège utilisateur standard.

Vous pouvez utiliser l’entrée de Registre LocalAccountTokenFilterPolicy pour modifier le comportement par défaut et autoriser les utilisateurs distants membres du groupe Administrateurs à s’exécuter avec des privilèges d’administrateur.

Attention

L’entrée LocalAccountTokenFilterPolicy désactive les restrictions distantes de contrôle de compte d’utilisateur (UAC) pour tous les utilisateurs de tous les ordinateurs affectés. Tenez compte des implications de ce paramètre soigneusement avant de modifier la stratégie.

Utilisez la commande suivante pour définir la valeur de Registre LocalAccountTokenFilterPolicy sur 1.

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

Comment utiliser une adresse IP dans une commande distante

Pour l’erreur :

ERREUR : le client WinRM ne peut pas traiter la requête. Si le schéma d'authentification est différent de Kerberos, ou si l'ordinateur client n'est pas joint à un domaine, le transport HTTPS doit être utilisé ou la machine de destination doit être ajoutée au paramètre de configuration TrustedHosts.

Le paramètre ComputerName des applets de Invoke-Command New-PSSessionEnter-PSSession commande accepte une adresse IP comme valeur valide. Toutefois, étant donné que l’authentification Kerberos ne prend pas en charge les adresses IP. Lorsque vous spécifiez une adresse IP, l’authentification NTLM est utilisée.

Pour prendre en charge l’authentification NTLM, vous devez répondre aux exigences suivantes :

  • Configurez l’ordinateur pour le transport HTTPS ou ajoutez les adresses IP des ordinateurs distants à la liste TrustedHosts sur l’ordinateur local.
  • Utilisez le paramètre Credential dans toutes les commandes distantes. Cela est nécessaire même lorsque vous vous connectez en tant qu’utilisateur actuel.

Comment se connecter à distance à partir d’un ordinateur basé sur un groupe de travail

Pour une erreur

ERREUR : le client WinRM ne peut pas traiter la requête. Si le schéma d'authentification est différent de Kerberos, ou si l'ordinateur client n'est pas joint à un domaine, le transport HTTPS doit être utilisé ou la machine de destination doit être ajoutée au paramètre de configuration TrustedHosts.

Lorsque l’ordinateur local n’est pas dans un domaine, vous devez répondre aux exigences suivantes :

  • Configurez l’ordinateur pour le transport HTTPS ou ajoutez les adresses IP des ordinateurs distants à la liste TrustedHosts sur l’ordinateur local.
  • Vérifiez qu’un mot de passe est défini sur l’ordinateur basé sur un groupe de travail. Si un mot de passe n’est pas défini ou si la valeur du mot de passe est vide, vous ne pouvez pas exécuter de commandes distantes.
  • Utilisez le paramètre Credential dans toutes les commandes distantes. Cela est nécessaire même lorsque vous vous connectez en tant qu’utilisateur actuel.

Comment ajouter un ordinateur à la liste des hôtes approuvés

L’élément TrustedHosts peut contenir une liste séparée par des virgules de noms d’ordinateurs, d’adresses IP et de noms de domaine complets. Les caractères génériques sont autorisés.

Pour afficher ou modifier la liste d’hôtes approuvée, utilisez le WSMan: lecteur. L’élément TrustedHost se trouve dans le WSMan:\localhost\Client nœud. Seuls les membres du groupe Administrateurs sur l’ordinateur ont l’autorisation de modifier la liste des hôtes approuvés sur l’ordinateur.

Attention

La valeur que vous définissez pour l’élément TrustedHosts affecte tous les utilisateurs de l’ordinateur.

Pour afficher la liste des hôtes approuvés, utilisez la commande suivante :

Get-Item wsman:\localhost\Client\TrustedHosts

L’exemple suivant utilise le caractère générique (*) pour ajouter tous les ordinateurs à la liste des hôtes approuvés.

Set-Item wsman:localhost\client\trustedhosts -Value *

Vous pouvez également utiliser un caractère générique (*) pour ajouter tous les ordinateurs d’un domaine particulier à la liste des hôtes approuvés. Par exemple, la commande suivante ajoute tous les ordinateurs du domaine Fabrikam.

Set-Item wsman:localhost\client\trustedhosts *.fabrikam.com

L’exemple suivant définit la liste des hôtes approuvés sur un seul ordinateur.

$server = 'Server01.Domain01.Fabrikam.com'
Set-Item wsman:\localhost\Client\TrustedHosts -Value $server

Pour ajouter un nom d’ordinateur à une liste existante d’hôtes approuvés, enregistrez d’abord la valeur actuelle dans une variable. Définissez ensuite la valeur sur une chaîne contenant une liste séparée par des virgules qui inclut les valeurs actuelles et nouvelles.

L’exemple suivant ajoute Server01 à une liste existante d’hôtes approuvés.

$newServer = 'Server01.Domain01.Fabrikam.com'
$curValue = (Get-Item wsman:\localhost\Client\TrustedHosts).Value
Set-Item wsman:\localhost\Client\TrustedHosts -Value "$curValue, $newServer"

Pour ajouter les adresses IP d’ordinateurs particuliers à la liste des hôtes approuvés, utilisez le format de commande suivant :

Set-Item wsman:\localhost\Client\TrustedHosts -Value <IP Address>

Par exemple :

Set-Item wsman:\localhost\Client\TrustedHosts -Value 172.16.0.0

Pour ajouter un ordinateur à la liste TrustedHosts d’un ordinateur distant, utilisez celui-ci Connect-WSMan pour vous connecter pour WSMan: conduire l’ordinateur distant à l’aide de l’utilisation Set-Item pour ajouter l’ordinateur.

Pour plus d’informations, consultez l’aide de Connect-WSMan.

Comment configurer la communication à distance sur d’autres ports

Pour l’erreur :

ERREUR : La connexion à l’hôte distant spécifié a été refusée. Vérifiez que le service WS-Management s’exécute sur l’hôte distant et configuré pour écouter les requêtes sur le port et l’URL HTTP appropriés.

La communication à distance PowerShell utilise le port 80 pour le transport HTTP par défaut. Le port par défaut est utilisé chaque fois que l’utilisateur ne spécifie pas les paramètres ConnectionURI ou Port dans une commande distante.

Utilisez Set-Item l’applet de commande pour modifier la valeur de port dans le nœud feuille de l’écouteur.

Par exemple, la commande suivante modifie le port par défaut sur 8080.

Set-Item wsman:\localhost\listener\listener*\port -Value 8080

Comment configurer la communication à distance avec un serveur proxy

Pour l’erreur :

ERREUR : le client ne peut pas se connecter à la destination spécifiée dans la requête. Vérifiez que le service sur la destination est en cours d’exécution et accepte les demandes.

Étant donné que la communication à distance PowerShell utilise le protocole HTTP, elle est affectée par les paramètres de proxy HTTP. Dans les entreprises disposant de serveurs proxy, les utilisateurs ne peuvent pas accéder directement à un ordinateur distant PowerShell.

Pour résoudre ce problème, utilisez les options de paramètre de proxy dans votre commande distante.

  • Utilisez les paramètres ProxyAccessType, ProxyAuthentication et ProxyCredential de l’applet New-PSSessionOption de commande pour créer une variable contenant un objet PSSessionOption avec les paramètres proxy de votre entreprise.
  • Utilisez la variable contenant l’objet PSSessionOption wit le paramètre SessionOption d’une commande Enter-PSSessionou Invoke-Command d’une New-PSSessioncommande.
$newPSSessionOptionSplat = @{
    ProxyAccessType = 'IEConfig'
    ProxyAuthentication = 'Negotiate'
    ProxyCredential = 'Domain01\User01'
}
$SessionOption = New-PSSessionOption @newPSSessionOptionSplat

$newPSSessionSplat = @{
    ConnectionUri = 'https://www.fabrikam.com'
    SessionOption = $SessionOption
}
New-PSSession @newPSSessionSplat

Pour plus d’informations sur l’applet New-PSSessionOption de commande, consultez New-PSSessionOption.

Pour définir ces options pour toutes les commandes distantes de la session active, définissez la variable de préférence sur l’objet $PSSessionOption PSSessionOption que vous avez créé. Pour plus d’informations, consultez about_Preference_Variables.

Pour définir ces options pour toutes les commandes distantes de toutes les sessions PowerShell sur l’ordinateur local, ajoutez la $PSSessionOption variable de préférence à votre profil PowerShell. Pour plus d’informations sur les profils PowerShell, consultez about_Profiles.

Comment détecter une session 32 bits sur un ordinateur 64 bits

Pour l’erreur :

ERREUR : le nom de> l’outil n’est <pas reconnu comme nom d’une applet de commande, d’une fonction, d’un fichier de script ou d’un programme opérable. Vérifiez l’orthographe du nom ou, si un chemin d’accès a été inclus, vérifiez que le chemin d’accès est correct et réessayez.

Si l’ordinateur distant exécute une version 64 bits de Windows et que la commande distante utilise une configuration de session 32 bits, telle que Microsoft.PowerShell32, WinRM charge un processus WOW64. Windows redirige automatiquement toutes les références vers $env:Windir\System32 le $env:Windir\SysWOW64 répertoire.

Par conséquent, l’exécution d’outils dans le System32 répertoire qui n’ont pas d’équivalents dans le SysWow64 répertoire est introuvable.

Pour rechercher l’architecture du processeur utilisée dans la session, utilisez la valeur de la variable d’environnement PROCESSOR_ARCHITECTURE.

$s = New-PSSession -ComputerName Server01 -ConfigurationName CustomShell
Invoke-Command -Session $s {$env:PROCESSOR_ARCHITECTURE}

x86

Pour plus d’informations, consultez about_Session_Configurations.

Résolution des problèmes de stratégie et de préférence

Cette section décrit les problèmes de communication à distance liés aux stratégies et préférences définies sur les ordinateurs locaux et distants.

Comment modifier la stratégie d’exécution pour Import-PSSession et Import-Module

Pour l’erreur :

ERREUR : Import-Module : Le nom de fichier <> ne peut pas être chargé, car l’exécution de scripts est désactivée sur ce système.

Les Import-PSSession applets de Export-PSSession commande et les applets de commande créent des modules qui contiennent des fichiers de script non signés et des fichiers de mise en forme.

Pour importer les modules créés par ces applets de commande, la stratégie d’exécution dans la session active ne peut pas être Restricted ou AllSigned. Pour plus d'informations, voir about_Execution_Policies.

Pour importer les modules sans modifier la stratégie d’exécution de l’ordinateur local, utilisez le paramètre Scope de Set-ExecutionPolicy façon à définir une stratégie d’exécution moins restrictive pour un seul processus.

Par exemple, l’exemple suivant montre comment définir la stratégie RemoteSigned d’exécution pour le processus actuel. La modification affecte uniquement le processus actuel.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

Vous pouvez également utiliser le paramètre ExecutionPolicy pour PowerShell.exe démarrer une seule session avec une stratégie d’exécution moins restrictive.

pwsh.exe -ExecutionPolicy RemoteSigned

Comment définir et modifier des quotas

Vous pouvez utiliser des quotas pour protéger l’ordinateur local et l’ordinateur distant contre une utilisation excessive des ressources, à la fois accidentelle et malveillante. Lorsque les quotas sont en conflit avec une commande, PowerShell génère l’erreur suivante.

ERREUR : le nombre total de données reçues du client distant a dépassé le maximum autorisé.

Le fournisseur WSMan a les paramètres de quota suivants :

  • Les paramètres MaxEnvelopeSizeKB et MaxProviderRequests dans le WSMan:<ComputerName> nœud et les paramètres MaxConcurrentOperations, MaxConcurrentOperationsPerUser et MaxConnections dans le WSMan:<ComputerName>\Service nœud.
  • Vous pouvez utiliser les paramètres MaximumReceivedDataSizePerCommand et MaximumReceivedObjectSize de l’applet New-PSSessionOption de commande et la $PSSessionOption variable de préférence pour protéger l’ordinateur local.
  • Pour protéger l’ordinateur distant, ajoutez des restrictions aux configurations de session à l’aide des paramètres MaximumReceivedDataSizePerCommandMB et MaximumReceivedObjectSizeMB de l’applet Register-PSSessionConfiguration de commande.

Pour résoudre l’erreur, modifiez la commande distante pour vous conformer au quota ou augmentez le quota pour permettre à la commande de se terminer.

Par exemple, la commande suivante augmente le quota de taille d’objet dans la configuration de session Microsoft.PowerShell sur l’ordinateur distant de 10 Mo (valeur par défaut) à 11 Mo.

$setPSSessionConfigurationSplat = @{
    Name = 'Microsoft.PowerShell'
    MaximumReceivedObjectSizeMB = 11
    Force = $true
}
Set-PSSessionConfiguration @setPSSessionConfigurationSplat

Pour plus d’informations sur les quotas WS-Management, consultez about_WSMan_Provider.

Comment résoudre les erreurs de délai d’expiration

Vous pouvez utiliser des délais d’expiration pour protéger l’ordinateur local et l’ordinateur distant contre une utilisation excessive des ressources, accidentelle et malveillante. Lorsque les délais d’expiration sont définis sur l’ordinateur local et distant, PowerShell utilise les paramètres de délai d’attente les plus courts.

Lorsqu’une valeur de délai d’expiration n’autorise pas l’exécution d’une opération, PowerShell met fin à l’opération et génère l’erreur suivante.

ERREUR : Le service WS-Management ne peut pas terminer l’opération dans le délai spécifié dans OperationTimeout.

Le fournisseur WSMan a les paramètres de délai d’expiration suivants.

  • Paramètre MaxTimeoutMs dans le WSMan:<ComputerName> nœud et les paramètres EnumerationTimeoutMs et MaxPacketRetrievalTimeSeconds dans le WSMan:<ComputerName>\Service nœud.
  • Vous pouvez protéger l’ordinateur local à l’aide des paramètres CancelTimeout, IdleTimeout, OpenTimeout et OperationTimeout de l’applet de commande et de la New-PSSessionOption $PSSessionOption variable de préférence.
  • Vous pouvez également protéger l’ordinateur distant en définissant des valeurs de délai d’expiration par programmation dans la configuration de session de la session.

Pour résoudre l’erreur, modifiez la commande pour qu’elle se termine dans l’intervalle de délai d’expiration ou augmentez l’intervalle de délai d’expiration pour permettre à la commande de se terminer.

L’exemple suivant crée une option de session avec une valeur OperationTimeout de 4 minutes (en MS), puis utilise l’option de session pour créer une session distante.

$pso = New-PSSessionOption -OperationTimeout 240000
New-PSSession -ComputerName Server01 -SessionOption $pso

Pour plus d’informations sur les délais d’expiration de gestion WS, consultez about_WSMan_Provider.

Comment interrompre une commande qui ne répond pas

Certains programmes natifs, tels que les programmes avec une interface utilisateur, les applications console qui demandent une entrée et les applications console qui utilisent l’API de console Win32, ne fonctionnent pas correctement dans l’hôte distant PowerShell.

Lorsque vous utilisez ces programmes, vous pouvez voir un comportement inattendu, tel qu’aucune sortie, sortie partielle ou commande distante qui n’est pas terminée.

Pour mettre fin à un programme sans réponse, tapez Ctrl+c. Utiliser Get-Error dans l’hôte local et la session distante pour afficher les erreurs qui ont pu être signalées.

Comment récupérer à partir d’un échec d’opération

L’erreur suivante est retournée lorsqu’une opération est terminée avant sa fin.

ERREUR : L’opération d’E/S a été abandonnée en raison d’une sortie de thread ou d’une demande d’application.

En règle générale, cela se produit lorsque le service WinRM arrête ou redémarre alors que d’autres opérations WinRM sont en cours.

Pour résoudre ce problème, vérifiez que le service WinRM est en cours d’exécution et réessayez la commande.

  1. Démarrez PowerShell avec l’option Exécuter en tant qu’administrateur.

  2. Exécutez la commande suivante :

    Start-Service WinRM

  3. Réexécutez la commande qui a généré l’erreur.

Limitations linux et macOS

La communication à distance PowerShell est Linux et macOS à l’aide de la communication à distance via SSH. Pour plus d’informations, consultez La communication à distance PowerShell sur SSH.

Voir aussi