Share via

about_Remote_Troubleshooting

  • Artigo

Descrição breve

Descreve como solucionar problemas de operações remotas no PowerShell.

Descrição longa

Antes de usar a comunicação remota do PowerShell, consulte about_Remote e about_Remote_Requirements para obter diretrizes sobre configuração e uso básico.

Você deve ter direitos administrativos para exibir ou alterar as configurações do computador local na WSMan: unidade. Isso inclui alterações na configuração de sessão, hosts confiáveis, portas ou ouvintes.

Você deve executar o PowerShell com a opção Executar como administrador .

Como executar como administrador

Para erro:

ERRO: o acesso foi negado. Você precisa executar esse cmdlet de um processo elevado.

Para iniciar Windows PowerShell com a opção Executar como administrador, clique com o botão direito do mouse no ícone do PowerShell no Menu Iniciar e selecione Executar como administrador.

Como habilitar a comunicação remota

Para erros:

  • ERRO: ACESSO NEGADO
  • ERRO: a conexão com o host remoto foi recusada. Verifique se o serviço WS-Management está em execução no host remoto e configurado para escutar solicitações na porta correta e na URL HTTP.

Para receber comandos remotos, a comunicação remota do PowerShell deve ser habilitada no computador. Windows PowerShell comunicação remota é habilitada por padrão em Windows Server 2012 e versões mais recentes do Windows Server. Você pode executar Enable-PSRemoting para reabilitar a comunicação remota se ela tiver sido desabilitada. Para obter mais informações, consulte Enable-PSRemoting.

Como habilitar a comunicação remota em uma empresa

Para erros:

  • ERRO: ACESSO NEGADO
  • ERRO: a conexão com o host remoto foi recusada. Verifique se o serviço WS-Management está em execução no host remoto e configurado para escutar solicitações na porta correta e na URL HTTP.

Para permitir que um único computador receba comandos remotos do PowerShell e aceite conexões, use o Enable-PSRemoting cmdlet .

Para habilitar a comunicação remota para vários computadores em uma empresa, você pode usar as seguintes opções dimensionadas.

  • Habilite a política Permitir configuração automática de grupo de ouvintes para configurar ouvintes para comunicação remota.
  • Configure e habilite a política de grupo Firewall do Windows: Permitir Exceções de Porta Local .
  • Defina o tipo de inicialização do serviço WinRM como Automatic e inicie o serviço.

Como habilitar ouvintes usando uma política de grupo

Para erros:

  • ERRO: ACESSO NEGADO
  • ERRO: a conexão com o host remoto foi recusada. Verifique se o serviço WS-Management está em execução no host remoto e configurado para escutar solicitações na porta correta e na URL HTTP.

Habilite a política Permitir configuração automática de ouvintes para configurar os ouvintes para todos os computadores em um domínio.

A política é encontrada no seguinte caminho de Política de Grupo:

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

Habilite a política e especifique os filtros IPv4 e IPv6. Caracteres curinga (*) são permitidos.

Como habilitar a comunicação remota em redes públicas

Enable-PSRemoting retorna esse erro quando a rede local é pública e o parâmetro SkipNetworkProfileCheck não é usado no comando .

ERRO: não é possível marcar o status do firewall

Em versões de servidor do Windows, Enable-PSRemoting é bem-sucedido em todos os perfis de rede. Ele cria regras de firewall que permitem o acesso remoto a redes privadas e de domínio ("Página Inicial" e "Trabalho"). Para redes públicas, ele cria regras de firewall que permitem o acesso remoto da mesma sub-rede local.

Em versões de cliente do Windows, Enable-PSRemoting o é bem-sucedido em redes privadas e de domínio. Por padrão, ele falha em redes públicas, mas se você usar o parâmetro SkipNetworkProfileCheck , Enable-PSRemoting terá êxito e criará uma regra de firewall que permite o tráfego da mesma sub-rede local.

Observação

No Windows PowerShell 2.0, em computadores que executam versões de servidor do Windows, Enable-PSRemoting o cria regras de firewall que permitem o acesso remoto em redes privadas, de domínio e públicas. Em computadores que executam versões de cliente do Windows, Enable-PSRemoting o cria regras de firewall que permitem o acesso remoto somente em redes privadas e de domínio.

Para remover a restrição de sub-rede local em redes públicas e permitir o acesso remoto de qualquer local, execute o seguinte comando:

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

O Set-NetFirewallRule cmdlet é exportado pelo módulo NetSecurity .

Observação

O nome da regra de firewall pode ser diferente para versões diferentes do Windows. Use Get-NetFirewallRule para ver uma lista de regras. Antes de habilitar a regra de firewall, exiba as configurações de segurança na regra para verificar se a configuração é apropriada para seu ambiente.

Como habilitar uma exceção de firewall usando uma política de grupo

Para erros:

  • ERRO: ACESSO NEGADO
  • ERRO: a conexão com o host remoto foi recusada. Verifique se o serviço WS-Management está em execução no host remoto e configurado para escutar solicitações na porta correta e na URL HTTP.

Use a política Firewall do Windows: permitir exceções de porta local para habilitar uma exceção de firewall para em todos os computadores em um domínio.

A política está localizada no seguinte caminho de Política de Grupo:

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

Essa política permite que os membros do grupo Administradores criem uma exceção de firewall para o serviço WinRM (Gerenciamento Remoto do Windows).

Se a configuração da política estiver incorreta, você poderá receber o seguinte erro:

O cliente não pode se conectar ao destino especificado na solicitação. Verifique se o serviço no destino está em execução e se está aceitando solicitações.

Um erro de configuração na política resulta em um valor vazio para a propriedade ListeningOn . Use o comando a seguir para marcar o valor.

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           : {}

Como definir o tipo de inicialização do serviço WinRM

Para erro:

ERRO: ACESSO NEGADO

A comunicação remota do PowerShell depende do serviço WinRM (Gerenciamento Remoto do Windows). O serviço deve estar em execução para dar suporte a comandos remotos.

Em versões de servidor do Windows, o tipo de inicialização do serviço WinRM é Automatic. No entanto, nas versões de cliente do Windows, o serviço WinRM é desabilitado por padrão.

Use o exemplo a seguir para definir o tipo de inicialização do serviço WinRM como Automatic e iniciar o serviço. O parâmetro ComputerName aceita vários valores.

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

Como recriar as configurações de sessão padrão

Para erro:

ERRO: ACESSO NEGADO

Quando você usa Enable-PSRemoting, ele cria configurações de sessão padrão no computador local. Os usuários remotos usam essas configurações de sessão sempre que um comando remoto não inclui o parâmetro ConfigurationName .

Se as configurações padrão em um computador não forem registradas ou excluídas, use o Enable-PSRemoting cmdlet para recriá-las. Você pode usar esse cmdlet repetidamente. Ele não gerará erros se um recurso já estiver configurado.

Se você alterar as configurações de sessão padrão e quiser restaurar as configurações de sessão originais, poderá excluir e recriar as configurações.

Use o Unregister-PSSessionConfiguration cmdlet para excluir as configurações de sessão alteradas. Use Enable-PSRemoting para restaurar as configurações originais da sessão. Enable-PSRemoting não altera as configurações de sessão existentes.

Observação

Quando Enable-PSRemoting restaura a configuração de sessão padrão, ela não cria descritores de segurança explícitos para as configurações. Em vez disso, as configurações herdam o descritor de segurança do RootSDDL, que é seguro por padrão.

Para ver o descritor de segurança RootSDDL , digite:

Get-Item wsman:\localhost\Service\RootSDDL

Para alterar o RootSDDL, use o Set-Item cmdlet na WSMan: unidade. Para alterar o descritor de segurança de uma configuração de sessão, use o Set-PSSessionConfiguration cmdlet com os parâmetros SecurityDescriptorSDDL ou ShowSecurityDescriptorUI .

Para obter mais informações sobre a WSMan: unidade, consulte about_WSMan_Provider.

Como fornecer credenciais de administrador

Para erro:

ERRO: ACESSO NEGADO

Você deve ser um membro do grupo Administradores conectar-se aos pontos de extremidade de sessão remota padrão. Você pode usar o parâmetro Credential dos New-PSSessioncmdlets ou Enter-PSSessionInvoke-Command para se conectar a pontos de extremidade remotos usando credenciais alternativas.

O exemplo a seguir mostra como fornecer as credenciais para um usuário administrador.

Invoke-Command -ComputerName Server01 -Credential Domain01\Admin01

Para obter mais informações sobre o parâmetro Credential , consulte a ajuda para New-PSSession, Enter-PSSession ou Invoke-Command.

Como habilitar a comunicação remota para usuários não administrativos

Para erro:

ERRO: ACESSO NEGADO

Por padrão, somente os membros do grupo Administradores em um computador têm permissão para usar as configurações de sessão padrão. Portanto, somente membros do grupo Administradores podem se conectar ao computador remotamente.

Para permitir que outros usuários se conectem ao computador local, conceda ao usuário permissões Executar para as configurações de sessão padrão no computador local.

O exemplo a seguir abre uma folha de propriedades que permite alterar o descritor de segurança da configuração de sessão padrão Microsoft.PowerShell no computador local.

Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI

Para obter mais informações, consulte about_Session_Configurations.

Como habilitar a comunicação remota para administradores em outros domínios

Para erro:

ERRO: ACESSO NEGADO

Quando um usuário em outro domínio é membro do grupo Administradores no computador local, o usuário não pode se conectar ao computador local remotamente com privilégios de Administrador. Por padrão, as conexões remotas de outros domínios são executadas apenas com tokens de privilégio de usuário padrão.

Você pode usar a entrada do registro LocalAccountTokenFilterPolicy para alterar o comportamento padrão e permitir que usuários remotos que são membros do grupo Administradores sejam executados com privilégios de Administrador.

Cuidado

A entrada LocalAccountTokenFilterPolicy desabilita as restrições remotas do UAC (controle de conta de usuário) para todos os usuários de todos os computadores afetados. Considere cuidadosamente as implicações dessa configuração antes de alterar a política.

Use o comando a seguir para definir o valor do registro LocalAccountTokenFilterPolicy como 1.

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

Como usar um endereço IP em um comando remoto

Para erro:

ERRO: o cliente WinRM não pode processar a solicitação. Se o esquema de autenticação for diferente do Kerberos ou se o computador cliente não estiver ingressado em um domínio, o transporte HTTPS deverá ser usado ou o computador de destino deverá ser adicionado à configuração TrustedHosts.

O parâmetro ComputerName dos New-PSSessioncmdlets e Enter-PSSessionInvoke-Command aceita um endereço IP como um valor válido. No entanto, como a autenticação Kerberos não dá suporte a endereços IP. Quando você especifica um endereço IP, a autenticação NTLM é usada.

Para dar suporte à autenticação NTLM, você deve atender aos seguintes requisitos:

  • Configure o computador para transporte HTTPS ou adicione os endereços IP dos computadores remotos à lista TrustedHosts no computador local.
  • Use o parâmetro Credential em todos os comandos remotos. Isso é necessário mesmo quando você se conecta como o usuário atual.

Como se conectar remotamente de um computador baseado em grupo de trabalho

Para erro

ERRO: o cliente WinRM não pode processar a solicitação. Se o esquema de autenticação for diferente do Kerberos ou se o computador cliente não estiver ingressado em um domínio, o transporte HTTPS deverá ser usado ou o computador de destino deverá ser adicionado à configuração TrustedHosts.

Quando o computador local não estiver em um domínio, você deverá atender aos seguintes requisitos:

  • Configure o computador para transporte HTTPS ou adicione os endereços IP dos computadores remotos à lista TrustedHosts no computador local.
  • Verifique se uma senha está definida no computador baseado em grupo de trabalho. Se uma senha não estiver definida ou o valor da senha estiver vazio, você não poderá executar comandos remotos.
  • Use o parâmetro Credential em todos os comandos remotos. Isso é necessário mesmo quando você se conecta como o usuário atual.

Como adicionar um computador à lista de hosts confiáveis

O item TrustedHosts pode conter uma lista separada por vírgulas de nomes de computador, endereços IP e nomes de domínio totalmente qualificados. Caracteres curinga são permitidos.

Para exibir ou alterar a lista de hosts confiáveis, use a WSMan: unidade . O item TrustedHost está no WSMan:\localhost\Client nó . Somente os membros do grupo Administradores no computador têm permissão para alterar a lista de hosts confiáveis no computador.

Cuidado

O valor definido para o item TrustedHosts afeta todos os usuários do computador.

Para exibir a lista de hosts confiáveis, use o seguinte comando:

Get-Item wsman:\localhost\Client\TrustedHosts

O exemplo a seguir usa o caractere curinga (*) para adicionar todos os computadores à lista de hosts confiáveis.

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

Você também pode usar um caractere curinga (*) para adicionar todos os computadores em um domínio específico à lista de hosts confiáveis. Por exemplo, o comando a seguir adiciona todos os computadores no domínio Fabrikam.

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

O exemplo a seguir define a lista de hosts confiáveis como um único computador.

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

Para adicionar um nome de computador a uma lista existente de hosts confiáveis, primeiro salve o valor atual em uma variável. Em seguida, defina o valor como uma cadeia de caracteres que contém uma lista separada por vírgulas que inclui os valores atuais e novos.

O exemplo a seguir adiciona o Server01 a uma lista existente de hosts confiáveis.

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

Para adicionar os endereços IP de computadores específicos à lista de hosts confiáveis, use o seguinte formato de comando:

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

Por exemplo:

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

Para adicionar um computador à lista TrustedHosts de um computador remoto, use o Connect-WSMan para se conectar para WSMan: conduzir o computador remoto que usa Set-Item para adicionar o computador.

Para obter mais informações sobre, consulte a ajuda para Connect-WSMan.

Como configurar a comunicação remota em portas alternativas

Para erro:

ERRO: a conexão com o host remoto especificado foi recusada. Verifique se o serviço WS-Management está em execução no host remoto e configurado para escutar solicitações na porta correta e na URL HTTP.

A comunicação remota do PowerShell usa a porta 80 para transporte HTTP por padrão. A porta padrão é usada sempre que o usuário não especifica os parâmetros ConnectionURI ou Port em um comando remoto.

Use Set-Item o cmdlet para alterar o valor porta no nó folha do ouvinte.

Por exemplo, o comando a seguir altera a porta padrão para 8080.

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

Como configurar a comunicação remota com um servidor proxy

Para erro:

ERRO: o cliente não pode se conectar ao destino especificado na solicitação. Verifique se o serviço no destino está em execução e se está aceitando solicitações.

Como a comunicação remota do PowerShell usa o protocolo HTTP, ela é afetada pelas configurações de proxy HTTP. Em empresas que têm servidores proxy, os usuários não podem acessar um computador remoto do PowerShell diretamente.

Para resolve esse problema, use as opções de configuração de proxy no comando remoto.

  • Use os parâmetros ProxyAccessType, ProxyAuthentication e ProxyCredential do New-PSSessionOption cmdlet para criar uma variável contendo um objeto PSSessionOption com as configurações de proxy para sua empresa.
  • Use a variável que contém o objeto PSSessionOption com o parâmetro SessionOption de um New-PSSessioncomando , Enter-PSSessionou Invoke-Command .
$newPSSessionOptionSplat = @{
    ProxyAccessType = 'IEConfig'
    ProxyAuthentication = 'Negotiate'
    ProxyCredential = 'Domain01\User01'
}
$SessionOption = New-PSSessionOption @newPSSessionOptionSplat

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

Para obter mais informações sobre o New-PSSessionOption cmdlet, consulte New-PSSessionOption.

Para definir essas opções para todos os comandos remotos na sessão atual, defina a $PSSessionOption variável de preferência como o objeto PSSessionOption que você criou. Para obter mais informações, consulte about_Preference_Variables.

Para definir essas opções para todos os comandos remotos em todas as sessões do PowerShell no computador local, adicione a $PSSessionOption variável de preferência ao seu perfil do PowerShell. Para obter mais informações sobre perfis do PowerShell, consulte about_Profiles.

Como detectar uma sessão de 32 bits em um computador de 64 bits

Para erro:

ERRO: o termo <tool-name> não é reconhecido como o nome de um cmdlet, função, arquivo de script ou programa operável. Verifique a ortografia do nome ou se um caminho foi incluído, verifique se ele está correto e tente novamente.

Se o computador remoto estiver executando uma versão de 64 bits do Windows e o comando remoto usar uma configuração de sessão de 32 bits, como Microsoft.PowerShell32, o WinRM carregará um processo WOW64. O Windows redireciona automaticamente todas as referências para $env:Windir\System32 o $env:Windir\SysWOW64 diretório.

Como resultado, não é possível encontrar ferramentas em execução no System32 diretório que não têm equivalentes no SysWow64 diretório.

Para localizar a arquitetura do processador que está sendo usada na sessão, use o valor da variável de ambiente PROCESSOR_ARCHITECTURE .

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

x86

Para obter mais informações, consulte about_Session_Configurations.

Solução de problemas de política e preferência

Esta seção discute problemas de comunicação remota relacionados a políticas e preferências definidas nos computadores locais e remotos.

Como alterar a política de execução para Import-PSSession e Import-Module

Para erro:

ERRO: Import-Module: o <nome do arquivo> não pode ser carregado porque a execução de scripts está desabilitada neste sistema.

Os Import-PSSession cmdlets e Export-PSSession criam módulos que contêm arquivos de script não assinados e arquivos de formatação.

Para importar os módulos criados por esses cmdlets, a política de execução na sessão atual não pode ser Restricted ou AllSigned. Para obter mais informações, consulte about_Execution_Policies.

Para importar os módulos sem alterar a política de execução do computador local, use o parâmetro Scope de para definir uma política de Set-ExecutionPolicy execução menos restritiva para um único processo.

Por exemplo, o exemplo a seguir define a política de execução como RemoteSigned para o processo atual. A alteração afeta apenas o processo atual.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

Você também pode usar o parâmetro ExecutionPolicy de PowerShell.exe para iniciar uma única sessão com uma política de execução menos restritiva.

pwsh.exe -ExecutionPolicy RemoteSigned

Como definir e alterar cotas

Você pode usar cotas para proteger o computador local e o computador remoto contra uso excessivo de recursos, acidental e mal-intencionado. Quando as cotas entram em conflito com um comando, o PowerShell gera o erro a seguir.

ERRO: o total de dados recebidos do cliente remoto excedeu o máximo permitido.

O provedor WSMan tem as seguintes configurações de cota:

  • As configurações MaxEnvelopeSizeKB e MaxProviderRequests no WSMan:<ComputerName> nó e nas configurações MaxConcurrentOperations, MaxConcurrentOperationsPerUser e MaxConnections no WSMan:<ComputerName>\Service nó.
  • Você pode usar os parâmetros MaximumReceivedDataSizePerCommand e MaximumReceivedObjectSize do New-PSSessionOption cmdlet e a $PSSessionOption variável de preferência para proteger o computador local.
  • Para proteger o computador remoto, adicione restrições às configurações de sessão usando os parâmetros MaximumReceivedDataSizePerCommandMB e MaximumReceivedObjectSizeMB do Register-PSSessionConfiguration cmdlet.

Para resolve o erro, altere o comando remoto para cumprir a cota ou aumentar a cota para permitir que o comando seja concluído.

Por exemplo, o comando a seguir aumenta a cota de tamanho do objeto na configuração da sessão Microsoft.PowerShell no computador remoto de 10 MB (o valor padrão) para 11 MB.

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

Para obter mais informações sobre as cotas de WS-Management, consulte about_WSMan_Provider.

Como resolve erros de tempo limite

Você pode usar tempos limite para proteger o computador local e o computador remoto contra uso excessivo de recursos, acidental e mal-intencionado. Quando os tempos limite são definidos no computador local e remoto, o PowerShell usa as configurações de tempo limite mais curtas.

Quando um valor de tempo limite não permite que uma operação seja concluída, o PowerShell encerra a operação e gera o erro a seguir.

ERRO: o serviço WS-Management não pode concluir a operação dentro do tempo especificado em OperationTimeout.

O provedor WSMan tem as seguintes configurações de tempos limite.

  • Configuração maxTimeoutMs no WSMan:<ComputerName> nó e as configurações EnumerationTimeoutMs e MaxPacketRetrievalTimeSeconds no WSMan:<ComputerName>\Service nó.
  • Você pode proteger o computador local usando os parâmetros CancelTimeout, IdleTimeout, OpenTimeout e OperationTimeout do New-PSSessionOption cmdlet e da $PSSessionOption variável de preferência.
  • Você também pode proteger o computador remoto definindo valores de tempo limite programaticamente na configuração da sessão para a sessão.

Para resolve o erro, altere o comando para ser concluído dentro do intervalo de tempo limite ou aumente o intervalo de tempo limite para permitir que o comando seja concluído.

O exemplo a seguir cria uma opção de sessão com um valor OperationTimeout de 4 minutos (em MS) e, em seguida, usa a opção de sessão para criar uma sessão remota.

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

Para obter mais informações sobre os tempos limite de WS-Management, consulte about_WSMan_Provider.

Como interromper um comando que não responde

Alguns programas nativos, como programas com uma interface do usuário, aplicativos de console que solicitam entrada e aplicativos de console que usam a API de console do Win32, não funcionam corretamente no host remoto do PowerShell.

Ao usar esses programas, você poderá ver um comportamento inesperado, como nenhuma saída, saída parcial ou um comando remoto que não seja concluído.

Para encerrar um programa sem resposta, digite Ctrl+c. Use Get-Error no host local e na sessão remota para exibir quaisquer erros que possam ter sido relatados.

Como se recuperar de uma falha de operação

O erro a seguir é retornado quando uma operação é encerrada antes de ser concluída.

ERRO: a operação de E/S foi anulada devido a uma saída de thread ou a uma solicitação de aplicativo.

Normalmente, isso ocorre quando o serviço WinRM é interrompido ou reiniciado enquanto outras operações do WinRM estão em andamento.

Para resolve esse problema, verifique se o serviço WinRM está em execução e tente o comando novamente.

  1. Inicie o PowerShell com a opção Executar como administrador .

  2. Execute o comando a seguir:

    Start-Service WinRM

  3. Execute novamente o comando que gerou o erro.

Limitações do Linux e do macOS

A comunicação remota do PowerShell é Linux e macOS usando comunicação remota via SSH. Para obter mais informações, consulte Comunicação remota do PowerShell por SSH.

Confira também