Windows Server 2025 / Usar a comunicação remota do PowerShell com WinRM

O PowerShell Remoting envia comandos para outro servidor ou abre um shell interativo nele. Para o Windows Server 2025, verifique o ponto de extremidade e a autenticação do Windows Remote Management (WinRM) antes de usar Enter-PSSession ou Invoke-Command.

Separe a configuração do destino dos comandos de conexão do cliente

Execute a configuração do listener (ponto de escuta) no console do FS1 e os comandos de conexão no PC de gerenciamento. Inverter esses locais pode expor listeners desnecessários ou consultar o computador errado. Este exercício usa a comunicação remota do Windows PowerShell pelo WinRM, em vez da comunicação remota do PowerShell 7 por SSH.

  • Identifique o FS1 e uma conta de administrador válida.
  • Use a rede de gerenciamento isolada pretendida.
  • Mantenha o console do destino disponível para recuperação.

Verifique o estado atual do destino no Windows PowerShell aberto como administrador; a comunicação remota pode já estar configurada:

Get-Service WinRM
Get-PSSessionConfiguration
Test-WSMan localhost

Configure o destino somente quando necessário

Se não estiver configurado, execute o seguinte no FS1. O comando pode afetar listeners, a configuração da sessão e as configurações de firewall, então verifique o nome do computador primeiro.

hostname
Enable-PSRemoting -Force
Test-WSMan localhost

Restrinja o acesso ao PC de gerenciamento ou sub-rede necessários. Para falhas relacionadas a perfis, inspecione o contexto de rede real em vez de desativar o firewall. As portas padrão do WinRM são TCP 5985 para HTTP e 5986 para HTTPS.

O nome de um listener HTTP por si só não estabelece que o tráfego de mensagens autenticadas está desprotegido. Revise Autenticação e segurança de mensagens do WinRM ao projetar a verificação de identidade e a proteção de credenciais.

Use nomes de servidor em um domínio em funcionamento

Este exemplo pressupõe que o PC e o FS1 entraram no mesmo domínio, o DNS e o horário funcionam, e a conta tem permissão. Não espere que funcione antes do domínio existir. Execute essas linhas uma por vez em um console interativo. Depois de Enter-PSSession, aguarde o prompt identificar o servidor remoto antes de digitar os comandos seguintes; não execute esse bloco como um script completo.

Test-WSMan -ComputerName 'fs1.ad.example.test'
Enter-PSSession -ComputerName 'fs1.ad.example.test'
hostname
whoami
Exit-PSSession

Os comandos digitados após Enter-PSSession são executados no servidor de destino. Exit-PSSession retorna ao PC de gerenciamento. Um endereço IP altera as condições de autenticação em comparação com um nome de domínio usando Kerberos; prefira o nome de domínio totalmente qualificado (FQDN) quando o DNS do domínio estiver disponível.

Mantenha a confiança do grupo de trabalho com escopo restrito

Conexões baseadas em grupo de trabalho ou IP exigem condições adicionais, como HTTPS ou uma entrada específica em TrustedHosts. Veja orientações de solução de problemas remotos. TrustedHosts não autentica a identidade de um servidor; considere HTTPS com certificado confiável para uso operacional.

Para este laboratório isolado, verifique o IP do FS1 em seu console. No PC de gerenciamento, mantenha o valor original e adicione apenas esse alvo. Substitua a conta pelo administrador de servidor real pretendido; não use um curinga para todos os hosts. Se o valor existente já contiver *, adicionar esse destino não restringirá a confiança: examine a configuração antes de prosseguir. Execute também as linhas desse bloco uma por vez e aguarde o prompt remoto após Enter-PSSession.

$previousHosts = (Get-Item WSMan:\localhost\Client\TrustedHosts).Value
$labTargets = (@($previousHosts -split ',') + '172.24.50.20' | Where-Object { $_ } | Sort-Object -Unique) -join ','
Set-Item WSMan:\localhost\Client\TrustedHosts -Value $labTargets
$labCredential = Get-Credential -UserName 'FS1\Administrator'
Enter-PSSession -ComputerName '172.24.50.20' -Credential $labCredential
hostname
Exit-PSSession

Contas de administrador local personalizadas podem encontrar restrições remotas do Controle de Conta de Usuário (UAC). Reavalie o design de autenticação em vez de desativar amplamente essas proteções. Na mesma sessão do PC de gerenciamento, restaure o valor anterior após o laboratório:

if ([string]::IsNullOrEmpty($previousHosts)) {
    Clear-Item WSMan:\localhost\Client\TrustedHosts
} else {
    Set-Item WSMan:\localhost\Client\TrustedHosts -Value $previousHosts
}

Execute uma única consulta e feche a sessão

Uma vez que os pré-requisitos de domínio estejam satisfeitos, colete as informações do sistema operacional do servidor de destino em uma única operação:

Invoke-Command -ComputerName 'fs1.ad.example.test' -ScriptBlock {
    Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,LastBootUpTime
}

Verifique PSComputerName e o sistema operacional retornado para que um resultado local não seja confundido com um remoto. Solucione problemas de DNS, acessibilidade da porta, resposta do WinRM, autenticação e autorização de sessão separadamente. Uma resposta do Test-WSMan sozinha não estabelece direitos de execução de comandos. Antes de reverter alterações no listener, verifique se outras ferramentas de gerenciamento dependem do WinRM e compare com as configurações originais.