Windows PowerShellUn adelanto de la administración remota en la versión 2.0
Don Jones
Este artículo se basa en una versión preliminar de Windows PowerShell. Por tanto, toda la información de este documento está sujeta a cambios.
Contenido
Dos tipos de comunicación remota
Sincrónico frente a asincrónico
Espacios de ejecución reutilizables
Comunicación remota convergente
La aplicación rompedora en la versión 2.0
¿Ha tenido la oportunidad de experimentar con la versión más reciente de Community Technology Preview (CTP) de Windows PowerShell 2.0? La versión más reciente, CTP2, ha refinado aún más la administración remota, y ahora mismo es un excelente momento para comenzar a familiarizarse con las nuevas capacidades que ofrece. Antes de comenzar, le recomiendo que dedique un momento a
descargarla de go.microsoft.com/fwlink/?LinkID=119707.
En primer lugar, permítame clarificar un par de puntos importantes. CTP es código en una fase anterior a la beta, que Microsoft ofrece para permitir que los usuarios ansiosos como yo se hagan una idea de hacia dónde se dirige Microsoft con la próxima versión de una aplicación. Cada hito o entrega de CTP (como la llaman en el sector) puede variar completamente con respecto a las entregas anteriores. Por eso el equipo de desarrollo reúne los comentarios, los revisa con cuidado y, a continuación, realiza los cambios en la aplicación basándose en estos comentarios de los usuarios. Esa metodología plantea una importante ventaja y una importante salvedad acerca del uso de CTP.
La ventaja consiste en que al usar CTP, se pueden proporcionar comentarios (a través del sitio web connect.microsoft.com) acerca del producto durante un momento del desarrollo en que el equipo puede actuar sobre esos comentarios. Si espera hasta la etapa beta o, peor aún, hasta la etapa de candidato de versión comercial, es mucho más difícil que se incorporen sus comentarios. Durante el uso de CTP, quizás algo suceda y el equipo puede realizar cambios vastos y generales, si fuera necesario.
Eso me lleva a la salvedad. CTP no está listo para producción. Sí, posiblemente Windows PowerShell™ 2.0 CTP2 es uno de los fragmentos más estables de versión preliminar de código que haya visto, pero tenga en cuenta que es posible que la próxima entrega de CTP sea una aplicación totalmente distinta. Así que no debe comenzar a depender de CTP2, porque en la próxima versión puede ser necesario que comience todo de nuevo.
Tenga en cuenta que CTP no se puede instalar en paralelo con Windows PowerShell 1.0. Para obtener una instalación ideal, en el sistema también se debe instalar Microsoft® .NET Framework 3.5 para habilitar todas las características disponibles. De lo contrario, algunas características estarán limitadas.
Además, como CTP es código muy temprano, Microsoft ha puesto hasta ahora un mayor énfasis en el funcionamiento de la aplicación en los sistemas operativos más recientes, es decir, Windows Vista® y Windows Server® 2008. La compatibilidad del sistema operativo actual no es una indicación de la que se puede esperar en la versión final del código. La migración a sistemas operativos anteriores recibe atención en un momento posterior del ciclo de desarrollo.
Dos tipos de comunicación remota
En el mundo de la administración remota, generalmente puede encontrar dos tipos de comunicación remota: convergente y ramificada. La comunicación remota convergente abarca a múltiples administradores que realizan conexiones de shell seguras a un solo servidor. Windows PowerShell está diseñado para habilitar esta funcionalidad de una manera segura y con particiones de modo que una empresa de hospedaje de Exchange Server, por ejemplo, pueda ofrecer a sus clientes acceso administrativo a sus partes de un servidor. Con la comunicación remota convergente, se obtiene un acceso seguro, remoto e interactivo a la copia de Windows PowerShell (sólo en la versión 2.0) instalada en un servidor remoto.
La comunicación remota ramificada se produce al enviar un conjunto de comandos a un grupo completo de servidores remotos a la vez. Los comandos "se ramifican" desde la estación de trabajo al grupo de servidores en paralelo. Los comandos se ejecutan en cada servidor, y los resultados, en forma de objetos de Windows PowerShell, se devuelven a la estación de trabajo para poder revisarlos y trabajar con ellos. Windows PowerShell es compatible con dos tecnologías principales para comunicación remota ramificada: Instrumental de administración de Windows® (WMI) y Administración remota de Windows (WinRM), que se suministró por primera vez con Windows Server 2008 y se actualizó más tarde en la versión de CTP de Windows PowerShell 2.0.
Sincrónico frente a asincrónico
En realidad, incluso Windows PowerShell 1.0 tenía algunas capacidades ramificadas básicas vinculadas a WMI. Por ejemplo, se podía crear fácilmente una matriz de nombres de equipo y posteriormente recuperar una clase WMI de cada uno:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem
–computer $names
Los métodos de ejecución, por ejemplo el reinicio de un equipo, necesitaban algo más de trabajo debido a que la versión 1.0 no ofrecía una forma masiva de ejecutar los métodos WMI. Sin embargo, en la versión 2.0 de CTP esto ha cambiado gracias al cmdlet Invoke-WmiMethod:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem –computer $names | `
Invoke-WmiMethod Reboot
No obstante, esta técnica presenta un problema. Es sincrónica, lo que significa que se pone en contacto con cada equipo de uno en uno, y hay que esperar a que cada uno termine antes de poder ejecutar otros comandos. Pero CTP introduce un nuevo concepto: trabajos en segundo plano, lo que permite que comandos de este tipo se ejecuten en segundo plano. Para simplificar, se puede hacer que un comando WMI se ejecute en segundo plano simplemente con agregar el parámetro -AsJob:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem –computer $names -asjob
Se puede revisar el estado del trabajo resultante ejecutando Get-PSJob y los resultados finales del trabajo se pueden ver ejecutando Receive-PSJob. (Analizaré con más profundidad los detalles subyacentes a la administración de trabajos en una futura columna). Sin embargo, el cmdlet Invoke-Command ofrece un medio todavía mejor para ejecutar comandos en segundo plano, tal como:
$command = { Get-WmiObject Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command –computer $names –asjob
En realidad envía el comando Get-WmiObject a cada equipo especificado y, a continuación, lo ejecuta de forma local. Normalmente se ejecuta mucho más rápido y sin tener que depender de las conexiones de llamadas a procedimiento remoto (RPC) de WMI. En vez de eso, Invoke-Command emplea WinRM, que de forma predeterminada usa los puertos 80 o 443. Estos puertos facilitan la navegación por los firewalls y es totalmente configurable. Invoke-Command también es compatible con parámetros adicionales alternativos para credenciales y limitación de peticiones, que permiten dirigirse a cientos de equipos pero sólo tener unos cuantos ejecutándose en paralelo. Esto permite evitar la congestión y las sobrecargas en exceso.
Espacios de ejecución reutilizables
Si se planea administrar más de una vez de forma remota un conjunto de equipos determinado, se debe considerar el uso de espacios de ejecución en lugar de listas simples de nombres de equipo. En Windows PowerShell, un espacio de ejecución es simplemente una instancia del motor del shell, tanto si se ejecuta de forma local en el equipo como ventana de la consola del shell, como si lo hace en segundo plano en un equipo remoto. Iniciar un espacio de ejecución remoto es fácil:
$names = @("server1","server2","server2")
New-RunSpace –computer $names
Como los espacios de ejecución también usan WinRM, usan el puerto 80 (o el puerto 443, si especifica el parámetro -UseSSL) de forma predeterminada. También pueden aceptar credenciales alternativas, etc. Si se recuperan los objetos resultantes de espacios de ejecución, se pueden pasar a Invoke-Command, y Windows PowerShell enviará el comando a los equipos en los que existen esos espacios de ejecución:
$command = { Get-WmiObject Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command –runspace $rs –asjob
Aquí la ventaja consiste en que los espacios de ejecución permanecen activos mientras el shell está abierto, de modo que se pueden volver a usar para comandos adicionales.
Comunicación remota convergente
Los espacios de ejecución son también la clave para la comunicación remota convergente. Por ejemplo, la figura 1 muestra un espacio de ejecución que he creado en un equipo remoto; recupero una referencia a ese espacio de ejecución y, a continuación, uso el cmdlet Push-Runspace para activarlo. En ese momento, ejecuto comandos en el equipo remoto, de un modo similar al que permitirían SSH u otras utilidades remotas del shell. La ejecución de Pop-Runspace devuelve el espacio de ejecución "local" original, y el mensaje del shell ayuda a realizar un seguimiento del lugar en que me encuentro en un momento dado.
Figura 1 Uso de un espacio de ejecución para ejecutar comandos en un equipo remoto (haga clic en la imagen para ampliarla)
La secuencia exacta de comandos que ejecuto es la siguiente:
PS C:\>new-runspace -computer "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32> pop-runspace
PS C:\>
Esta técnica es denomina convergente porque múltiples administradores pueden abrir espacios de ejecución interactivos remotos en el mismo servidor al mismo tiempo: ellos "convergen" desde sus estaciones de trabajo individuales al servidor. Un nuevo modelo de seguridad en Windows PowerShell 2.0 permite crear shells y cmdlets restringidos, para evitar que cada administrador realice modificaciones globales. Cada uno está limitado a su propia área del shell. (Estas nuevas técnicas de seguridad requieren desarrollos personalizados de software en un lenguaje orientado a .NET Framework. Este aspecto supera el ámbito de la columna de Windows PowerShell, pero es interesante saber que estas capacidades existen).
La aplicación rompedora en la versión 2.0
La versión de CTP de Windows PowerShell 2.0 tiene una lista espectacular de características nuevas. En mi opinión, la comunicación remota es la aplicación rompedora. Puede beneficiar a cada administrador en prácticamente cualquier entorno.
Debe familiarizarse con estas características para poder ofrecer sus sugerencias al equipo de producto. ¿Desea que los puertos predeterminados de WinRM se administren a través de directivas de grupo? ¿Los cmdlets deben funcionar de un modo diferente? ¿Hay problemas de rendimiento? ¿WinRM resulta fácil de configurar? Puede tener repercusión si envía las sugerencias a connect.microsoft.com o comparte sus comentarios con destinatarios reconocidos con el premio MVP, entre los que me incluyo (para ponerse en contacto conmigo, publique sus comentarios en los foros en ScriptingAnswers.com). ¡Participe y ayude a crear la aplicación rompedora de la próxima generación de Windows PowerShell!
Cmdlet del mes Select-Object
Pruébelo: Get-Service | ConvertTo-HTML | Out-File Servicios.htm. Ahora consulte en su explorador web el archivo HTML resultante. Hay bastante información, ¿no es cierto? Ojalá hubiera una manera de reducirla un poco y seleccionar la información de interés. Precisamente estas son las capacidades de Select-Object. Por ejemplo, digamos que sólo desea una lista de nombres de servicio y sus estados actuales. Puede usar: Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Servicios.htm.
No obstante, algo que debe recordar es que Select-Object descarta el objeto original, en este caso, los servicios, y produce un objeto personalizado (literalmente, un tipo de objeto PSCustom) que sólo contiene las propiedades que ha especificado. Cualquier funcionalidad del objeto original deja de estar accesible, por lo que es probable que desee ubicar Select-Object cerca del final de la canalización y trabajar con el objeto original mientras sea posible.
Don Jones es coautor de Windows PowerShell v2.0: TFM y entrenador a cargo del aprendizaje en aula "Fuerzas especiales" de ScriptingAnswers.com (scriptinganswers.com/training.asp). Puede ponerse en contacto con él en la dirección jeepdon@mac.com.
© 2008 Microsoft Corporation y CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.