Windows PowerShell: Comunicación remota implícita

  • Artículo

Don Jones

Hay una característica poco conocida en Windows PowerShell 2.0, que puede agregar fácilmente una cantidad increíble de flexibilidad para su entorno. Imagine que los equipos cliente ejecutan principalmente Windows XP, aún un escenario común suficientemente. Los controladores de dominio están utilizando Windows Server 2003.

Puede obtener Windows PowerShell 2.0 para ambos de estos sistemas operativos, pero es posible que no pueda utilizar algunos de los módulos de cmdlet más recientes de Windows PowerShell, al igual que el módulo de Active Directory incluida con R2 de Windows Server 2008. Estos módulos no se ejecutarán en versiones anteriores de Windows.

No es ningún problema. Sólo tiene que instalar Windows 7 o Windows Server 2008 R2 en un equipo en su entorno (el módulo de Active Directory se ejecutará en uno de estos). Por ejemplo, se puede instalar un único controlador de dominio de Windows Server 2008 R2, ya proporcionan con el módulo de Active Directory y el servicio de puerta de enlace de administración de Active Directory con el que se comunica el módulo. Descargue el servicio de puerta de enlace y se instala en Windows Server 2008 y Windows Server 2003.

Habilitar acceso remoto y WinRM en ese controlador de dominio nuevo ejecutando de Enable-PSRemoting en Windows PowerShell. A continuación, activar Windows PowerShell 2.0 en el equipo de cliente de Windows XP y estar preparado para realizar algunas arte de magia.

Hacer que un módulo

Si se inician estableciendo una sesión de acceso remoto para el nuevo controlador de dominio:

$session = New-PSSession -computerName my-new-dc

Proporcionar el nombre de equipo correcto en lugar de “ my-nuevo-dc, ” supuesto. Puede especificar parámetros adicionales, como, por ejemplo, credenciales alternativas o de otros puertos de WinRM. Ejecutar Ayuda nuevo-pssession para obtener más información.

A continuación, indicar a esa instancia remota de Windows PowerShell para cargar los cmdlets de Active Directory:

Invoke-command { import-module activedirectory } -session $session

Ésta es la parte interesante: Tiene a su instancia local de Windows PowerShell exportar los cmdlets de Active Directory de la sesión en un módulo local del equipo cliente:

Export-PSSession -session $session -commandname *-AD* -outputmodule RemAD -allowclobber

Este comando crea un nuevo módulo de Windows PowerShell, que se almacenan en la carpeta documentos en WindowsPowerShell\Modules\RemAD. Sólo los cmdlets cuyos nombres coinciden con el modelo “ *-AD * ” se va a incluir. Como parte del nombre del cmdlet en el es una de las razones más importantes, mayoría de los cmdlets de complemento, utilizar algún tipo de prefijo como “ AD ”. Este modo, más fácil de obtener sólo los cmdlets.

Los cmdlets realmente no se copian al equipo local. En su lugar, el módulo creado de forma local actúa como un tipo de método abreviado. Los cmdlets siempre se ejecutará en el controlador de dominio remoto, pero los cmdlets se parece ejecutarse localmente.

Usar los Cmdlets

Inicie la eliminación de esa sesión en el controlador de dominio remoto:

Remove-PSSession -session $session

Cargar ahora el nuevo módulo:

Import-Module RemAD -prefix Rem

Este comando carga el nuevo módulo en la memoria y agrega un prefijo “ REM ” al nombre de cada cmdlet del módulo. El prefijo es una buena manera de recordar que estos cmdlets se van a ejecutar remotamente. Puede elegir cualquier prefijo que se desee, pero suele usar algo como “ R ” o “ REM ” reposar “ Remote. ”

Intente solicitar ayuda sobre un cmdlet remoto:

Help New-RemADUser

Verá un error, porque no se establece una sesión de acceso remoto actual entre el equipo y el controlador de dominio donde vive estos cmdlets. No es necesario iniciar la sesión de forma explícita. Es posible implícitamente para ello, intente ejecutar uno de los cmdlets de acceso remotos:

Get-RemADUser -filter "Name -like 'D*'"

Esto se re-instantiate la conexión remota con el controlador de dominio, enviar el comando de ejecución y ejecutar el comando en el controlador de dominio. A continuación, todos los usuarios cuyo nombre comience por “ D ” se serializa en XML y se transmiten a través de la red al equipo. No existe estén deserializados en objetos que puede trabajar en la canalización de Windows PowerShell. Ahora puede solicitar ayuda porque la sesión remota activa:

Help New-RemADUser

La sesión permanece activa hasta que se cierre la instancia del shell o se quita el módulo:

Remove-Module RemAD

Llegar a fuera y administrar algo

Implícita de interacción remota resulta más fácil de usar los cmdlets que sólo están disponibles en un equipo remoto. Los cmdlets implícitamente acceso remotos comportan prácticamente la misma manera que si se han instalado localmente. Esto los hace disponibles cada vez que necesite. La sesión de interacción remota requiere poca sobrecarga en el equipo o en el equipo remoto, por lo que se trata de una forma práctica extraordinariamente para distribuir la informática.

Don Jones *is a founder of Concentrated Technology, and answers questions about Windows PowerShell and other technologies at ConcentratedTech.com.*También es autor de de Nexus.Realtimepublishers.com , lo que muchos de sus libros disponibles como ediciones electrónicas libres.

Contenido relacionado