about_Remote_Troubleshooting
Breve descrição
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 orientação 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 da sessão, hosts confiáveis, portas ou ouvintes.
Você deve executar o PowerShell com a opção Executar como administrador .
Como executar como administrador
Por erro:
ERRO: Acesso negado. Você precisa executar esse cmdlet a partir de um processo elevado.
Para iniciar o 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 ativar a comunicação remota
Para erros:
- ERRO: O 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 estar habilitada no computador. A comunicação remota do Windows PowerShell é habilitada por padrão no Windows Server 2012 e em versões mais recentes do Windows Server. Você pode executar Enable-PSRemoting
para reativar a comunicação remota se ela estiver desativada. Para obter mais informações, consulte Enable-PSRemoting.
Como habilitar a comunicação remota em uma empresa
Para erros:
- ERRO: O 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 de grupo Permitir configuração automática 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 para
Automatic
e inicie o serviço.
Como habilitar ouvintes usando uma política de grupo
Para erros:
- ERRO: O 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 Diretiva 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. Curingas (*
) 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 verificar o status do firewall
Nas versões de servidor do Windows, Enable-PSRemoting
é bem-sucedido em todos os perfis de rede. Cria regras de firewall que permitem o acesso remoto a redes privadas e de domínio ("Casa" e "Trabalho"). Para redes públicas, cria regras de firewall que permitem o acesso remoto a partir da mesma sub-rede local.
Em versões cliente do Windows, Enable-PSRemoting
é 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.
Nota
No Windows PowerShell 2.0, em computadores que executam versões de servidor do Windows, Enable-PSRemoting
cria regras de firewall que permitem o acesso remoto em redes privadas, públicas e de domínio. Em computadores que executam versões cliente do Windows, Enable-PSRemoting
cria regras de firewall que permitem acesso remoto apenas 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 .
Nota
O nome da regra de firewall pode ser diferente para diferentes versões 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 diretiva de grupo
Para erros:
- ERRO: O 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 diretiva Firewall do Windows: Permitir exceções de porta local para habilitar uma exceção de firewall em todos os computadores de um domínio.
A diretiva está localizada no seguinte caminho de Diretiva de Grupo:
Computer Configuration\Administrative Templates\Network
\Network Connections\Windows Firewall\Domain Profile
Esta política permite que os membros do grupo Administradores criem uma exceção de firewall para o serviço de Gerenciamento Remoto do Windows (WinRM).
Se a configuração da política estiver incorreta, 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 está aceitando solicitações.
Um erro de configuração na política resulta em um valor vazio para a propriedade ListeningOn . Use o seguinte comando para verificar 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
Por erro:
ERRO: O ACESSO É NEGADO
A comunicação remota do PowerShell depende do serviço de Gerenciamento Remoto do Windows (WinRM). O serviço deve estar em execução para oferecer suporte a comandos remotos.
Em versões de servidor do Windows, o tipo de inicialização do serviço WinRM é Automatic
.
No entanto, em versões de cliente do Windows, o serviço WinRM é desativado por padrão.
Use o exemplo a seguir para definir o tipo de inicialização do serviço WinRM e Automatic
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
Por erro:
ERRO: O ACESSO É NEGADO
Quando você usa Enable-PSRemoting
o , 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 gera 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 de sessão originais. Enable-PSRemoting
não altera as configurações de sessão existentes.
Nota
Quando Enable-PSRemoting
restaura a configuração de sessão padrão, ele 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
WSMan:
cmdlet na 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
Por erro:
ERRO: O ACESSO É NEGADO
Você deve ser membro do grupo Administradores para se conectar aos pontos de extremidade de sessão remota padrão. Você pode usar o parâmetro Credential do , Enter-PSSession
ou Invoke-Command
cmdlets para se conectar a pontos de New-PSSession
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
Por erro:
ERRO: O ACESSO É NEGADO
Por padrão, apenas os membros do grupo Administradores em um computador têm permissão para usar as configurações de sessão padrão. Portanto, somente os 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
Por erro:
ERRO: O 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.
Atenção
A entrada LocalAccountTokenFilterPolicy desativa as restrições remotas de controle de conta de usuário (UAC) 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
Por 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 associado a um domínio, deve ser utilizado o transporte HTTPS ou a máquina de destino deve ser adicionada à definição de configuração TrustedHosts.
O parâmetro ComputerName dos New-PSSession
cmdlets , Enter-PSSession
e Invoke-Command
aceita um endereço IP como um valor válido. No entanto, porque a autenticação Kerberos não suporta endereços IP. Quando você especifica um endereço IP, a autenticação NTLM é usada.
Para oferecer 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 conectar-se remotamente a partir de um computador baseado em grupo de trabalho
Por 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 associado a um domínio, deve ser utilizado o transporte HTTPS ou a máquina de destino deve ser adicionada à definição de 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 no 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 anfitriões fidedignos
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. Curingas 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ó. Apenas os membros do grupo Administradores no computador têm permissão para alterar a lista de anfitriões fidedignos no computador.
Atenção
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 da Fabrikam.
Set-Item wsman:localhost\client\trustedhosts *.fabrikam.com
O exemplo a seguir define a lista de hosts confiáveis para 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 contendo uma lista separada por vírgulas que inclua os valores atual e novo.
O exemplo a seguir adiciona 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 determinados computadores à 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 o uso Set-Item
para adicionar o computador.
Para obter mais informações sobre, consulte a ajuda do Connect-WSMan.
Como configurar a comunicação remota em portas alternativas
Por 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 Port 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
Por 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 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 resolver esse problema, use as opções de configuração de proxy no comando remoto.
- Use os parâmetros ProxyAccessType, ProxyAuthentication e ProxyCredential do cmdlet para criar uma variável contendo um objeto PSSessionOption com as configurações de
New-PSSessionOption
proxy para sua empresa. - Use a variável que contém o objeto PSSessionOption com o parâmetro SessionOption de um
New-PSSession
comando ,Enter-PSSession
ouInvoke-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 detetar uma sessão de 32 bits em um computador de 64 bits
Por 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 o caminho 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, as ferramentas em execução no System32
diretório que não têm contrapartidas no SysWow64
diretório não podem ser encontradas.
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ências
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
Por 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 diretiva de execução para o computador local, use o parâmetro Scope de para definir uma diretiva de Set-ExecutionPolicy
execução menos restritiva para um único processo.
Por exemplo, o exemplo a seguir define a política de execução para RemoteSigned
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 para iniciar uma única sessão com uma diretiva de PowerShell.exe
execução menos restritiva.
pwsh.exe -ExecutionPolicy RemoteSigned
Como definir e alterar quotas
Você pode usar cotas para proteger o computador local e o computador remoto do uso excessivo de recursos, tanto acidental quanto mal-intencionado. Quando as cotas entram em conflito com um comando, o PowerShell gera o seguinte erro.
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 as configurações MaxConcurrentOperations, MaxConcurrentOperationsPerUser e MaxConnections noWSMan:<ComputerName>\Service
nó. - Você pode usar os parâmetros MaximumReceivedDataSizePerCommand e MaximumReceivedObjectSize do cmdlet e a
$PSSessionOption
variável deNew-PSSessionOption
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 resolver o erro, altere o comando remoto para cumprir a cota ou aumente 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 de sessão do 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 WS-Management, consulte about_WSMan_Provider.
Como resolver erros de tempo limite
Você pode usar tempos limite para proteger o computador local e o computador remoto do uso excessivo de recursos, tanto acidental quanto mal-intencionado. Quando os tempos limite são definidos no computador local e remoto, o PowerShell usa as configurações de tempo limite mais curto.
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 seguinte erro.
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 tempo limite.
- Configuração MaxTimeoutMs no
WSMan:<ComputerName>
nó e as configurações EnumerationTimeoutMs e MaxPacketRetrievalTimeSeconds noWSMan:<ComputerName>\Service
nó. - Você pode proteger o computador local usando os parâmetros CancelTimeout, IdleTimeout, OpenTimeout e OperationTimeout do cmdlet e da
$PSSessionOption
variável deNew-PSSessionOption
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 resolver o erro, altere o comando para concluir 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 session 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 do WS-Management, consulte about_WSMan_Provider.
Como interromper um comando que não responde
Alguns programas nativos, como programas com uma interface de 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.
Quando você usa esses programas, você pode ver um comportamento inesperado, como nenhuma saída, saída parcial ou um comando remoto que não é concluído.
Para encerrar um programa que não responde, digite Ctrl+c. Use Get-Error
no host local e na sessão remota para exibir quaisquer erros que possam ter sido relatados.
Como 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 abortada devido a uma saída de thread ou a uma solicitação de aplicativo.
Normalmente, isso ocorre quando o serviço WinRM para ou reinicia enquanto outras operações do WinRM estão em andamento.
Para resolver esse problema, verifique se o serviço WinRM está em execução e tente o comando novamente.
Inicie o PowerShell com a opção Executar como administrador .
Execute o seguinte comando:
Start-Service WinRM
Execute novamente o comando que gerou o erro.
Limitações do Linux e macOS
A comunicação remota do PowerShell é Linux e macOS usando comunicação remota sobre SSH. Para obter mais informações, consulte Comunicação remota do PowerShell sobre SSH.