Windows PowerShell 2.0 introdujo una nueva y potente tecnología, la comunicación remota, que se perfeccionó y amplió para PowerShell 3.0. Basado principalmente en protocolos y técnicas estandarizados, la comunicación remota es posiblemente uno de los aspectos más importantes de PowerShell: los futuros productos de Microsoft dependerán de ella casi por completo para las comunicaciones administrativas a través de una red.,
desafortunadamente, la comunicación remota también es un conjunto complejo de componentes, y aunque Microsoft ha intentado proporcionar una guía sólida para usarlo en una variedad de escenarios, muchos administradores todavía tienen problemas con él. Este «mini libro electrónico» está diseñado para ayudarlo a comprender mejor qué es la comunicación remota, cómo funciona y, lo más importante, cómo usarla en una variedad de situaciones diferentes.
Nota Esta guía no pretende reemplazar la gran cantidad de libros existentes que cubren aspectos básicos de la comunicación remota, como el propio Learn Windows PowerShell de Don en un mes de almuerzos ( http://MoreLunches.com) o PowerShell en profundidad., En su lugar, esta guía los complementa proporcionando instrucciones paso a paso para muchos de los casos de «borde» en la comunicación remota, y explicando algunos de los comportamientos y requisitos de comunicación remota más inusuales.
en esencia, la comunicación remota le permite acceder a máquinas remotas a través de una red y recuperar datos o ejecutar código en uno o varios equipos remotos. Esta no es una idea nueva, y en el pasado han evolucionado varias tecnologías remotas diferentes. Algunos cmdlets tradicionalmente han proporcionado sus propias capacidades de comunicación remota limitadas, mientras que la mayoría de los cmdlets no admiten la comunicación remota por sí solos.,
con la comunicación remota de PowerShell, finalmente hay un entorno de comunicación remota genérico que permite la ejecución remota de literalmente cualquier comando que se pueda ejecutar en un PowerShell local. Por lo tanto, en lugar de agregar capacidades de comunicación remota a cada cmdlet y aplicación, solo tiene que dejar que PowerShell transfiera el código de PowerShell a los equipos de destino, lo ejecute allí y, a continuación, le devuelva los resultados.
a lo largo de este eBook, nos centraremos en la comunicación remota de PowerShell y no cubriremos las capacidades de comunicación remota privada no estándar integradas en cmdlets seleccionados.,
al examinar la arquitectura remota
como se muestra en la Figura 1.1, la arquitectura remota genérica de PowerShell consta de numerosos componentes y elementos diferentes e interrelacionados.
Figura 1.1: los elementos y componentes de PowerShell Remoting
Aquí está la lista completa:
■ en la parte inferior de la figura está su equipo, o más adecuadamente su cliente., Aquí es donde te sientas físicamente, y es donde iniciarás la mayoría de tus actividades remotas.
■ su ordenador se comunicará a través del protocolo WS-MAN, o Web Services for Management. Este es un protocolo basado en HTTP(S) que puede encapsular una variedad de comunicaciones diferentes. Hemos ilustrado esto como el uso de HTTP, que es la configuración predeterminada de Remoting, pero podría ser fácilmente HTTPS.
■ en el equipo remoto, en la terminología adecuada del servidor (que no se refiere al sistema operativo), se ejecuta el servicio de administración remota de Windows (WinRM)., Este servicio está configurado para tener uno o más oyentes. Cada receptor espera el tráfico WS-MAN entrante en un puerto específico, cada uno vinculado a un protocolo específico (HTTP o HTTPS) y en direcciones IP específicas (o todas las direcciones locales).
■ Cuando un receptor recibe tráfico, el servicio WinRM busca para qué extremo está destinado el tráfico. Para nuestros propósitos, un endpoint generalmente lanzará una instancia de Windows PowerShell. En términos de PowerShell, un extremo también se denomina configuración de sesión., Esto se debe a que, además de iniciar PowerShell, puede cargar automáticamente scripts y módulos, imponer restricciones a lo que puede hacer el usuario que se conecta y aplicar configuraciones específicas de sesión adicionales no mencionadas aquí.
Nota Aunque mostramos PowerShell.exe en nuestro diagrama, eso es para fines ilustrativos. PowerShell.exe es la aplicación de Consola de PowerShell, y no tendría sentido que se ejecutara como un proceso en segundo plano en un equipo remoto. El proceso real se llama Wsmprovhost.exe, que aloja PowerShell en segundo plano para conexiones remotas.,
como puede ver, un solo equipo remoto puede tener fácilmente docenas o incluso cientos de endpoints, cada uno con una configuración diferente. PowerShell 3.0 configura tres de estos extremos de forma predeterminada: uno para PowerShell de 32 bits (en sistemas de 64 bits), el extremo de PowerShell predeterminado (que es de 64 bits en sistemas x64) y uno para PowerShell Workflow. A partir de Windows Server 2008 R2, hay un cuarto punto final predeterminado para las tareas de flujo de trabajo del administrador del servidor.,
habilitar la comunicación remota
La mayoría de las versiones de cliente de Windows, comenzando con Windows Vista, no habilitan las conexiones remotas entrantes de forma predeterminada. Las versiones más recientes de Windows Server lo hacen, pero las versiones anteriores pueden no hacerlo. Por lo tanto, su primer paso con la comunicación remota generalmente será habilitarla en aquellos equipos en los que desea recibir conexiones entrantes. Hay tres formas de habilitar la comunicación remota, y la tabla 1.1 compara lo que se puede lograr con cada una de ellas.
Cuadro 1.,1 Comparing the ways of enabling remoting
|
Enable-PSRemoting |
Group Policy |
Manually Step-by-Step |
|||
|
Set WinRM to auto-start and start the service |
Yes |
Yes |
Yes – use Set-Service and Start-Service., |
No |
Yes – use PSSessionConfiguration cmdlets |
|
Configure Windows Firewall exception |
Yes* |
Yes* |
Yes* – use Firewall cmdlets or Windows Firewall GUI |
Note Existing client versions of Windows, such as Windows Vista, do not permit firewall exceptions on any network identified as «Public»., Las redes deben ser «Home» o «Work/Domain» para permitir excepciones. En PowerShell 3.0, puede ejecutar Enable-PSRemoting con el conmutador-SkipNetworkProfileCheck para evitar este problema.
habilitaremos la comunicación remota en nuestro entorno de prueba ejecutando Enable-PSRemoting. Es rápido, fácil y completo; también verá la mayoría de las tareas manuales realizadas en las próximas secciones.
entorno de prueba
usaremos un entorno de prueba consistente en las siguientes secciones; esto se creó en seis máquinas virtuales en CloudShare.,com, y está configurado como se muestra en la figura 1.2.
la Figura 1.2: entorno de Prueba de configuración
Algunas notas importantes:
■ .NET Framework v4 y PowerShell 3.0 está instalado en todos los equipos. La mayor parte de lo que cubriremos también se aplica a PowerShell 2.0.,
■ como se muestra, la mayoría de los equipos tienen un nombre de equipo numérico (C2108222963, etc.); el controlador de dominio para cada dominio (que también es un servidor DNS) tiene registros CNAME con nombres más fáciles de recordar.
■ cada controlador de dominio tiene un reenviador condicional configurado para el otro dominio, de modo que las máquinas de cualquiera de los dominios pueden resolver los nombres de los equipos en el otro dominio.
■ realizamos todas las tareas como miembro del grupo Administradores de dominio, a menos que se indique lo contrario.
■ creamos un sexto servidor completamente independiente que no está en ningún dominio., Esto será útil para cubrir algunas de las situaciones que no son de dominio en las que puede encontrarse con la comunicación remota.
precaución al abrir PowerShell en un equipo que tenga habilitado el Control de cuentas de usuario (UAC), asegúrese de hacer clic con el botón secundario en el icono de PowerShell y seleccione Ejecutar como administrador. Si la barra de título de la ventana de PowerShell resultante no comienza con administrador: entonces no tiene privilegios administrativos. Puede comprobar los permisos mediante programación con esto (whoami / all / select-string s-1-16-12288) – ne from null desde la consola de PowerShell., En un shell elevado se devuelve True, de lo contrario se devuelve False.
habilitar la comunicación remota
comenzamos ejecutando Enable-PSRemoting en los seis equipos. Tomamos cuidado para asegurarse de que el comando se ejecutó sin errores; errores en este punto son una señal de que debe detener y resolver el error antes de intentar continuar. La figura 1.3 muestra el producto esperado.
la Figura 1.,3: salida esperada de Enable-PSRemoting
Nota: notará el uso derrochador de capturas de pantalla a lo largo de esta guía. Ayuda a garantizar que no cometo errores tipográficos o de copiar / pegar, ya que estás viendo exactamente lo que escribimos y ejecutamos.
la ejecución de Get-PSSessionConfiguration debería revelar los tres o cuatro puntos finales creados por Enable-PSRemoting. La figura 1.4 muestra la salida esperada en un servidor.
la Figura 1.,4: salida esperada de Get-PSSessionConfiguration
Nota: La Figura 1.4 ilustra que puede esperar que se configuren diferentes puntos finales en diferentes máquinas. Este ejemplo provenía de un equipo con Windows Server 2008 R2, que tiene menos puntos finales que un equipo con Windows 2012.
vale la pena tomarse un momento para probar rápidamente la configuración remota. Para los equipos que forman parte del mismo dominio, cuando haya iniciado sesión como Administrador de dominio desde ese dominio, la comunicación remota debería «funcionar».»Compruébelo rápidamente intentando remotearlo de un equipo a otro usando Enter-PSSession.,
Nota: en otros entornos, una cuenta de administrador de dominio puede no ser la única cuenta que puede usar la comunicación remota. Si su entorno doméstico o de trabajo tiene cuentas adicionales en el grupo Administradores local como estándar en su dominio, también podrá usar estas cuentas para la comunicación remota.
La Figura 1.5 muestra la salida esperada, en la que también ejecutamos un comando de directorio rápido y luego salimos de la sesión remota.
la Figura 1.5: Comprobación de conectividad remota de la COMPAÑÍA.cliente de loc al controlador de dominio DCA.
precaución: si está siguiendo en su propio entorno de prueba, no continúe hasta que haya confirmado la conectividad remota entre dos equipos en el mismo dominio. Ningún otro escenario necesita funcionar en este momento; llegaremos a ellos en las próximas secciones.
tareas principales de comunicación remota
PowerShell proporciona dos casos de Uso Principales de comunicación remota., El PRIMERO, 1-TO-1 Remoting, es similar en naturaleza al SSH secure shell ofrecido en sistemas UNIX y Linux. Con él, se obtiene un símbolo del sistema de línea de comandos en un solo equipo remoto. La segunda, la comunicación remota de 1 a muchos, le permite enviar un comando (o una lista de comandos) en paralelo a un conjunto de equipos remotos. También hay un par de técnicas secundarias útiles que veremos.
1-to-1 Remoting
El comando Enter-PSSession se conecta a un equipo remoto y le proporciona un mensaje de línea de comandos en ese equipo., Puede ejecutar los comandos que estén en ese equipo, siempre que tenga permiso para realizar esa tarea. Tenga en cuenta que no está creando una sesión de inicio de sesión interactiva; su conexión se auditará como un inicio de sesión de red, al igual que si se conectara al recurso compartido C administrative administrative del equipo. PowerShell no cargará ni procesará scripts de perfil en el equipo remoto. Cualquier script que elija Ejecutar (y esto incluye la importación de Módulos de script) solo funcionará si la directiva de ejecución del equipo remoto lo permite.,
Enter-PSSession -computerName DC01
Nota: si está conectado a una máquina remota a través de se han agregado, su símbolo de los cambios y muestra el nombre del sistema remoto entre corchetes. Si ha personalizado su solicitud, todas las personalizaciones se perderán porque la solicitud ahora se crea en el sistema remoto y se transfiere de nuevo a usted. Toda la entrada del teclado interactivo se envía a la máquina remota y todos los resultados se envían de vuelta a usted. Es importante tener en cuenta esto porque no puede usar Enter-PSSession en un script., Si lo hiciera, el script seguiría ejecutándose en su máquina local ya que no se introdujo ningún código de forma interactiva.
comunicación remota de 1 a muchos
Con esta técnica, se especifican uno o varios nombres de equipo y un comando (o una lista de comandos separados por punto y coma); PowerShell envía los comandos, a través de comunicación remota, a los equipos especificados. Esos equipos ejecutan los comandos, serializan los resultados en XML y le transmiten los resultados. El equipo vuelve a deserializar el XML en objetos y los coloca en la canalización de la sesión de PowerShell., Esto se logra mediante el cmdlet Invoke-Command.
Invoke-Command -computername DC01,CLIENT1 -scriptBlock { Get-Service }
Si tiene un script de comandos para ejecutar, puede hacer que Invoke-Command lo lea, transmita el contenido a los equipos remotos y haga que ejecuten esos comandos.
Invoke-Command -computername DC01,CLIENT1 -filePath c:\Scripts\Task.ps1
tenga en cuenta que Invocar el Comando por defecto, comunicarse con sólo 32 equipos a la vez. Si especifica más, los extras se pondrán en cola y Invoke-Command comenzará a procesarlos a medida que finalice los primeros 32., El parámetro-ThrottleLimit puede aumentar este límite; el único costo es para el equipo, que debe tener recursos suficientes para mantener una sesión única de PowerShell para cada equipo con el que se está contactando simultáneamente. Si espera recibir grandes cantidades de datos de los equipos remotos, el ancho de banda de red disponible puede ser otro factor limitante.,
Sessions
cuando ejecuta Enter-PSSession o Invoke-Command y utiliza su parámetro-ComputerName, la comunicación remota crea una conexión (o sesión), hace lo que le haya pedido y, a continuación, cierra la conexión (en el caso de una sesión interactiva creada con Enter-PSSession, PowerShell sabe que ha terminado cuando ejecuta Exit-PSSession). Hay cierta sobrecarga involucrada en esa configuración y desmontaje, por lo que PowerShell también ofrece la opción de crear una conexión persistente, llamada PSSession. Ejecute New-PSSession para crear una sesión nueva y persistente., A continuación, en lugar de usar-ComputerName con Enter-PSSession o Invoke-Command, utilice su parámetro-Session y pase un objeto PSSession abierto existente. Eso permite que los comandos reutilicen la conexión persistente que había creado anteriormente.
Cuando utiliza el parámetro-ComputerName y trabaja con sesiones ad-hoc, cada vez que envía un comando a una máquina remota, hay un retraso significativo causado por la sobrecarga que se necesita para crear una nueva sesión. Dado que cada llamada a Enter-PSSession o Invoke-Command configura una nueva sesión, tampoco puede conservar el estado., En el siguiente ejemplo, la variable test test se pierde en la segunda llamada:
cuando se usan sesiones persistentes, por otro lado, las re-conexiones son mucho más rápidas, y como se mantienen y reutilizan las sesiones, conservarán el estado., Así que aquí, la segunda llamada a Invoke-Command todavía podrá acceder a la variable test test que se configuró en la primera llamada
Existen varios otros comandos para comprobar el estado de la sesión y recuperar sesiones (Get-PSSession), cerrarlas (Remove-PSSession), desconectarlas y reconectarlas (Disconnect-PSSession y Reconnect-PSSession, que son nuevas en PowerShell v3), y así sucesivamente., En PowerShell v3, también puede pasar una sesión abierta a Get-Module E Import-Module, lo que le permite ver los módulos enumerados en un equipo remoto (a través de la PSSession abierta) o importar un módulo desde un equipo remoto al equipo para la comunicación remota implícita. Revise la ayuda de esos comandos para obtener más información.
Nota: Una vez que use New-PSSession y cree sus propias sesiones persistentes, es su responsabilidad hacer la limpieza y cerrar y eliminar la sesión cuando haya terminado con ellas., Hasta que no lo haga, las sesiones persistentes permanecen activas, consumen recursos y pueden impedir que otros se conecten. De forma predeterminada, solo se permiten 10 conexiones simultáneas a una máquina remota. Si mantiene demasiadas sesiones activas, se encontrará fácilmente con límites de recursos. Esta línea muestra lo que sucede si se intenta establecer demasiadas sesiones simultáneas:
PS> 1..10 | Foreach-Object { New-PSSession -ComputerName CLIENT1 }
Remoting Devuelve Deserializar Datos
Los resultados que usted recibe de un equipo remoto ha sido serializado en XML y, a continuación, deserializa en su ordenador., En esencia, los objetos colocados en la canalización de su shell son instantáneas estáticas e independientes de lo que estaba en el equipo remoto en el momento en que completó su comando. Estos objetos deserializados carecen de los métodos de los objetos originales, y en su lugar solo ofrecen propiedades estáticas.
si necesita acceder a métodos o cambiar propiedades, o en otras palabras, si debe trabajar con los objetos en vivo, simplemente asegúrese de hacerlo en el lado remoto, antes de que los objetos se serialicen y viajen de regreso al autor de la llamada., Este ejemplo utiliza métodos de objeto en el lado remoto para determinar los propietarios de procesos que funcionan bien:
una vez que los resultados viajan de vuelta a usted, ya no puede invocar métodos de objeto porque ahora trabaja con objetos «rehidratados» que están separados de los objetos vivos y ya no contienen ningún método:
serializar y deserializar es relativamente caro. Puede optimizar la velocidad y los recursos asegurándose de que su código remoto emita solo los datos que realmente necesita., Por ejemplo, podría usar Select-Object y elegir cuidadosamente las propiedades que desea recuperar en lugar de serializar y deserializar todo.
Enter-PSSession vs. Invoke-Command
muchos recién llegados se confundirán un poco sobre la comunicación remota, en parte debido a cómo PowerShell ejecuta los scripts. Considere lo siguiente y asuma que SERVER2 contiene un script llamado C:\RemoteTest.,ps1:
Enter-PSSession -ComputerName SERVER2C:\RemoteTest.ps1
Si tuviera que sentarse y escribir estos comandos de forma interactiva en la ventana de la consola en su equipo cliente, esto funcionaría (suponiendo que la comunicación remota esté configurada, tenga permisos y todo eso). Sin embargo, si pegaras estos en un script y ejecutaras ese script, no funcionaría. El script intentaría ejecutar C:\RemoteTest.ps1 en su computadora local.
el resultado práctico de esto es que Enter-PSSession está realmente destinado para uso interactivo por un ser humano, no para uso por lotes por un script., Si desea enviar un comando a un equipo remoto, desde un script, Invoke-Command es la forma correcta de hacerlo. Puede configurar una sesión por adelantado (útil si planea enviar más de un comando) o puede usar un nombre de equipo si solo desea enviar un solo comando. Por ejemplo:
$session = New-PSSession -ComputerName SERVER2Invoke-Command -session $session -ScriptBlock { C:\RemoteTest.ps1 }
Obviamente, tendrás que utilizar algo de cautela. Si esas fueran las únicas dos líneas en el script, entonces cuando el script terminara de ejecutarse ,session session dejaría de existir., Eso podría desconectarlo (en cierto sentido) de la sesión que se ejecuta en el servidor 2. Lo que haces, e incluso si necesitas preocuparte por ello, depende mucho de lo que estés haciendo y de cómo lo estés haciendo. En este ejemplo, probablemente todo estaría bien, porque Invoke-Command «mantendría» el script local ejecutándose hasta que el script remoto terminara y devolviera su salida (si la hubiera).
