Partilhar via


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-PSRemotingo , 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-PSSessionextremidade 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-PSSessioncmdlets , 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-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 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 no WSMan:<ComputerName>\Service nó.
  • Você pode usar os parâmetros MaximumReceivedDataSizePerCommand e MaximumReceivedObjectSize do cmdlet e a $PSSessionOption variável de New-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 no WSMan:<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 de New-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.

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

  2. Execute o seguinte comando:

    Start-Service WinRM

  3. 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.

Consulte também