Windows Server 2025 / Cómo usar la administración remota de PowerShell con WinRM

La administración remota de PowerShell permite enviar comandos a otro servidor o abrir allí una consola interactiva. En Windows Server 2025, compruebe primero el servicio de administración remota de Windows (WinRM, Windows Remote Management), el punto de conexión y la autenticación antes de usar Enter-PSSession o Invoke-Command.

Separe la configuración del servidor y la conexión desde el cliente

Configure la recepción de conexiones en la consola de FS1 y ejecute los comandos de conexión en el PC de administración. Invertir esas ubicaciones puede habilitar escuchas innecesarias o consultar otro equipo. Este procedimiento usa Windows PowerShell 5.1 con WinRM; no utiliza el transporte SSH. Ejecute las instrucciones de forma interactiva y por partes, sin convertir todos los bloques del artículo en un único script.

• Identifique FS1 y una cuenta administradora válida para ese servidor.
• Use la red de administración aislada prevista para el laboratorio.
• Mantenga disponible la consola de FS1 para comprobar el estado y recuperar el acceso.

En FS1, abra Windows PowerShell con Ejecutar como administrador y registre el estado inicial, que puede estar ya configurado. Get-Service muestra el estado de WinRM; Get-PSSessionConfiguration enumera los puntos de conexión de PowerShell; Test-WSMan localhost comprueba la respuesta local de WinRM. Cuando la configuración esté operativa, espere WinRM en estado Running, configuraciones de sesión disponibles y una respuesta de WS-Management en vez de un error. Este chequeo local no demuestra ni el acceso desde el cliente ni su permiso para ejecutar comandos:

Get-Service WinRM
Get-PSSessionConfiguration
Test-WSMan localhost

Configure el servidor solo si es necesario

Si la recepción remota no está configurada, compruebe hostname en la consola de FS1 antes de ejecutar Enable-PSRemoting. Este comando puede iniciar o reiniciar WinRM, crear escuchas, habilitar configuraciones de sesión y modificar reglas del firewall. -Force evita las preguntas de confirmación; no omite los requisitos de permisos ni corrige una configuración equivocada. No lo ejecute en el PC solo para enviar comandos.

hostname
Enable-PSRemoting -Force
Test-WSMan localhost

Restrinja el origen al PC o a la subred de administración necesarios. En wf.msc, revise las reglas de entrada de WinRM, el perfil activo, el puerto y las direcciones remotas; compruebe también si otra regla permite un acceso más amplio. No desactive el firewall ni cambie arbitrariamente el perfil para resolver un fallo. Los puertos predeterminados de WinRM son TCP 5985 para HTTP y TCP 5986 para HTTPS.

Una escucha HTTP no significa por sí sola que los mensajes autenticados viajen sin protección. Con Kerberos o NTLM (NT LAN Manager), WinRM cifra los mensajes después de la autenticación; HTTPS añade la protección del transporte y requiere configurar y verificar el certificado. La identidad del servidor sigue siendo una cuestión distinta. Revise la autenticación y seguridad de mensajes de WinRM antes de elegir el diseño.

Use el nombre del servidor cuando el dominio ya funcione

Esta alternativa requiere que el PC y FS1 estén unidos al mismo dominio, que el sistema de nombres de dominio (DNS) y la hora funcionen y que la cuenta tenga los permisos necesarios. No la ejecute esperando éxito antes de configurar el dominio. Enter-PSSession abre una sesión interactiva: ejecute la conexión, espere a que el indicador muestre el destino y escriba después hostname, whoami y Exit-PSSession uno a uno.

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

Tras una conexión correcta, hostname debe identificar FS1 y whoami debe mostrar la identidad esperada. Exit-PSSession devuelve el control al PC de administración. Use el nombre de dominio completo (FQDN, Fully Qualified Domain Name) cuando exista DNS de dominio: una dirección IP no utiliza la misma autenticación Kerberos que el nombre del servidor.

Limite la confianza en la alternativa de grupo de trabajo

La conexión por IP o desde un grupo de trabajo tiene requisitos adicionales: HTTPS correctamente configurado o una entrada específica de TrustedHosts, además de credenciales explícitas. La guía de resolución de problemas de conexión remota explica esas condiciones. TrustedHosts suprime un error de verificación de identidad; no autentica al servidor. Para uso operativo, considere HTTPS con un certificado de confianza y respete las directivas de autenticación de la organización.

En este laboratorio aislado, verifique en la consola que FS1 usa la IP prevista. En el PC de administración, abra Windows PowerShell como administrador y compruebe que WinRM esté disponible para acceder a WSMan:. El ejemplo guarda la lista anterior y agrega solo ese destino; si la lista ya contiene comodines, estos siguen vigentes. Revise el valor original antes de cambiarlo: TrustedHosts afecta a todos los usuarios del PC. No sustituya la lista por un comodín global.

En el siguiente bloque, sustituya FS1\Administrator por la cuenta administradora real de FS1, con contraseña no vacía. Get-Credential con -UserName puede pedir primero el parámetro obligatorio Message en Windows PowerShell 5.1: escriba una descripción de la solicitud, no la contraseña. A continuación introduzca las credenciales en el aviso correspondiente. Ejecute Enter-PSSession de forma interactiva; tras entrar, compruebe hostname y salga con Exit-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

Las cuentas administradoras locales personalizadas pueden estar sujetas a restricciones remotas del Control de cuentas de usuario (UAC). Revise el diseño y los permisos, sin desactivar esas protecciones de forma general. Tras volver al PC de administración, restaure la lista con la misma ventana local de PowerShell donde guardó $previousHosts. Compruebe que no haya cambios posteriores de otra persona que deban conservarse; si cerró esa ventana y perdió la variable, no ejecute una restauración suponiendo que el valor anterior estaba vacío:

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

Ejecute una consulta remota y compruebe el origen

Cuando los requisitos del dominio se cumplan, ejecute en el PC de administración esta consulta para obtener la información del sistema operativo de FS1 sin abrir una consola interactiva:

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

Compruebe PSComputerName y los valores Caption, Version y LastBootUpTime devueltos para confirmar el servidor consultado; no confunda una salida local con una remota. Revise por separado DNS, acceso al puerto, respuesta de WinRM, autenticación y autorización de sesión. Que Test-WSMan responda no prueba el derecho a ejecutar comandos. Antes de revertir cambios en las escuchas o el servicio, compruebe las dependencias de otras herramientas y compárelos con el estado inicial.