about_Remote_Troubleshooting

  • Artigo

Descrição breve

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

Descrição longa

Esta seção descreve alguns dos problemas que você pode encontrar ao usar os recursos de comunicação remota do PowerShell baseados em tecnologia WS-Management e sugere soluções para esses problemas.

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. Além disso, os tópicos da Ajuda para cada um dos cmdlets de comunicação remota, particularmente as descrições de parâmetro, têm informações úteis projetadas para ajudá-lo a evitar problemas.

Observação

Para exibir ou alterar as configurações do computador local na unidade WSMan: incluindo alterações nas configurações de sessão, hosts confiáveis, portas ou ouvintes, inicie o PowerShell com a opção Executar como administrador .

Solução de problemas de permissão e autenticação

Esta seção discute problemas de comunicação remota relacionados a permissões de usuário e computador e requisitos de comunicação remota.

Como executar como administrador

ERROR: Access is denied. You need to run this cmdlet from an elevated
process.

Para iniciar uma sessão remota no computador local ou para exibir ou alterar as configurações do computador local no WSMan: unidade, incluindo alterações nas configurações de sessão, hosts confiáveis, portas ou ouvintes, inicie Windows PowerShell com a opção Executar como administrador.

Para começar Windows PowerShell com a opção Executar como administrador:

  • Clique com o botão direito do mouse em um ícone Windows PowerShell (ou Windows PowerShell ISE) e clique em Executar como administrador.

    Para começar Windows PowerShell com a opção Executar como administrador no Windows 7 e no Windows Server 2008 R2.

  • Na barra de tarefas do Windows, clique com o botão direito do mouse no ícone Windows PowerShell e clique em Executar como administrador.

    No Windows Server 2008 R2, o ícone Windows PowerShell é fixado na barra de tarefas por padrão.

Como habilitar a comunicação remota

ERROR:  ACCESS IS DENIED

or

ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to
listen for requests on the correct port and HTTP URL.

Nenhuma configuração é necessária para permitir que um computador envie comandos remotos. No entanto, para receber comandos remotos, a comunicação remota do PowerShell deve ser habilitada no computador. A habilitação inclui iniciar o serviço WinRM, definir o tipo de inicialização do serviço WinRM como Automático, criar ouvintes para conexões HTTP e HTTPS e criar configurações de sessão padrão.

Windows PowerShell comunicação remota está habilitada em Windows Server 2012 e versões mais recentes do Windows Server por padrão. Em todos os outros sistemas, execute o Enable-PSRemoting cmdlet para habilitar a comunicação remota. Você também pode executar o Enable-PSRemoting cmdlet para habilitar novamente a comunicação remota em Windows Server 2012 e versões mais recentes do Windows Server se a comunicação remota estiver desabilitada.

Para configurar um computador para receber comandos remotos, use o Enable-PSRemoting cmdlet. O comando a seguir habilita todas as configurações remotas necessárias, habilita as configurações de sessão e reinicia o serviço WinRM para tornar as alterações efetivas.

Enable-PSRemoting

Para suprimir todos os prompts do usuário, digite:

Enable-PSRemoting -Force

Para obter mais informações, consulte Enable-PSRemoting.

Como habilitar a comunicação remota em uma empresa

ERROR:  ACCESS IS DENIED

or

ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to listen
for requests on the correct port and HTTP URL.

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.

  • Para configurar ouvintes para comunicação remota, habilite a configuração automática permitir a política de grupo de ouvintes .

  • Para definir o tipo de inicialização do WinRM (Gerenciamento Remoto do Windows) como Automático em vários computadores, use o Set-Service cmdlet.

  • Para habilitar uma exceção de firewall, use o Firewall do Windows: permitir a política de grupo de Exceções de Porta Local .

Como habilitar ouvintes usando uma política de grupo

ERROR:  ACCESS IS DENIED

or

ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to listen
for requests on the correct port and HTTP URL.

Para configurar os ouvintes para todos os computadores em um domínio, habilite a política Permitir configuração automática de ouvintes no seguinte caminho 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. Curingas (*) são permitidos.

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

ERROR:  Unable to check the status of the firewall

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

Em versões de servidor do Windows, Enable-PSRemoting é bem-sucedido em todos os tipos de local de rede. Ele cria regras de firewall que permitem 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.

Nas versões do 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.

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.

Observação

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

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

ERROR:  ACCESS IS DENIED

or

ERROR: The connection to the remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to listen
for requests on the correct port and HTTP URL.

Para habilitar uma exceção de firewall para todos os computadores em um domínio, habilite o Firewall do Windows: permitir a política de exceções de porta local 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 no computador usem o Firewall do Windows em Painel de Controle para criar uma exceção de firewall para o serviço de Gerenciamento Remoto do Windows.

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

The client cannot connect to the destination specified in the request. Verify
that the service on the destination is running and is accepting requests.

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

PS> 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

ERROR:  ACCESS IS DENIED

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.

Nas versões de servidor do Windows, o tipo de inicialização do serviço WinRM (Gerenciamento Remoto do Windows) é Automático.

No entanto, nas versões do cliente do Windows, o serviço WinRM é desabilitado por padrão.

Para definir o tipo de inicialização de um serviço em um computador remoto, use o Set-Service cmdlet.

Para executar o comando em vários computadores, você pode criar um arquivo de texto ou um arquivo CSV dos nomes do computador.

Por exemplo, os comandos a seguir obtêm uma lista de nomes de computador do Servers.txt arquivo e definem o tipo de inicialização do serviço WinRM em todos os computadores como Automático.

$servers = Get-Content servers.txt
Set-Service WinRM -ComputerName $servers -startuptype Automatic

Para ver os resultados, use o Get-WMIObject cmdlet com o objeto Win32_Service . Para obter mais informações, consulte Set-Service.

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

ERROR:  ACCESS IS DENIED

Para se conectar ao computador local e executar comandos remotamente, o computador local deve incluir configurações de sessão para comandos remotos.

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 padrão originais, use o Unregister-PSSessionConfiguration cmdlet para excluir as configurações de sessão alteradas e, em seguida, use o Enable-PSRemoting cmdlet para restaurá-las. 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 unidade WSMan: . 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 o WSMan: unidade, consulte o tópico ajuda para o provedor WSMan ("Get-Help wsman").

Como fornecer credenciais de administrador

ERROR:  ACCESS IS DENIED

Para criar uma PSSession ou executar comandos em um computador remoto, por padrão, o usuário atual deve ser membro do grupo Administradores no computador remoto. Às vezes, as credenciais são necessárias mesmo quando o usuário atual está conectado a uma conta que é membro do grupo Administradores.

Se o usuário atual for membro do grupo Administradores no computador remoto ou puder fornecer as credenciais de um membro do grupo Administradores, use o parâmetro Credencial do New-PSSessionEnter-PSSession cmdlets ou Invoke-Command conecte-se remotamente.

Por exemplo, o comando a seguir fornece as credenciais de um Administrador.

Invoke-Command -ComputerName Server01 -Credential Domain01\Admin01

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

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

ERROR:  ACCESS IS DENIED

Para estabelecer uma PSSession ou executar um comando em um computador remoto, o usuário deve ter permissão para usar as configurações de sessão no computador remoto.

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 comando a seguir abre uma folha de propriedades que permite alterar o descritor de segurança da configuração de sessão padrão do 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

ERROR:  ACCESS IS DENIED

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 com apenas tokens de privilégio de usuário padrão.

No entanto, 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 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.

Para alterar a política, use o comando a seguir para definir o valor da entrada do registro LocalAccountTokenFilterPolicy como 1.

New-ItemProperty -Name LocalAccountTokenFilterPolicy `
  -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System `
  -PropertyType DWord -Value 1

Como usar um endereço ip em um comando remoto

ERROR: The WinRM client cannot process the request. If the authentication
scheme is different from Kerberos, or if the client computer is not joined to a
domain, then HTTPS transport must be used or the destination machine must be
added to the TrustedHosts configuration setting.

O parâmetro ComputerName do New-PSSessionEnter-PSSession . e Invoke-Command cmdlets 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, a autenticação NTLM é usada por padrão sempre que você especifica um endereço IP.

Ao usar a autenticação NTLM, o procedimento a seguir é necessário para comunicação remota.

  1. Configure o computador para transporte HTTPS ou adicione os endereços IP dos computadores remotos à lista TrustedHosts no computador local.

  2. Use o parâmetro credencial em todos os comandos remotos.

    Isso é necessário mesmo quando você está enviando as credenciais do usuário atual.

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

ERROR: The WinRM client cannot process the request. If the authentication
scheme is different from Kerberos, or if the client computer is not joined to a
domain, then HTTPS transport must be used or the destination machine must be
added to the TrustedHosts configuration setting.

Quando o computador local não está em um domínio, o procedimento a seguir é necessário para comunicação remota.

  1. Configure o computador para o transporte HTTPS ou adicione os nomes dos computadores remotos à lista TrustedHosts no computador local.

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

    Para definir a senha para sua conta de usuário, use contas de usuário em Painel de Controle.

  3. Use o parâmetro credencial em todos os comandos remotos.

    Isso é necessário mesmo quando você está enviando as credenciais do 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 host confiável, use a unidade WSMan: . 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

Você também pode usar o Set-Location cmdlet (alias = cd) para navegar pelo WSMan: unidade até o local. Por exemplo:

cd WSMan:\localhost\Client; dir

Para adicionar todos os computadores à lista de hosts confiáveis, use o comando a seguir, que coloca um valor de * (todos) no ComputerName

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 à lista de hosts confiáveis.

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

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

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

em que cada valor <ComputerName> deve ter o seguinte formato:

<Computer>.<Domain>.<Company>.<top-level-domain>

Por exemplo:

$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 e, em seguida, defina o valor para uma lista separada por vírgulas que inclui os valores atuais e novos.

Por exemplo, para adicionar o computador Server01 a uma lista de hosts confiáveis existente, use o seguinte comando:

$curValue = (Get-Item wsman:\localhost\Client\TrustedHosts).value

Set-Item wsman:\localhost\Client\TrustedHosts -Value `
  "$curValue, Server01.Domain01.Fabrikam.com"

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 cmdlet para adicionar um nó para o computador remoto ao WSMan: unidade no computador local. Em seguida, use um Set-Item comando para adicionar o computador.

Para obter mais informações sobre o Connect-WSMan cmdlet, consulte Connect-WSMan.

Solução de problemas de configuração do computador

Esta seção discute problemas de comunicação remota relacionados a configurações específicas de um computador, domínio ou empresa.

Como configurar a comunicação remota em portas alternativas

ERROR: The connection to the specified remote host was refused. Verify that the
WS-Management service is running on the remote host and configured to listen
for requests on the correct port and HTTP URL.

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 Porta em um comando remoto.

Para alterar a porta padrão que o PowerShell usa, use Set-Item o cmdlet no WSMan: unidade para alterar o valor da 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

ERROR: The client cannot connect to the destination specified in the request.
Verify that the service on the destination is running and is accepting
requests.

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 em seu comando remoto. As seguintes configurações estão disponíveis:

  • ProxyAccessType
  • ProxyAuthentication
  • ProxyCredential

Para definir essas opções para um comando específico, use o seguinte procedimento:

  1. Use os parâmetros ProxyAccessType, ProxyAuthentication e ProxyCredential do New-PSSessionOption cmdlet para criar um objeto de opção de sessão com as configurações de proxy para sua empresa. Salvar o objeto de opção é uma variável.

  2. Use a variável que contém o objeto de opção como o valor do parâmetro SessionOption de um New-PSSession, Enter-PSSessionou Invoke-Command comando.

Por exemplo, o comando a seguir cria um objeto de opção de sessão com opções de sessão proxy e usa o objeto para criar uma sessão remota.

$SessionOption = New-PSSessionOption -ProxyAccessType IEConfig `
-ProxyAuthentication Negotiate -ProxyCredential Domain01\User01

New-PSSession -ConnectionURI https://www.fabrikam.com

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, use o objeto de opção que New-PSSessionOption cria no valor da variável de $PSSessionOption preferência. 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

ERROR: The term "<tool-Name>" is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the name, or
if a path was included, verify that the path is correct and try again.

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

Como resultado, se você tentar usar ferramentas no diretório System32 que não têm equivalentes no diretório SysWow64, como Defrag.exe, as ferramentas não poderão ser encontradas no 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 . O comando a seguir localiza a arquitetura do processador da sessão na $s variável.

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

x86

Para obter mais informações sobre configurações de sessão, 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

ERROR: Import-Module: File <filename> cannot be loaded because the
execution of scripts is disabled on this system.

Os Import-PSSession cmdlets e os Export-PSSession cmdlets 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, usando ouImport-Module, Import-PSSession a política de execução na sessão atual não pode ser Restrita ou AllSigned. Para obter informações sobre políticas de execução do PowerShell, consulte about_Execution_Policies.

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

Por exemplo, o comando a seguir inicia um processo com a RemoteSigned política de execução. A alteração da política de execução afeta apenas o processo atual e não altera a configuração do Registro de ExecutionPolicy do PowerShell.

Set-ExecutionPolicy -Scope process -ExecutionPolicy RemoteSigned

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

PowerShell.exe -ExecutionPolicy RemoteSigned

Para obter mais informações sobre políticas de execução, consulte about_Execution_Policies. Para obter mais informações, digite PowerShell.exe -?.

Como definir e alterar cotas

ERROR: The total data received from the remote client exceeded allowed
maximum.

Você pode usar cotas para proteger o computador local e o computador remoto contra uso excessivo de recursos, acidental e mal-intencionado.

As cotas a seguir estão disponíveis na configuração básica.

  • O provedor WSMan (WSMan:) fornece várias configurações de cota, como 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 proteger o computador local usando os parâmetros MaximumReceivedDataSizePerCommand e MaximumReceivedObjectSize do New-PSSessionOption cmdlet e a $PSSessionOption variável de preferência.

  • Você pode proteger o computador remoto adicionando restrições às configurações de sessão, como usando os parâmetros MaximumReceivedDataSizePerCommandMB e MaximumReceivedObjectSizeMB do Register-PSSessionConfiguration cmdlet.

Quando as cotas entram em conflito com um comando, o PowerShell gera um erro.

Para resolver o erro, altere o comando remoto para cumprir a cota. Ou determine a origem da cota e, em seguida, 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.

Set-PSSessionConfiguration -Name microsoft.PowerShell `
  -MaximumReceivedObjectSizeMB 11 -Force

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

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

Como resolver erros de tempo limite

ERROR: The WS-Management service cannot complete the operation within
the time specified in OperationTimeout.

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.

Os tempos limite a seguir estão disponíveis na configuração básica.

  • O provedor WSMan (WSMan:) fornece várias configurações de tempo limite do lado do cliente e do lado do serviço, como a 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.

Quando um valor de tempo limite não permite a conclusão de uma operação, o PowerShell encerra a operação e gera um erro.

Para resolver o erro, altere o comando para ser concluído dentro do intervalo de tempo limite ou determine a origem do limite de tempo limite e aumente o intervalo de tempo limite para permitir que o comando seja concluído.

Por exemplo, os comandos a seguir usam o New-PSSessionOption cmdlet para criar um objeto de opção de sessão com um valor OperationTimeout de 4 minutos (em MS) e, em seguida, usar o objeto de 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 WS-Management, consulte o tópico ajuda para o provedor WSMan (tipo Get-Help WSMan).

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

Solução de problemas de comportamento sem resposta

Esta seção discute problemas de comunicação remota que impedem que um comando seja concluído e impeça ou atrase o retorno do prompt do PowerShell.

Como interromper um comando

Alguns programas nativos do Windows, 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. Para exibir quaisquer erros que possam ter sido relatados, digite $error o host local e a sessão remota.

Como se recuperar de uma falha de operação

ERROR: The I/O operation has been aborted because of either a thread exit
or an  application request.

Esse erro é retornado quando uma operação é encerrada antes de ser concluída. Normalmente, ocorre quando o serviço WinRM é interrompido ou reiniciado 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 comando a seguir:

    Start-Service WinRM

  3. Execute novamente o comando que gerou o erro.

Limitações do Linux e macOS

Autenticação

Somente a autenticação básica funciona no macOS e tentar usar outros esquemas de autenticação pode resultar na falha do processo.

Consulte as instruções de autenticação OMI .

Confira também