about_Remote_FAQ
Se aplica a: Windows PowerShell 2.0, Windows PowerShell 3.0, Windows PowerShell 4.0
TEMA
about_Remote_FAQ
DESCRIPCIÓN BREVE
Contiene preguntas y respuestas sobre cómo ejecutar comandos remotos en Windows PowerShell®.
DESCRIPCIÓN LARGA
Cuando trabaja de forma remota, escribe los comandos en Windows PowerShell en un equipo (denominado "equipo local"), pero los comandos se ejecutan en otro equipo (denominado "equipo remoto"). La experiencia de trabajar de forma remota debería parecerse lo máximo posible a trabajar directamente en el equipo remoto.
Nota: Para usar la comunicación remota de Windows PowerShell, el equipo remoto debe estar configurado para poder emplear esta característica. Para obtener más información, consulte about_Remote_Requirements.
¿LOS DOS EQUIPOS DEBEN TENER INSTALADO WINDOWS POWERSHELL?
Sí. Para trabajar de forma remota, el equipo local y el equipo remoto deben tener Windows PowerShell, Microsoft .NET Framework y el protocolo WS-Management (Web Services for Management). Todos los archivos y recursos que sean necesarios para ejecutar un determinado comando deben estar en el equipo remoto.
Los equipos que ejecutan Windows PowerShell 3.0 y los que ejecutan Windows PowerShell 2.0 pueden conectarse entre ellos de forma remota y ejecutar comandos remotos. Sin embargo, algunas características, como la capacidad de desconectarse de una sesión y volver a conectarse a ella, solo funcionan si ambos equipos ejecutan Windows PowerShell 3.0.
Debe tener permiso para conectarse al equipo remoto, para ejecutar Windows PowerShell y para obtener acceso a los almacenes de datos (por ejemplo, archivos y carpetas) y al Registro del equipo remoto.
Para obtener más información, consulte about_Remote_Requirements.
¿CÓMO FUNCIONA LA COMUNICACIÓN REMOTA?
Al enviar un comando remoto, este se transmite al motor de Windows PowerShell del equipo remoto a través de la red y se ejecuta en el cliente de Windows PowerShell de dicho equipo. Los resultados del comando se devuelven al equipo local y aparecen en la sesión de Windows PowerShell del equipo local.
Para transmitir los comandos y recibir la salida, Windows PowerShell usa el protocolo WS-Management. Para obtener información sobre el protocolo WS-Management, consulte "Protocolo WS-Management" en MSDN (Microsoft Developer Network) Library, en https://go.microsoft.com/fwlink/?LinkId=144634.
A partir de Windows PowerShell 3.0, las sesiones remotas se almacenan en el equipo remoto, lo que le permite desconectarse de la sesión y volver a conectar a otra sesión o a otro equipo sin interrumpir los comandos ni perder el estado.
¿ES SEGURA LA COMUNICACIÓN REMOTA DE WINDOWS POWERSHELL?
Cuando se conecta a un equipo remoto, el sistema usa las credenciales de nombre y contraseña del usuario en el equipo local o las credenciales suministradas en el comando para iniciar sesión en el equipo remoto. Las credenciales y el resto de la transmisión se cifran.
Para agregar una protección adicional, puede configurar el equipo remoto para que use la Capa de sockets seguros (SSL) en lugar del HTTP para escuchar las solicitudes de la Administración remota de Windows (WinRM). Después, los usuarios pueden usar los parámetros UseSSL de los cmdlets Invoke-Command, New-PSSession y Enter-PSSession al establecer una conexión. Esta opción usa el canal más seguro de HTTPS en lugar del HTTP.
¿TODOS LOS COMANDOS REMOTOS REQUIEREN LA COMUNICACIÓN REMOTA DE WINDOWS POWERSHELL?
No. Hay varios cmdlets que tienen un parámetro ComputerName que le permite obtener objetos del equipo remoto.
Estos cmdlets no usan la comunicación remota de Windows PowerShell. Por lo tanto, puede usarlos en cualquier equipo que ejecute Windows PowerShell, incluso si el equipo no está configurado para usar la comunicación remota de Windows PowerShell o si no cumple los requisitos de la comunicación remota de Windows PowerShell.
Estos cmdlets incluyen los siguientes cmdlets:
Get-Process
Get-Service
Get-WinEvent
Get-EventLog
Get-WmiObject
Test-Connection
Para buscar todos los cmdlets que tienen un parámetro ComputerName, escriba:
Get-Help * -Parameter ComputerName
or
Get-Command -ParameterName ComputerName
Para determinar si el parámetro ComputerName de un cmdlet en particular requiere la comunicación remota de Windows 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-Process -Parameter Computername
Para el resto de los 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.
Coloque 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. También puede crear una conexión persistente con un equipo remoto (una sesión) y, luego, usar el parámetro Session 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, presione Control + C. La solicitud de interrupción se pasa al equipo remoto, que 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.
¿SE PUEDE USAR TELNET 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 Windows PowerShell, escriba:
Enter-PSSession <ComputerName>
El símbolo del sistema cambia y muestra que está conectado al equipo remoto.
<ComputerName>\C:>
Ahora, los comandos que escribe se ejecutan en el equipo remoto como si los escribiera 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 ofrece una experiencia parecida.
Para obtener más información, consulte Enter-PSSession.
¿SE PUEDE CREAR UNA CONEXIÓN PERSISTENTE?
Sí. Puede ejecutar comandos remotos especificando el nombre del equipo remoto, su nombre de NETBIOS o su dirección IP. También puede ejecutar comandos remotos especificando una sesión de Windows PowerShell (PSSession) que esté conectada al equipo remoto.
Cuando se usa el parámetro ComputerName de Invoke-Command o Enter-PSSession, Windows PowerShell establece una conexión temporal. Windows PowerShell usa la conexión para ejecutar solo el comando actual y, a continuación, cierra la conexión. Se trata de un método muy eficaz para ejecutar un comando o varios comandos no relacionados, incluso en muchos equipos remotos.
Al usar el cmdlet New-PSSession para crear una PSSession, Windows PowerShell establece una conexión persistente para la PSSession. A continuación, puede ejecutar varios comandos en la PSSession, como los comandos que comparten datos. Insertar aquí cuerpo de sección.
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 más información sobre las sesiones, consulte about_PSSessions.
¿SE PUEDEN 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 Session acepta varias PSSessions.
Al ejecutar un comando Invoke-Command, Windows PowerShell ejecuta los comandos en todos los equipos especificados o en todas las PSSessions especificadas.
Windows 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, consulte el ejemplo del tema de ayuda de Invoke-Command.
¿DÓNDE ESTÁN LOS PERFILES?
Los perfiles de Windows PowerShell no se ejecutan automáticamente en las sesiones remotas. Por eso, 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 las 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 no se ha rellenado la variable $profile, 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 agrega el perfil 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 usa la configuración de sesión.
Para más información sobre los perfiles de Windows 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 que le resulte más fácil administrar los recursos del equipo local, Windows 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 de 32 conexiones simultáneas, pero puede usar los parámetros ThrottleLimit de los cmdlets para establecer un límite personalizado para determinados comandos.
Cuando use la característica de limitación, recuerde que esta se aplica a todos los comandos, no a toda la sesión o al equipo. Si ejecuta comandos de forma simultánea en varias sesiones o PSSessions, el número de conexiones simultáneas será la suma de las conexiones simultáneas de todas las sesiones.
Para buscar los cmdlets que tienen el 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?
Al usar Windows PowerShell de forma local, se envían y se reciben objetos "activos" de .NET Framework. Los objetos "activos" son objetos que se asocian con componentes reales del sistema o de los programas. Al invocar los métodos o al cambiar las propiedades de los objetos activos, los cambios afectan al programa o componente real. Además, cuando se cambian las propiedades de un programa o de un 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, Windows PowerShell "serializa" la mayoría de los objetos que se envían en los comandos remotos, es decir, convierte cada objeto en una serie de elementos de datos XML (Lenguaje de restricciones en XML [CLiXML]) para efectuar la transmisión.
Cuando Windows PowerShell recibe un objeto serializado, convierte el XML en un tipo de objeto deserializado. El objeto deserializado es un registro exacto de las propiedades del componente o del programa en un momento anterior, pero ya no está "activo"; es decir, ya no está asociado directamente con el componente. Además, se quitan los métodos porque ya no están en vigor.
Por lo general, puede usar los objetos deserializados de la misma forma que usaría los objetos activos, pero debe ser consciente de sus limitaciones. Además, los objetos devueltos por el cmdlet Invoke-Command tienen propiedades adicionales que le permiten determinar el origen del comando.
Algunos tipos de objetos, como los objetos DirectoryInfo y los GUID, al recibirlos se convierten en objetos activos. Estos objetos no necesitan ningún tratamiento o formato especial.
Para obtener información sobre cómo interpretar y dar formato a la salida remota, consulte about_Remote_Output.
¿SE PUEDEN EJECUTAR TRABAJOS EN SEGUNDO PLANO DE FORMA REMOTA?
Sí. Un trabajo en segundo plano de Windows PowerShell es un comando de Windows PowerShell que se ejecuta de forma asincrónica sin interactuar con la sesión. Cuando se inicia un trabajo en segundo plano, el símbolo del sistema vuelve inmediatamente y puede seguir trabajando en la sesión mientras se ejecuta el trabajo, incluso si se ejecuta durante un intervalo de tiempo prolongado.
Puede iniciar un trabajo en segundo plano aunque se estén ejecutando otros comandos; esto es posible porque los trabajos en segundo plano siempre se ejecutan asincrónicamente en una sesión temporal. Insertar aquí cuerpo de sección.
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 un trabajo en segundo plano. También puede usar Invoke-Command para ejecutar un comando Start-Job de forma remota.
Para más información sobre los trabajos en segundo plano en Windows PowerShell, consulte about_Jobs y about_Remote_Jobs.
¿SE PUEDEN EJECUTAR PROGRAMAS DE WINDOWS EN UN EQUIPO REMOTO?
Puede usar los comandos remotos de Windows PowerShell para ejecutar programas basados en Windows en equipos remotos. Por ejemplo, puede ejecutar Shutdown.exe o Ipconfig en un equipo remoto.
Sin embargo, no puede usar los comandos de Windows PowerShell para abrir la interfaz de usuario de ningún programa en un equipo remoto.
Al iniciar un programa de Windows en un equipo remoto, el comando no se completa y el símbolo del sistema de Windows PowerShell no vuelve hasta que se termina el programa o hasta que presiona Control + C para interrumpir el comando. Por ejemplo, si ejecuta el programa IpConfig en un equipo remoto, el símbolo del sistema no volverá hasta que se complete IpConfig.
Si usa comandos remotos para iniciar un programa que tiene una interfaz de usuario, el proceso del programa se inicia, pero no aparece la interfaz de usuario. El comando de Windows PowerShell no se completa y el símbolo del sistema no vuelve hasta que detenga el proceso del programa o hasta que presione Control + C, con lo que se interrumpe el comando y se detiene el proceso.
Por ejemplo, si usa un comando de Windows PowerShell para ejecutar el Bloc de notas en un equipo remoto, el proceso del Bloc de notas se inicia en el equipo remoto, pero no aparece la interfaz de usuario del Bloc de notas. Para interrumpir el comando y restaurar el símbolo del sistema, presione Control + C.
¿SE PUEDEN LIMITAR LOS COMANDOS QUE PUEDEN EJECUTAR LOS USUARIOS DE FORMA REMOTA EN EL 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 del equipo (y los permisos de dichas 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 para la sesión. Puede definir la configuración con un ensamblado que implementa una nueva clase de configuración o con un script que se ejecuta 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 protejan el equipo, como las opciones que limitan la cantidad de datos que puede recibir la sesión 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 para que la configuración permita que solo los miembros del grupo Administradores del equipo puedan usarlos.
Puede usar los cmdlets de configuración de sesión para editar las configuraciones de sesión predeterminadas, para crear nuevas configuraciones de sesión y para cambiar los descriptores de seguridad de todas las configuraciones de sesión.
A partir de Windows PowerShell 3.0, el cmdlet New-SessionConfigurationFile le permite crear configuraciones de sesión personalizadas mediante un archivo de texto. El archivo incluye opciones para establecer el modo de lenguaje y para especificar los cmdlets y los 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. También pueden cambiar la configuración predeterminada que usan sus sesiones; para ello, deben cambiar 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 de los cmdlets de configuración de sesión. Para buscar los cmdlets de la configuración de sesión, escriba:
Get-Command *PSSessionConfiguration
¿QUÉ SON LAS CONFIGURACIONES DE ABANICO DE ENTRADA Y DE ABANICO DE SALIDA?
El escenario más habitual de comunicación remota de Windows PowerShell en el que participan varios equipos es la configuración "uno a varios", en la que un equipo local (el equipo del administrador) ejecuta comandos de Windows PowerShell en varios equipos remotos. Es lo que se conoce como escenario de "abanico de salida".
Sin embargo, en algunas empresas, la configuración es "varios a uno", en la que muchos equipos cliente se conectan a un único equipo remoto que ejecuta Windows PowerShell, como un servidor de archivos o un quiosco. Esto es lo que se conoce como configuración de "abanico de entrada".
La comunicación remota de Windows PowerShell admite tanto la configuración de abanico de entrada como la de abanico de salida.
Para la configuración de abanico de salida, Windows PowerShell usa el protocolo WS-Management (Web Services for 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 que Windows PowerShell inicie el proceso de host de Windows 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 abanico de entrada, Windows PowerShell usa Internet Information Services (IIS) para hospedar WS-Management, cargar el complemento de Windows PowerShell e iniciar Windows PowerShell. En este escenario, en lugar de iniciar cada sesión de Windows PowerShell en un proceso independiente, todas las sesiones de Windows PowerShell se ejecutan en el mismo proceso de host.
La administración remota de abanico de entrada y el hospedaje de IIS no son compatibles con Windows XP ni Windows Server 2003.
En una configuración de abanico de entrada, el usuario puede especificar un URI de conexión y un extremo HTTP, incluido el transporte, el nombre del equipo, el puerto y el nombre de la aplicación. IIS reenvía a la aplicación todas las solicitudes que tienen un nombre de aplicación especificado. El nombre predeterminado es WS-Management, que puede hospedar Windows PowerShell.
También puede especificar un mecanismo de autenticación y prohibir o permitir la redirección de los extremos HTTP y HTTPS.
¿SE PUEDE PROBAR LA COMUNICACIÓN REMOTA EN UN EQUIPO (NO EN UN DOMINIO)?
Sí. La comunicación remota de Windows PowerShell está disponible incluso cuando el equipo local no se encuentra en un dominio. Puede usar las características de comunicación remota para conectarse a las sesiones y para 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 grupo de trabajo de un equipo, cambie la siguiente configuración de Windows de dicho equipo.
Precaución: Esta configuración afecta a todos los usuarios del sistema y puede hacer que el sistema sea más vulnerable a ataques malintencionados. Tenga cuidado al efectuar estos cambios.
--Windows XP con SP2:
Use la Configuración de seguridad local (Secpol.msc) para cambiar a "Clásico" la configuración de la directiva "Acceso a redes: modelo de seguridad y uso compartido para cuentas locales" en Configuración de seguridad\Directivas locales\Opciones de seguridad.
--Windows Vista, Windows 7 y Windows 8:
Cree la siguiente entrada del registro y establezca su valor en 1: LocalAccountTokenFilterPolicy en HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Puede usar el siguiente comando de Windows PowerShell para agregar esta entrada:
New-ItemProperty `
–Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System `
–Name LocalAccountTokenFilterPolicy –propertyType DWord –Value 1
--Windows Server 2003, Windows Server 2008, Windows Server 2012 y Windows Server 2012 R2:
No es necesario efectuar ningún cambio porque la configuración predeterminada de la directiva "Acceso a redes: modelo de seguridad y uso compartido para cuentas locales" está establecida en "Clásico". Compruebe la configuración en el caso de que haya cambiado.
¿SE PUEDEN EJECUTAR COMANDOS REMOTOS EN UN EQUIPO DE OTRO DOMINIO?
Sí. Normalmente, los comandos se ejecutan sin errores, aunque puede que deba usar el parámetro Credential 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 aunque el usuario actual sea miembro del grupo Administradores en el equipo local y en el equipo remoto.
No obstante, si el equipo remoto no está en un dominio en el que el equipo local confíe, el equipo remoto podría no ser capaz de 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 del equipo local en WinRM. Escriba el comando en el símbolo del sistema de Windows 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 del equipo local, escriba el siguiente comando en el símbolo del sistema de Windows PowerShell:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value Server01
VEA TAMBIÉN
about_Remote
about_Profiles
about_PSSessions
about_Remote_Jobs
about_Remote_Variables
Invoke-Command
New-PSSession