Al trabajar de forma remota, escriba comandos en PowerShell en un equipo (conocido como "equipo local"), pero los comandos se ejecutan en otro equipo (conocido como "equipo remoto"). La experiencia de trabajar de forma remota debe ser lo más parecido a trabajar directamente en el equipo remoto como sea posible.
Nota:
Para usar la comunicación remota de PowerShell, el equipo remoto debe configurarse para la comunicación remota. Para obtener más información, consulte about_Remote_Requirements.
¿Deben tener instalados ambos equipos PowerShell?
Sí. Para trabajar de forma remota, los equipos locales y remotos deben tener PowerShell, Microsoft .NET Framework y el protocolo Web Services for Management (WS-Management). Los archivos y otros recursos necesarios para ejecutar un comando determinado deben estar en el equipo remoto.
Los equipos que ejecutan Windows PowerShell 3.0 y los equipos que ejecutan Windows PowerShell 2.0 pueden conectarse entre sí de forma remota y ejecutar comandos remotos. Sin embargo, algunas características, como la capacidad de desconectar de una sesión y volver a conectarse a ella, solo funcionan cuando ambos equipos ejecutan Windows PowerShell 3.0.
Debe tener permiso para conectarse al equipo remoto, el permiso para ejecutar PowerShell y el permiso para acceder a almacenes de datos (como archivos y carpetas) y el registro en el equipo remoto.
Para obtener más información, consulte about_Remote_Requirements.
¿Cómo funciona la comunicación remota?
Al enviar un comando remoto, el comando se transmite a través de la red al motor de PowerShell en el equipo remoto y se ejecuta en el cliente de PowerShell en el equipo remoto. Los resultados del comando se devuelven al equipo local y aparecen en la sesión de PowerShell en el equipo local.
Para transmitir los comandos y recibir la salida, PowerShell usa el protocolo WS-Management. Para obtener información sobre el protocolo WS-Management, vea Protocolo WS-Management en la documentación de Windows.
A partir de Windows PowerShell 3.0, las sesiones remotas se almacenan en el equipo remoto. Esto le permite desconectar de la sesión y volver a conectarse desde una sesión diferente o desde otro equipo sin interrumpir los comandos ni perder el estado.
¿Es seguro la comunicación remota de PowerShell?
Cuando se conecta a un equipo remoto, el sistema usa las credenciales de nombre de usuario y contraseña en el equipo local o las credenciales que proporcione en el comando para iniciar sesión en el equipo remoto. Las credenciales y el resto de la transmisión se cifran.
Para agregar protección adicional, puede configurar el equipo remoto para que use Capa de sockets seguros (SSL) en lugar de HTTP para escuchar las solicitudes de Administración remota de Windows (WinRM).
A continuación, los usuarios pueden usar el parámetro UseSSL de los cmdlets Invoke-Command, New-PSSession y Enter-PSSession al establecer una conexión. Esta opción usa el canal HTTPS más seguro en lugar de HTTP.
¿Requieren todos los comandos remotos la comunicación remota de PowerShell?
No. Algunos cmdlets tienen un parámetro ComputerName que permite obtener objetos del equipo remoto.
Estos cmdlets no usan la comunicación remota de PowerShell. Por lo tanto, puede usarlos en cualquier equipo que ejecute PowerShell, incluso si el equipo no está configurado para la comunicación remota de PowerShell o si el equipo no cumple los requisitos para la comunicación remota de PowerShell.
Estos cmdlets incluyen lo siguiente:
Get-HotfixRename-ComputerRestart-ComputerStop-Computer
Para buscar todos los cmdlets con un parámetro ComputerName, escriba:
Get-Help * -Parameter ComputerName
# or
Get-Command -ParameterName ComputerName
Para determinar si el parámetro ComputerName de un cmdlet determinado requiere comunicación remota de PowerShell, consulte la descripción del parámetro. Para mostrar la descripción del parámetro, escriba:
Get-Help <cmdlet-name> -Parameter ComputerName
Por ejemplo:
Get-Help Get-Hotfix -Parameter ComputerName
Para todos los demás comandos, use el cmdlet Invoke-Command.
¿Cómo se ejecuta un comando en un equipo remoto?
Para ejecutar un comando en un equipo remoto, use el cmdlet Invoke-Command.
Incluya el comando entre llaves ({}) para convertirlo en un bloque de script. Use el parámetro ScriptBlock de Invoke-Command para especificar el comando.
Puede usar el parámetro ComputerName de Invoke-Command para especificar un equipo remoto. O bien, puede crear una conexión persistente a un equipo remoto (una sesión) y, a continuación, usar el parámetroSesión de Invoke-Command para ejecutar el comando en la sesión.
Por ejemplo, los siguientes comandos ejecutan un comando Get-Process de forma remota.
Invoke-Command -ComputerName Server01, Server02 -ScriptBlock {Get-Process}
# - OR -
Invoke-Command -Session $s -ScriptBlock {Get-Process}
Para interrumpir un comando remoto, escriba CTRL+C. La solicitud de interrupción se pasa al equipo remoto, donde finaliza el comando remoto.
Para obtener más información sobre los comandos remotos, consulte about_Remote y los temas de Ayuda de los cmdlets que admiten la comunicación remota.
¿Puedo simplemente telnet en un equipo remoto?
Puede usar el cmdlet Enter-PSSession para iniciar una sesión interactiva con un equipo remoto.
En el símbolo del sistema de PowerShell, escriba:
Enter-PSSession <ComputerName>
El símbolo del sistema cambia para mostrar que está conectado al equipo remoto.
<ComputerName>\C:>
Ahora, los comandos que escriba se ejecutan en el equipo remoto como si se escriben directamente en el equipo remoto.
Para finalizar la sesión interactiva, escriba:
Exit-PSSession
Una sesión interactiva es una sesión persistente que usa el protocolo WS-Management. No es lo mismo que usar Telnet, pero proporciona una experiencia similar.
Para obtener más información, vea Enter-PSSession.
¿Puedo crear una conexión persistente?
Sí. Puede ejecutar comandos remotos especificando el nombre del equipo remoto, su nombre NetBIOS o su dirección IP. O bien, puede ejecutar comandos remotos especificando una sesión de PowerShell (PSSession) conectada al equipo remoto.
Cuando se usa el parámetro ComputerName de Invoke-Command o Enter-PSSession, PowerShell establece una conexión temporal. PowerShell usa la conexión para ejecutar solo el comando actual y, a continuación, cierra la conexión. Este es un método muy eficaz para ejecutar un solo comando o varios comandos no relacionados, incluso en muchos equipos remotos.
Cuando se usa el cmdlet New-PSSession para crear una PSSession, PowerShell establece una conexión persistente para PSSession. A continuación, puede ejecutar varios comandos en PSSession, incluidos los comandos que comparten datos.
Normalmente, se crea una PSSession para ejecutar una serie de comandos relacionados que comparten datos. De lo contrario, la conexión temporal creada por el parámetro ComputerName es suficiente para la mayoría de los comandos.
Para obtener más información sobre las sesiones, consulte about_PSSessions.
¿Puedo ejecutar comandos en más de un equipo a la vez?
Sí. El parámetro ComputerName del cmdlet Invoke-Command acepta varios nombres de equipo y el parámetro Sesión acepta varias PSSessions.
Al ejecutar un comando Invoke-Command, PowerShell ejecuta los comandos en todos los equipos especificados o en todas las PSSessions especificadas.
PowerShell puede administrar cientos de conexiones remotas simultáneas. Sin embargo, el número de comandos remotos que puede enviar podría estar limitado por los recursos del equipo y su capacidad para establecer y mantener varias conexiones de red.
Para obtener más información, vea el ejemplo del tema de ayuda de Invoke-Command.
¿Dónde están mis perfiles?
Los perfiles de PowerShell no se ejecutan automáticamente en sesiones remotas, por lo que los comandos que agrega el perfil no están presentes en la sesión. Además, la variable automática $profile no se rellena en sesiones remotas.
Para ejecutar un perfil en una sesión, use el cmdlet Invoke-Command.
Por ejemplo, el siguiente comando ejecuta el perfil CurrentUserCurrentHost desde el equipo local de la sesión en $s.
Invoke-Command -Session $s -FilePath $profile
El siguiente comando ejecuta el perfil CurrentUserCurrentHost desde el equipo remoto de la sesión en $s. Dado que la variable $profile no se rellena, el comando usa la ruta de acceso explícita al perfil.
Invoke-Command -Session $s {
. "$home\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1"
}
Después de ejecutar este comando, los comandos que el perfil agrega a la sesión están disponibles en $s.
También puede usar un script de inicio en una configuración de sesión para ejecutar un perfil en cada sesión remota que use la configuración de sesión.
Para obtener más información sobre los perfiles de PowerShell, consulte about_Profiles. Para obtener más información sobre las configuraciones de sesión, consulte Register-PSSessionConfiguration.
¿Cómo funciona la limitación en los comandos remotos?
Para ayudarle a administrar los recursos en el equipo local, PowerShell incluye una característica de limitación por comando que le permite limitar el número de conexiones remotas simultáneas que se establecen para cada comando.
El valor predeterminado es 32 conexiones simultáneas, pero puede usar el parámetro ThrottleLimit de los cmdlets para establecer un límite de limitación personalizado para determinados comandos.
Cuando use la característica de limitación, recuerde que se aplica a cada comando, no a toda la sesión o al equipo. Si ejecuta comandos simultáneamente en varias sesiones o PSSessions, el número de conexiones simultáneas es la suma de las conexiones simultáneas en todas las sesiones.
Para buscar cmdlets con un parámetro ThrottleLimit, escriba:
Get-Help * -Parameter ThrottleLimit
-or-
Get-Command -ParameterName ThrottleLimit
¿La salida de los comandos remotos es diferente de la salida local?
Cuando se usa PowerShell localmente, se envían y reciben objetos de .NET Framework en directo; Los objetos "activos" son objetos asociados a programas o componentes reales del sistema. Al invocar los métodos o cambiar las propiedades de los objetos dinámicos, los cambios afectan al programa o componente real. Además, cuando cambian las propiedades de un programa o componente, también cambian las propiedades del objeto que los representan.
Sin embargo, dado que la mayoría de los objetos activos no se pueden transmitir a través de la red, PowerShell "serializa" la mayoría de los objetos enviados en comandos remotos, es decir, convierte cada objeto en una serie de elementos de datos XML (Lenguaje de restricción en XML [CLiXML]) para la transmisión.
Cuando PowerShell recibe un objeto serializado, convierte el XML en un tipo de objeto deserializado. El objeto deserializado es un registro preciso de las propiedades del programa o componente en un momento anterior, pero ya no está "activo", es decir, ya no está asociado directamente con el componente. Además, los métodos se quitan porque ya no son efectivos.
Normalmente, puede usar objetos deserializados igual que usaría objetos dinámicos, pero debe tener en cuenta sus limitaciones. Además, los objetos devueltos por el cmdlet Invoke-Command tienen propiedades adicionales que le ayudan a determinar el origen del comando.
Algunos tipos de objetos, como objetos DirectoryInfo y GUID, se convierten de nuevo en objetos activos cuando se reciben. Estos objetos no necesitan ningún control o formato especiales.
Para obtener información sobre cómo interpretar y dar formato a la salida remota, consulte about_Remote_Output.
¿Puedo ejecutar trabajos en segundo plano de forma remota?
Sí. Un trabajo en segundo plano de PowerShell es un comando de PowerShell que se ejecuta de forma asincrónica sin interactuar con la sesión. Al iniciar un trabajo en segundo plano, el símbolo del sistema devuelve inmediatamente y puede continuar trabajando en la sesión mientras se ejecuta el trabajo incluso si se ejecuta durante un período de tiempo prolongado.
Puede iniciar un trabajo en segundo plano incluso mientras se ejecutan otros comandos porque los trabajos en segundo plano siempre se ejecutan de forma asincrónica en una sesión temporal.
Puede ejecutar trabajos en segundo plano en un equipo local o remoto. De forma predeterminada, un trabajo en segundo plano se ejecuta en el equipo local. Sin embargo, puede usar el parámetro AsJob del cmdlet Invoke-Command para ejecutar cualquier comando remoto como trabajo en segundo plano. Además, puede usar Invoke-Command para ejecutar un comando Start-Job de forma remota.
Para obtener más información sobre los trabajos en segundo plano en PowerShell, vea about_Jobs y about_Remote_Jobs.
¿Puedo ejecutar programas de Windows en un equipo remoto?
Puede usar comandos remotos de PowerShell para ejecutar programas basados en Windows en equipos remotos.
Por ejemplo, puede ejecutar Shutdown.exe o Ipconfig.exe en un equipo remoto.
Sin embargo, no puede usar comandos de PowerShell para abrir la interfaz de usuario de cualquier programa en un equipo remoto.
Cuando inicia un programa de Windows en un equipo remoto, el comando no se completa y el símbolo del sistema de PowerShell no vuelve, hasta que el programa haya terminado o hasta que presione CTRL+C para interrumpir el comando. Por ejemplo, si ejecuta el programa Ipconfig.exe en un equipo remoto, el símbolo del sistema no devuelve hasta que se complete Ipconfig.exe.
Si usa comandos remotos para iniciar un programa que tenga una interfaz de usuario, se inicia el proceso de programa, pero la interfaz de usuario no aparece. El comando de PowerShell no se completa y el símbolo del sistema no vuelve hasta que detenga el proceso del programa o hasta que presione CTRL+C, lo que interrumpe el comando y detiene el proceso.
Por ejemplo, si usa un comando de PowerShell para ejecutar Notepad en un equipo remoto, el proceso del Bloc de notas se inicia en el equipo remoto, pero la interfaz de usuario del Bloc de notas no aparece. Para interrumpir el comando y restaurar el símbolo del sistema, presione CTRL+C.
¿Puedo limitar los comandos que los usuarios pueden ejecutar de forma remota en mi equipo?
Sí. Cada sesión remota debe usar una de las configuraciones de sesión en el equipo remoto. Puede administrar las configuraciones de sesión en el equipo (y los permisos para esas configuraciones de sesión) para determinar quién puede ejecutar comandos de forma remota en el equipo y qué comandos pueden ejecutar.
Una configuración de sesión configura el entorno de la sesión. Puede definir la configuración mediante un ensamblado que implemente una nueva clase de configuración o mediante un script que se ejecute en la sesión. La configuración puede determinar los comandos que están disponibles en la sesión. Además, la configuración puede incluir opciones que protegen el equipo, como la configuración que limita la cantidad de datos que la sesión puede recibir de forma remota en un solo objeto o comando. También puede especificar un descriptor de seguridad que determine los permisos necesarios para usar la configuración.
El cmdlet Enable-PSRemoting crea las configuraciones de sesión predeterminadas en el equipo: Microsoft.PowerShell, Microsoft.PowerShell.Workflow y Microsoft.PowerShell32 (solo sistemas operativos de 64 bits). Enable-PSRemoting establece el descriptor de seguridad de la configuración para permitir que solo los miembros del grupo Administradores del equipo los usen.
Puede usar los cmdlets de configuración de sesión para editar las configuraciones de sesión predeterminadas, crear nuevas configuraciones de sesión y cambiar los descriptores de seguridad de todas las configuraciones de sesión.
A partir de Windows PowerShell 3.0, el cmdlet New-PSSessionConfigurationFile le permite crear configuraciones de sesión personalizadas mediante un archivo de texto. El archivo incluye opciones para establecer el modo de idioma y para especificar los cmdlets y módulos que están disponibles en las sesiones que usan la configuración de sesión.
Cuando los usuarios usan los cmdlets Invoke-Command, New-PSSession o Enter-PSSession, pueden usar el parámetro ConfigurationName para indicar la configuración de sesión que se usa para la sesión. Además, pueden cambiar la configuración predeterminada que usan sus sesiones cambiando el valor de la variable de preferencia $PSSessionConfigurationName en la sesión.
Para obtener más información sobre las configuraciones de sesión, consulte la Ayuda para los cmdlets de configuración de sesión. Para buscar los cmdlets de configuración de sesión, escriba:
Get-Command *PSSessionConfiguration
¿Qué son las configuraciones de ventilador y distribución?
El escenario de comunicación remota de PowerShell más común que implica varios equipos es la configuración de uno a varios, en la que un equipo local (el equipo del administrador) ejecuta comandos de PowerShell en numerosos equipos remotos. Esto se conoce como escenario de "distribución ramificada".
Sin embargo, en algunas empresas, la configuración es de varios a uno, donde muchos equipos cliente se conectan a un único equipo remoto que ejecuta PowerShell, como un servidor de archivos o un quiosco. Esto se conoce como la configuración de "ventilador".
La comunicación remota de PowerShell admite configuraciones de distribución ramificada y de ventilador.
Para la configuración de distribución ramificada, PowerShell usa el protocolo Web Services for Management (WS-Management) y el servicio WinRM que admite la implementación de Microsoft de WS-Management. Cuando un equipo local se conecta a un equipo remoto, WS-Management establece una conexión y usa un complemento para PowerShell para iniciar el proceso de host de PowerShell (Wsmprovhost.exe) en el equipo remoto. El usuario puede especificar un puerto alternativo, una configuración de sesión alternativa y otras características para personalizar la conexión remota.
Para admitir la configuración de "ventilador", PowerShell usa Internet Information Services (IIS) para hospedar WS-Management, cargar el complemento de PowerShell e iniciar PowerShell. En este escenario, en lugar de iniciar cada sesión de PowerShell en un proceso independiente, todas las sesiones de PowerShell se ejecutan en el mismo proceso de host.
El hospedaje de IIS y la administración remota con ventilador no se admiten en Windows XP ni en Windows Server 2003.
En una configuración de ventilador, el usuario puede especificar un URI de conexión y un punto de conexión HTTP, incluido el transporte, el nombre del equipo, el puerto y el nombre de la aplicación. IIS reenvía todas las solicitudes con un nombre de aplicación especificado a la aplicación. El valor predeterminado es WS-Management, que puede hospedar PowerShell.
También puede especificar un mecanismo de autenticación y prohibir o permitir el redireccionamiento desde puntos de conexión HTTP y HTTPS.
¿Puedo probar la comunicación remota en un solo equipo que no esté en un dominio?
Sí. La comunicación remota de PowerShell está disponible incluso cuando el equipo local no está en un dominio. Puede usar las características de comunicación remota para conectarse a sesiones y crear sesiones en el mismo equipo. Las características funcionan igual que cuando se conecta a un equipo remoto.
Para ejecutar comandos remotos en un equipo de un grupo de trabajo, cambie la siguiente configuración de Windows en el equipo.
Precaución: esta configuración afecta a todos los usuarios del sistema y puede hacer que el sistema sea más vulnerable a un ataque malintencionado. Tenga cuidado al realizar estos cambios.
Windows Vista, Windows 7, Windows 8:
Cree la siguiente entrada del Registro y establezca su valor en 1: LocalAccountTokenFilterPolicy en
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\SystemPuede usar el siguiente comando de PowerShell para agregar esta entrada:
$parameters = @{ Path='HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' Name='LocalAccountTokenFilterPolicy' propertyType='DWord' Value=1 } New-ItemProperty @parametersWindows Server 2003, Windows Server 2008, Windows Server 2012, Windows Server 2012 R2:
No se necesitan cambios porque la configuración predeterminada de la directiva "Acceso a la red: Uso compartido y seguridad para cuentas locales" es "Clásico". Compruebe la configuración en caso de que haya cambiado.
¿Puedo ejecutar comandos remotos en un equipo de otro dominio?
Sí. Normalmente, los comandos se ejecutan sin error, aunque es posible que tenga que usar el parámetro Credencial de los cmdlets Invoke-Command, New-PSSession o Enter-PSSession para proporcionar las credenciales de un miembro del grupo Administradores en el equipo remoto. Esto a veces es necesario incluso cuando el usuario actual es miembro del grupo Administradores en los equipos locales y remotos.
Sin embargo, si el equipo remoto no está en un dominio en el que confía el equipo local, es posible que el equipo remoto no pueda autenticar las credenciales del usuario.
Para habilitar la autenticación, use el siguiente comando para agregar el equipo remoto a la lista de hosts de confianza para el equipo local en WinRM. Escriba el comando en el símbolo del sistema de PowerShell.
Set-Item WSMan:\localhost\Client\TrustedHosts -Value <Remote-computer-name>
Por ejemplo, para agregar el equipo Server01 a la lista de hosts de confianza en el equipo local, escriba el siguiente comando en el símbolo del sistema de PowerShell:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value Server01
¿Admite PowerShell la comunicación remota a través de SSH?
Sí. Para obtener más información, consulte Comunicación remota de PowerShell a través de SSH.
