PSRemoting (Parte 1): ¿Qué es PowerShell Remoting?

Si bien ejecutando scripts de PowerShell de forma local en nuestras máquinas y servidores podemos realizar grandes automatizaciones, cuando PowerShell empieza a brillar es cuando ejecutamos acciones directamente en máquinas remotas y de forma masiva. Empezamos esta serie de entradas en la que profundizaremos sobre esta tecnología viendo qué es PowerShell Remoting y cómo funciona.

Os dejo el índice de la serie:

• Parte 1: ¿Qué es PowerShell Remoting?
• Parte 2: Cómo configurar PowerShell Remoting.
• Parte 3: Cómo utilizar PowerShell Remoting.

¿Qué es PowerShell Remoting?

PowerShell Remoting es una tecnología introducida en Windows PowerShell 2.0 (y refinada en Windows PowerShell 3.0) con la cual podremos ejecutar órdenes de PowerShell en máquinas remotas a través de la red de una forma estandarizada y muy sencilla.

Con PowerShell Remoting conseguimos la capacidad de administrar cientos de máquinas a la vez y ejecutar órdenes en las mismas sin la necesidad de aumentar nuestro tiempo de dedicación.

Es importante no confundir PowerShell Remoting con la capacidad que tienen algunos cmdlets como Get-Process o Get-Service de facilitar un parámetro -ComputerName con el que ejecutar dicho cmdlet de forma remota.

• PowerShell Remoting trabaja sobre WS-Man, en cambio estos cmdlets utilizan DCOM/RPC. Tal y como vimos en la entrada sobre CIM y WMI, WS-Man es un protocolo más ‘Firewall friendly’ basado en HTTP/HTTPS que DCOM/RPC.
• PowerShell Remoting proporciona capacidades de ejecución remota a cualquier cmdlet o función que la máquina sea capaz de ejecutar. Con DCOM/RPC cada cmdlet tiene que ser desarrollado con dicha funcionalidad.
• Con PowerShell Remoting la carga del procesamiento de las tareas se realiza en la máquina remota, con DCOM/RPC ésta se genera en la máquina local.
• Si realizamos una ejecución masiva a diferentes máquinas con PowerShell Remoting se ejecutan las tareas en paralelo gracias a lo comentado en el punto anterior. De hacerlo con DCOM/RPC se realizan de forma secuencial, con su correspondiente aumento de tiempos de ejecución.

¿Cómo funciona PowerShell Remoting?

Una vez entendido qué es PowerShell Remoting es importante tener claro cómo funciona para poder sacar el máximo partido de él. Para ilustrar mejor su funcionamiento he creado este diagrama donde podemos ver una transacción de PowerShell Remoting:

PowerShell Remoting funciona a modo cliente-servidor. Cuando iniciamos una comunicación de PowerShell Remoting desde la máquina cliente ésta manda una petición utilizando WS-Man a la máquina servidor por defecto por el puerto 5985/TCP utilizando HTTP (también se puede ejecutar utilizando HTTPS en cuyo caso utilizaría el puerto 5986/TCP).

Una vez llega dicha petición a la máquina servidor el servicio WinRM (Windows Remote Management) es el encargado de recepcionarla y facilitársela al servicio de background de PowerShell para que la procese y se mantiene a la espera. Cuando el servicio de background de PowerShell finaliza la ejecución devuelve el resultado a WinRM que se encarga de devolver el resultado a la máquina cliente utilizando el mismo canal.

Requisitos de PowerShell Remoting

Como hemos visto anteriormente, PowerShell Remoting fue lanzado para Windows PowerShell 2.0, pero no fue hasta la versión 3.0 que se añadió la funcionalidad completa. Es por ello que desde Microsoft se facilitan dos “juegos” de requisitos:

Para utilizar la funcionalidad de PowerShell Remoting de PowerShell 3.0 o superior tanto cliente como servidor deben disponer de:

• PowerShell 3.0 o superior.
• .NET Framework 4.0 o superior.
• Windows Remote Management 3.0.

Estos requisitos vienen instalados por defecto en todos los sistemas operativos de Microsoft a partir de Windows 8 y Windows Server 2012.

Si en cambio vamos a utilizar la funcionalidad de 2.0 tanto cliente como servidor deben disponer de:

• PowerShell 2.0.
• .NET Framework 2.0 o superior.
• Windows Remote Management 2.0

Si bien podríamos realizar conexiones desde una máquina con PowerShell 2.0 a una con 3.0 dicha comunicación se realizaría perdiendo la funcionalidad que ofrece la versión 3.0.

Por último, a estos requisitos a nivel de máquina deberíamos añadir los siguientes requisitos a nivel de red:

• Comunicación entre cliente y servidor por el puerto 5985 TCP (para utilizar WS-MAN sobre HTTPS).
• Comunicación ente cliente y servidor por el puerto 5986 TCP (para utilizar WS-MAN sobre HTTPS).

Conclusión

Y hasta aquí la entrada de hoy, la más teórica de las de esta serie pero sin duda necesaria para entender lo que haremos en las partes más prácticas.

En la próxima entrada veremos qué opciones tenemos para habilitar PowerShell Remoting tanto en origen como en destino y así empezar a trastear con esta tecnología.

¡Nos vemos pronto!