Perguntas frequentes sobre comunicação remota do PowerShell

Sim. Para funcionar remotamente, os computadores locais e remotos devem ter o PowerShell, o Microsoft .NET Framework e o protocolo dos Serviços Web para Gerenciamento (WS-Management). Todos os arquivos e outros recursos necessários para executar um comando específico devem estar no computador remoto.

Computadores que executam o Windows PowerShell 3.0 e computadores que executam o Windows PowerShell 2.0 podem se conectar entre si remotamente e executar comandos remotos. No entanto, alguns recursos, como a capacidade de se desconectar de uma sessão e se reconectar a ela, funcionam somente quando ambos os computadores estiverem executando o Windows PowerShell 3.0.

Você deve ter permissão para se conectar ao computador remoto, permissão para executar o PowerShell e permissão para acessar armazenamentos de dados (como arquivos e pastas) e o registro no computador remoto.

Para obter mais informações, confira about_Remote_Requirements.

Quando você envia um comando remoto, o comando é transmitido pela rede para o mecanismo do PowerShell no computador remoto e é executado no cliente do PowerShell no computador remoto. Os resultados do comando são enviados de volta para o computador local e aparecem na sessão do PowerShell no computador local.

Para transmitir os comandos e receber a saída, o PowerShell usa o protocolo WS-Management. Para obter informações sobre o protocolo WS-Management, confira ws-management protocol na documentação do Windows.

A partir do Windows PowerShell 3.0, as sessões remotas são armazenadas no computador remoto. Isso permite que você se desconecte da sessão e se reconecte de uma sessão diferente ou de um computador diferente sem interromper os comandos ou perder o estado.

Quando você se conecta a um computador remoto, o sistema usa as credenciais de nome de usuário e senha no computador local ou as credenciais fornecidas no comando para fazer logon no computador remoto. As credenciais e o restante da transmissão são criptografados.

Para adicionar proteção adicional, você pode configurar o computador remoto para usar protocolo SSL em vez de HTTP para escutar solicitações do Gerenciamento Remoto do Windows (WinRM). Em seguida, os usuários podem usar o parâmetro UseSSL dos cmdlets Invoke-Command, New-PSSession e Enter-PSSession ao estabelecer uma conexão. Esta opção usa o canal HTTPS, mais seguro, em vez de HTTP.

Não. Alguns cmdlets têm um parâmetro ComputerName que permite obter objetos do computador remoto.

Esses cmdlets não usam a comunicação remota do PowerShell. Portanto, você pode usá-los em qualquer computador que esteja executando o PowerShell, mesmo que o computador não esteja configurado para comunicação remota do PowerShell ou se o computador não atender aos requisitos de comunicação remota do PowerShell.

Esses cmdlets incluem o seguinte:

• Get-Hotfix
• Rename-Computer
• Restart-Computer
• Stop-Computer

Para localizar todos os cmdlets com um parâmetro ComputerName, digite:

Get-Help * -Parameter ComputerName
# or
Get-Command -ParameterName ComputerName

Para determinar se o parâmetro ComputerName de um determinado cmdlet requer comunicação remota do PowerShell, confira a descrição do parâmetro. Para exibir a descrição do parâmetro, digite:

Get-Help <cmdlet-name> -Parameter ComputerName

Por exemplo:

Get-Help Get-Hotfix -Parameter ComputerName

Para todos os outros comandos, use o cmdlet Invoke-Command.

Para executar um comando em um computador remoto, use o cmdlet Invoke-Command.

Coloque seu comando entre chaves ({}) para torná-lo um bloco de script. Use o parâmetro ScriptBlock de Invoke-Command para especificar o comando.

Você pode usar o parâmetro ComputerName de Invoke-Command para especificar um computador remoto. Ou você pode criar uma conexão persistente com um computador remoto (uma sessão) e, em seguida, usar o parâmetro Session de Invoke-Command para executar o comando na sessão.

Por exemplo, os comandos a seguir executam um comando Get-Process remotamente.

Invoke-Command -ComputerName Server01, Server02 -ScriptBlock {Get-Process}

#  - OR -

Invoke-Command -Session $s -ScriptBlock {Get-Process}

Para interromper um comando remoto, digite CTRL+C. A solicitação de interrupção é passada para o computador remoto, onde termina o comando remoto.

Para obter mais informações sobre comandos remotos, confira about_Remote e os tópicos da Ajuda para os cmdlets que dão suporte à comunicação remota.

Você pode usar o cmdlet Enter-PSSession para iniciar uma sessão interativa com um computador remoto.

No prompt do PowerShell, digite:

Enter-PSSession <ComputerName>

O prompt de comando é alterado para mostrar que você está conectado ao computador remoto.

<ComputerName>\C:>

Agora, os comandos que você digita são executados no computador remoto como se você os digitasse diretamente no computador remoto.

Para encerrar a sessão interativa, digite:

Exit-PSSession

Uma sessão interativa é uma sessão persistente que usa o protocolo WS-Management. Não é o mesmo que usar Telnet, mas fornece uma experiência semelhante.

Para obter mais informações, consulte Enter-PSSession.

Sim. Você pode executar comandos remotos especificando o nome do computador remoto, seu nome NetBIOS ou seu endereço IP. Ou, você pode executar comandos remotos especificando uma sessão do PowerShell (PSSession) conectada ao computador remoto.

Quando você usa o parâmetro ComputerName de Invoke-Command ou Enter-PSSession, o PowerShell estabelece uma conexão temporária. O PowerShell usa a conexão para executar apenas o comando atual e, em seguida, fecha a conexão. Este é um método muito eficiente para executar um único comando ou vários comandos não relacionados, mesmo em muitos computadores remotos.

Quando você usa o cmdlet New-PSSession para criar uma PSSession, o PowerShell estabelece uma conexão persistente para a PSSession. Em seguida, você pode executar vários comandos na PSSession, incluindo comandos que compartilham dados.

Normalmente, você cria uma PSSession para executar uma série de comandos relacionados que compartilham dados. Caso contrário, a conexão temporária criada pelo parâmetro ComputerName é suficiente para a maioria dos comandos.

Para obter mais informações sobre sessões, confira about_PSSessions.

Sim. O parâmetro ComputerName do cmdlet Invoke-Command aceita vários nomes de computador, e o parâmetro Session aceita várias PSSessions.

Quando você executa um comando Invoke-Command, o PowerShell executa os comandos em todos os computadores especificados ou em todas as PSSessions especificadas.

O PowerShell pode gerenciar centenas de conexões remotas simultâneas. No entanto, o número de comandos remotos que você pode enviar pode ser limitado pelos recursos do seu computador e sua capacidade de estabelecer e manter várias conexões de rede.

Para obter mais informações, confira o exemplo no tópico da Ajuda Invoke-Command.

Os perfis do PowerShell não são executados automaticamente em sessões remotas, portanto, os comandos adicionados pelo perfil não estão presentes na sessão. Além disso, a variável automática $profile não é preenchida em sessões remotas.

Para executar um perfil em uma sessão, use o cmdlet Invoke-Command.

Por exemplo, o comando a seguir executa o perfil CurrentUserCurrentHost do computador local na sessão em $s.

Invoke-Command -Session $s -FilePath $profile

O comando a seguir executa o perfil CurrentUserCurrentHost do computador remoto na sessão em $s. Como a variável $profile não é preenchida, o comando usa o caminho explícito para o perfil.

Invoke-Command -Session $s {
  . "$home\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1"
}

Depois de executar este comando, os comandos que o perfil adiciona à sessão estão disponíveis em $s.

Você também pode usar um script de inicialização em uma configuração de sessão para executar um perfil em cada sessão remota que usa a configuração de sessão.

Para obter mais informações sobre perfis do PowerShell, confira about_Profiles. Para obter mais informações sobre configurações de sessão, confira Register-PSSessionConfiguration.

Para ajudar você a gerenciar os recursos em seu computador local, o PowerShell inclui um recurso de limitação por comando que permite limitar o número de conexões remotas simultâneas estabelecidas para cada comando.

O padrão é 32 conexões simultâneas, mas você pode usar o parâmetro ThrottleLimit dos cmdlets para definir um limite de limitação personalizado para comandos específicos.

Ao usar o recurso de limitação, lembre-se de que ele é aplicado a cada comando, não à sessão inteira ou ao computador. Se você estiver executando comandos simultaneamente em várias sessões ou PSSessions, o número de conexões simultâneas será a soma das conexões simultâneas em todas as sessões.

Para localizar cmdlets com um parâmetro ThrottleLimit, digite:

Get-Help * -Parameter ThrottleLimit
-or-
Get-Command -ParameterName ThrottleLimit

Ao usar o PowerShell localmente, você envia e recebe objetos "dinâmicos" do .NET Framework; objetos "dinâmicos" são objetos associados a programas ou componentes reais do sistema. Quando você invoca os métodos ou altera as propriedades de objetos dinâmicos, as alterações afetam o programa ou componente real. E, quando as propriedades de um programa ou componente são alteradas, as propriedades do objeto que os representa também são alteradas.

No entanto, como a maioria dos objetos dinâmicos não pode ser transmitida pela rede, o PowerShell "serializa" a maioria dos objetos enviados em comandos remotos, ou seja, converte cada objeto em uma série de elementos de dados XML (Constraint Language in XML [CLiXML]) para transmissão.

Quando o PowerShell recebe um objeto serializado, ele converte o XML em um tipo de objeto desserializado. O objeto desserializado é um registro preciso das propriedades do programa ou componente em um momento anterior, mas não é mais "dinâmico", ou seja, não está mais diretamente associado ao componente. E os métodos são removidos porque não são mais eficazes.

Normalmente, você pode usar objetos desserializados da mesma forma que usaria objetos dinâmicos, mas deve estar ciente de suas limitações. Além disso, os objetos retornados pelo cmdlet Invoke-Command têm propriedades adicionais que ajudam você a determinar a origem do comando.

Alguns tipos de objeto, como objetos DirectoryInfo e GUIDs, são convertidos novamente em objetos ativos quando são recebidos. Esses objetos não precisam de nenhuma manipulação ou formatação especial.

Para obter informações sobre interpretação e formatação de saída remota, confira about_Remote_Output.

Sim. Um trabalho em segundo plano do PowerShell é um comando do PowerShell que é executado de forma assíncrona sem interagir com a sessão. Quando você inicia um trabalho em segundo plano, o prompt de comando retorna imediatamente e você pode continuar a trabalhar na sessão enquanto o trabalho é executado mesmo que ele seja executado por um longo período de tempo.

Você pode iniciar um trabalho em segundo plano mesmo enquanto outros comandos estão em execução porque trabalhos em segundo plano sempre são executados de forma assíncrona em uma sessão temporária.

Você pode executar trabalhos em segundo plano em um computador local ou remoto. Por padrão, um trabalho em segundo plano é executado no computador local. No entanto, você pode usar o parâmetro AsJob do cmdlet Invoke-Command para executar qualquer comando remoto como um trabalho em segundo plano. E você pode usar Invoke-Command para executar um comando Start-Job remotamente.

Para obter mais informações sobre trabalhos em segundo plano no PowerShell, confira about_Jobs e about_Remote_Jobs.

Você pode usar comandos remotos do PowerShell para executar programas baseados no Windows em computadores remotos. Por exemplo, você pode executar Shutdown.exe ou Ipconfig.exe em um computador remoto.

No entanto, você não pode usar comandos do PowerShell para abrir a interface do usuário para qualquer programa em um computador remoto.

Quando você inicia um programa Windows em um computador remoto, o comando não é concluído e o prompt de comando do PowerShell não é retornado, até que o programa seja concluído ou até que você pressione CTRL+C para interromper o comando. Por exemplo, se você executar o programa Ipconfig.exe em um computador remoto, o prompt de comando não retornará até que Ipconfig.exe seja concluído.

Se você usar comandos remotos para iniciar um programa que tenha uma interface do usuário, o processo do programa será iniciado, mas a interface do usuário não aparecerá. O comando do PowerShell não está concluído e o prompt de comando não retorna até que você interrompa o processo do programa ou até pressionar CTRL+C, o que interrompe o comando e interrompe o processo.

Por exemplo, se você usar um comando do PowerShell para executar Notepad em um computador remoto, o processo do Bloco de notas será iniciado no computador remoto, mas a interface do usuário do Bloco de notas não aparecerá. Para interromper o comando e restaurar o prompt de comando, pressione CTRL+C.

Sim. Cada sessão remota deve usar uma das configurações de sessão no computador remoto. Você pode gerenciar as configurações de sessão em seu computador (e as permissões para essas configurações de sessão) para determinar quem pode executar comandos remotamente em seu computador e quais comandos eles podem executar.

Uma configuração de sessão configura o ambiente para a sessão. Você pode definir a configuração usando um assembly que implementa uma nova classe de configuração ou usando um script executado na sessão. A configuração pode determinar os comandos disponíveis na sessão. Além disso, a configuração pode incluir configurações que protegem o computador, como configurações que limitam a quantidade de dados que a sessão pode receber remotamente em um único objeto ou comando. Você também pode especificar um descritor de segurança que determina as permissões necessárias para usar a configuração.

O cmdlet Enable-PSRemoting cria as configurações de sessão padrão em seu computador: Microsoft.PowerShell, Microsoft.PowerShell.Workflow e Microsoft.PowerShell32 (somente sistemas operacionais de 64 bits). Enable-PSRemoting define o descritor de segurança para a configuração para permitir que apenas membros do grupo Administradores em seu computador as usem.

Você pode usar os cmdlets de configuração de sessão para editar as configurações de sessão padrão, criar novas configurações de sessão e alterar os descritores de segurança de todas as configurações de sessão.

A partir do Windows PowerShell 3.0, o cmdlet New-PSSessionConfigurationFile permite criar configurações de sessão personalizadas usando um arquivo de texto. O arquivo inclui opções para definir o modo de idioma e especificar os cmdlets e módulos disponíveis em sessões que usam a configuração da sessão.

Quando os usuários usam os cmdlets Invoke-Command, New-PSSession ou Enter-PSSession, eles podem usar o parâmetro ConfigurationName para indicar a configuração de sessão usada para a sessão. Além disso, eles podem alterar a configuração padrão que suas sessões usam alterando o valor da variável de preferência $PSSessionConfigurationName na sessão.

Para obter mais informações sobre configurações de sessão, confira a Ajuda para os cmdlets de configuração de sessão. Para localizar os cmdlets de configuração de sessão, digite:

Get-Command *PSSessionConfiguration

O cenário de comunicação remota mais comum do PowerShell envolvendo vários computadores é a configuração um-para-muitos, na qual um computador local (o computador do administrador) executa comandos do PowerShell em vários computadores remotos. Isso é conhecido como o cenário de "fan-out".

No entanto, em algumas empresas, a configuração é muitos-para-um, em que muitos computadores cliente se conectam a um único computador remoto que está executando o PowerShell, como um servidor de arquivos ou um quiosque. Isso é conhecido como a configuração "fan-in".

A comunicação remota do PowerShell dá suporte a configurações de fan-out e fan-in.

Para a configuração de fan-out, o PowerShell usa o protocolo dos Serviços Web para Gerenciamento (WS-Management) e o serviço WinRM que dá suporte à implementação da Microsoft do WS-Management. Quando um computador local se conecta a um computador remoto, o WS-Management estabelece uma conexão e usa um plug-in para o PowerShell para iniciar o processo de host do PowerShell (Wsmprovhost.exe) no computador remoto. O usuário pode especificar uma porta alternativa, uma configuração de sessão alternativa e outros recursos para personalizar a conexão remota.

Para dar suporte à configuração de "fan-in", o PowerShell usa os Serviços de Informações da Internet (IIS) para hospedar o WS-Management, carregar o plug-in do PowerShell e iniciar o PowerShell. Nesse cenário, em vez de iniciar cada sessão do PowerShell em um processo separado, todas as sessões do PowerShell são executadas no mesmo processo de host.

Não há suporte para hospedagem do IIS e gerenciamento remoto de fan-in no Windows XP ou no Windows Server 2003.

Em uma configuração fan-in, o usuário pode especificar um URI de conexão e um ponto de extremidade HTTP, incluindo o transporte, o nome do computador, a porta e o nome do aplicativo. O IIS encaminha todas as solicitações com um nome de aplicativo especificado para o aplicativo. O padrão é o WS-Management, que pode hospedar o PowerShell.

Você também pode especificar um mecanismo de autenticação e proibir ou permitir o redirecionamento de pontos de extremidade HTTP e HTTPS.

Sim. A comunicação remota do PowerShell está disponível mesmo quando o computador local não está em um domínio. Você pode usar os recursos de comunicação remota para se conectar às sessões e criar sessões no mesmo computador. Os recursos funcionam da mesma forma que funcionam quando você se conecta a um computador remoto.

Para executar comandos remotos em um computador em um grupo de trabalho, altere as seguintes configurações do Windows no computador.

Cuidado: essas configurações afetam todos os usuários no sistema e podem tornar o sistema mais vulnerável a um ataque mal-intencionado. Tenha cuidado ao fazer essas alterações.

• Windows Vista, Windows 7, Windows 8:

  Crie a seguinte entrada do Registro e defina seu valor como 1: LocalAccountTokenFilterPolicy em HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

  Você pode usar o seguinte comando do PowerShell para adicionar esta entrada:

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

• Windows Server 2003, Windows Server 2008, Windows Server 2012, Windows Server 2012 R2:

  Nenhuma alteração é necessária porque a configuração padrão da política "Acesso à rede: compartilhamento e modelo de segurança para contas locais" é "Clássico". Verifique a configuração caso ela tenha sido alterada.

Sim. Normalmente, os comandos são executados sem erros, embora talvez seja necessário usar o parâmetro Credential dos cmdlets ou Invoke-Command, New-PSSession ou Enter-PSSession para fornecer as credenciais de um membro do grupo Administradores no computador remoto. Às vezes, isso é necessário mesmo quando o usuário atual é membro do grupo Administradores nos computadores locais e remotos.

No entanto, se o computador remoto não estiver em um domínio em que o computador local confia, o computador remoto poderá não conseguir autenticar as credenciais do usuário.

Para habilitar a autenticação, use o comando a seguir para adicionar o computador remoto à lista de hosts confiáveis para o computador local no WinRM. Digite o comando no prompt do PowerShell.

Set-Item WSMan:\localhost\Client\TrustedHosts -Value <Remote-computer-name>

Por exemplo, para adicionar o computador Server01 à lista de hosts confiáveis no computador local, digite o seguinte comando no prompt do PowerShell:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value Server01

Sim. Para obter mais informações, confira Comunicação remota do PowerShell por meio do SSH.

Confira também

about_Remote

about_Profiles

about_PSSessions

about_Remote_Jobs

about_Remote_Variables

Invoke-Command

New-PSSession